MySQL : Some Questions!
8 отговора
287 прегледа
MySQL : Some Questions!
В момента работя по един "едър" проект.
Имам няколко варианта на разработка като съм се спрял определено на два.
Единия е по-кратък, удобен и най-вече - готов :)
Докато другия е по-нежелан но пестелив относно базата данни.
-------------------------------------
И в двата варианта разполагам с таблица съдържаща минимум 20 000 полета (има и други разбира се, но тази е важната), но докато за втория вариант тази таблица е напълно достатъчна, то първия има нужда от още една допълнителна таблица с пропорционални (средно) на брой полета спрямо първата = 1:11. Тоест ако едната таблица е с 20 000 полета то другата е с 220 000 полета. И плюс това се претърсва сравнително често.
Та на въпроса...
Не съм работил с толкова много полета и не знам дали мога да имам проблеми и от какво естество биха могли да бъдат (броя на полетата, затруднения и забавяния при търсенията и т.н.)
По възможност съвети от хора с опит биха ми дошли много добре или някакъв линк с документация по въпроса. Аз лично не можах да намеря.
Благодаря ви предварително.
П.С. Мисля че има значение : в използването на голямата таблица не се използва търсене по Ай Ди (защото няма как)
Имам няколко варианта на разработка като съм се спрял определено на два.
Единия е по-кратък, удобен и най-вече - готов :)
Докато другия е по-нежелан но пестелив относно базата данни.
-------------------------------------
И в двата варианта разполагам с таблица съдържаща минимум 20 000 полета (има и други разбира се, но тази е важната), но докато за втория вариант тази таблица е напълно достатъчна, то първия има нужда от още една допълнителна таблица с пропорционални (средно) на брой полета спрямо първата = 1:11. Тоест ако едната таблица е с 20 000 полета то другата е с 220 000 полета. И плюс това се претърсва сравнително често.
Та на въпроса...
Не съм работил с толкова много полета и не знам дали мога да имам проблеми и от какво естество биха могли да бъдат (броя на полетата, затруднения и забавяния при търсенията и т.н.)
По възможност съвети от хора с опит биха ми дошли много добре или някакъв линк с документация по въпроса. Аз лично не можах да намеря.
Благодаря ви предварително.
П.С. Мисля че има значение : в използването на голямата таблица не се използва търсене по Ай Ди (защото няма как)
Re: MySQL : Съвет.
За да не стават обърквания в терчинологията просто винаги казвай
Таблици, Редове, Колони, Стойности.
Броят на редовете сам по себе си не казва нищо. 220 000 не нещо особено. Виж ако бяха 220 милиона това все още минава за голяма таблица.
"Докато другия е по-нежелан но пестелив относно базата данни. "
Толкова мъгляво се изказваш, че никой нищо не може да ти отговори.
Дай малко по-подробно.
Например при добър дизайн обикновено таблиците стават повече, често и с много като брой редове, но това може да спести както място така и скорост а понякога и двете едновременно.
salle.online.bg/sig
Таблици, Редове, Колони, Стойности.
Броят на редовете сам по себе си не казва нищо. 220 000 не нещо особено. Виж ако бяха 220 милиона това все още минава за голяма таблица.
"Докато другия е по-нежелан но пестелив относно базата данни. "
Толкова мъгляво се изказваш, че никой нищо не може да ти отговори.
Дай малко по-подробно.
Например при добър дизайн обикновено таблиците стават повече, често и с много като брой редове, но това може да спести както място така и скорост а понякога и двете едновременно.
salle.online.bg/sig
Re: MySQL : Some Questions!
........или някакъв линк с документация по въпроса. Аз лично не можах да намеря........
Съдейки по въпроса ти мисля, че ще е добре да попрочетеш за основите на релационните бази данни - същности, релации, нормализация. Не мога да ти дам готов линк, но ако търсиш с Codd RDBMS SQL няма начин да не намериш.
Съдейки по въпроса ти мисля, че ще е добре да попрочетеш за основите на релационните бази данни - същности, релации, нормализация. Не мога да ти дам готов линк, но ако търсиш с Codd RDBMS SQL няма начин да не намериш.
Re: MySQL : Some Questions!
200 000 не са "мижави"
Не случайно споменах "добре проектирана" база данни.
Мога да ти демонстрирам (всеки може всъщност) как една заявка към таблица с 10 000 000 реда работи по бързо от друга заява към таблица с 100 реда. Или пък да ти напиша пример за заявка, към таблица он 100 реда, която не само, че ще работи с часове но и толкова памет ще иска, че като нищо ще ти срине сървъра.
Всичко е много относително. Наскоро имах случай със една заявка която се "влачи ужасно бавно - цели 15 секунди" а идеше реч за няколко гигабайта информация. В други случаи дадена заявка се изпълняваше "само" за 2 часа.... в сравнение с над 40 преди оптимизация.
Така, че дерзай.
salle.online.bg/sig
Не случайно споменах "добре проектирана" база данни.
Мога да ти демонстрирам (всеки може всъщност) как една заявка към таблица с 10 000 000 реда работи по бързо от друга заява към таблица с 100 реда. Или пък да ти напиша пример за заявка, към таблица он 100 реда, която не само, че ще работи с часове но и толкова памет ще иска, че като нищо ще ти срине сървъра.
Всичко е много относително. Наскоро имах случай със една заявка която се "влачи ужасно бавно - цели 15 секунди" а идеше реч за няколко гигабайта информация. В други случаи дадена заявка се изпълняваше "само" за 2 часа.... в сравнение с над 40 преди оптимизация.
Така, че дерзай.
salle.online.bg/sig