Предел объема базы для нормальной работы

[espada]

Предел объема базы для нормальной работы

У меня на сайте в одном из разделов скрипт пробегает по всем таблицам базы, выбирает часть данных из всех полей и выносит их на страницу.

Пока при наличии сорока таблиц по пять полей и не больше пятидесяти записей в каждой все получается нормально. Но ориентировочно и число таблиц и число записей в дальнейшем должно перевалить далеко за тысячу, и хотелось бы заранее представлять себе подводные камни. То есть на каких числах того и другого скрипт начнет спотыкаться.

 

[Romantik]

ИМХО я уверен, что у тебя не верно спроектирована база данных...

 

[nagash]

согласен с романтиком...

расскажи чего ты пытаешься добаться...
уверен можно более оптимально спроектировать базу

 

[Yurik]

И скоко ж вас таких? Наверное доручи вам написать что-то типа 1С - так пару десятков тысяч полей в БД создадут.

espada: почитай хоть чуток теории, что такое 2 и 3 нормальные формы. Спорю что после этого таблиц станет в 8 раз меньше, а полей станет фиксированное к-во - не больше 15 в каждой.

 

[DiMA]

А помоему классно - на каждую запись в гостевой книге заводить по отдельной таблице. Прикиньте, какая сказочная скорость при выборе из таблицы одной записи, когда она там всего одна?

 

[Sad Spirit]

Автор оригинала: DiMA
А помоему классно - на каждую запись в гостевой книге заводить по отдельной таблице. Прикиньте, какая сказочная скорость при выборе из таблицы одной записи, когда она там всего одна?

Не смешно.
Заглядывал недавно в потрошки одного интернет-магазина --- там для каждого типа товара своя таблица, при добавлении/изменении атрибутов делается ALTER TABLE...

 

[Romantik]

Круто! Я вот тоже видел магазин : мало того, что на каждую группу товара создается отдельная таблица, к тому же добавляются по 3 файла для группы и... в несколько файлов меню дописывается код обработки этой группы.

 

[young]

http://www.innodb.com/features.html

maximum tablespace size 4 billion pages.

 

[espada]

Полей у меня и так фиксированное количество. А вот таблиц...

Ситуация такая. Многоязычный словарь с неограниченной выборкой языков и слов. То есть и языков и слов неопределенное количество.

В базе на каждое русское слово - своя таблица. А на каждый язык - своя запись. В принципе можно бы и наоборот (языков в перспективе меньше, чем слов), но тогда, во-первых, будет сложнее переносить в базу старый хтмл-ный сайт, а во-вторых, рукописная часть на карточках тоже сгруппирована не по языкам, а по словам - то есть переносить опять же проще так, как сделано, а не наоборот.

А третьего пути я не вижу. Может, кто подскажет.

Результат всего этого можно найти на http://thezaurus.org.ru

P.S.
Поскольку в результате нормализации база данных разделяется на ряд более мелких таблиц, модифицировать существующие структуры становится проще. Гораздо проще изменить небольшую таблицу с малым количеством данных, чем большую таблицу, содержащую все жизненно важные для базы данных значения.

Это из лекции по нормализации баз данных. Следует ли понимать это так, что много маленьких таблиц лучше чем мало громадных?

 

[espada]

Теперь я знаю ответ на свой вопрос. 300 таблиц замедляют работу почти катастрофически

 

[Yurik]

В базе на каждое русское слово - своя таблица.

Заглядывал недавно в потрошки одного интернет-магазина --- там для каждого типа товара своя таблица

на каждую запись в гостевой книге заводить по отдельной таблице

почитай хоть чуток теории, что такое 2 и 3 нормальные формы

 

[Yurik]

Поскольку в результате нормализации база данных разделяется на ряд более мелких таблиц, модифицировать существующие структуры становится проще. Гораздо проще изменить небольшую таблицу с малым количеством данных, чем большую таблицу, содержащую все жизненно важные для базы данных значения.

Совершенно неправильное понимание прочитанного

 

[Yurik]

_word.php?id=sviaschennik

и не влом так на каждое слово создавать ключики?
sviaschennik - священник
blabla - блабла

 

[fixxxer]

espada:
Вот, нашел описание {1-3}NF без мудреных определений:

Первая нормальная форма требует, чтобы каждое поле таблицы БД было неделимым и не содержало повторяющихся групп. Неделимость поля означает, что содержащиеся в нём значения не должны делиться на более мелкие. Повторяющимися являются поля, содержащие одинаковые по смыслу значения.

Вторая нормальная форма требует, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц.

Третья нормальная форма требует, чтобы в таблице не имелось транзитивных зависимостей между неключевыми полями, то есть, чтобы значение любого поля, не входящего в первичный ключ, не зависело от значения другого поля, также не входящего в первичный ключ.

Внимательно прочитай и осмысли.

 

[Romantik]

ИМХО читать нужно не с нормализации, а с основ проектирования БД!

 

[Sad Spirit]

Автор оригинала: Romantik
ИМХО читать нужно не с нормализации, а с основ проектирования БД!

а что, "основы проектирования" не включают "нормализацию"?

 

[Romantik]

Это следующая глава.

 

[Кром]

>и не влом так на каждое слово создавать ключики?

Yurik абсолютно прав. Такие ключи погубят все дело.
id должен быть id, а не слово в транслитерации. Меняй структуру пока не поздно.

 

[espada]

Ладно, аллах с ним. Все равно я придумал только один вариант - свести все эти мелкие таблички в одну большую, добавив одно поле.

А с id я не понял сути. Все равно ведь нужна отдельная таблица, из которой формируется список слов.

Впрочем, буду благодарен за любые идеи, как этого избежать.

Структура новой большой таблицы у меня включает три поля (на самом деле больше, но остальные пока не в счет):

слово - язык - перевод

Слово и язык объединены уникальным ключом. Выглядит это, допустим, так:

крокодил - литовский - перевод
крокодил - английский - перевод

И возникает вопрос, как мне достать отсюда одного крокодила для списка? Сейчас я вынимаю его из другой таблицы, где написано: крокодил - krokodil, и такая запись уникальна.

krokodil я передаю, как аргумент по ссылке. Можно бы и русское слово передавать, но тогда возникнет проблема с конвертацией id=крокодил в крокодил.php (или я неправ?)

Правда, тут же возникает заморока, потому что в исполняющем скрипте приходится конвертировать krokodil обратно в крокодил через ту же таблицу. Но ведь если id будет, к примеру, номером, все равно придется делать то же самое.

В принципе, можно сделать это в пределах одной общей таблицы. Вставить для каждого слова по записи типа

крокодил - -word- - krokodil

Но сути дела это ведь не меняет.

 

[fixxxer]

А числовой id передавать не судьба?
Или ты хочешь сказать что у тебя в таблице нет автоинерементного целочислеггого ид? Ну тогда совсем дела плохи...