Как правильно сделать БД для 1 млн. записей

[MStek]

Необходимо сделать базу данных.
Есть некоторые значения (текст около 300-500 символов) и категории. Одно значение может относится сразу к нескольким категориям. Дальнейшее редактирование значений не требуется. Категорий будет 100 с дальнейшим увеличением до 200-300. Значений будет примерно по 5-10 тыс.в каждой категории. Значения так же всё время дополняются, т.о. общее количество значений ожидается около 1 млн.
Задача: как правильно спроектировать базу данных, что бы при работе возникала минимальная нагрузка на сервер.

Мои варианты:
1. Сделать для каждой категории таблицу и в неё вносить значения.
- Будет накапливаться в каждой таблице дублирующая информация со значениями. ( так как одно значение может относится к нескольким категориям, придется записывать в несколько таблиц )
- Практически сложно будет редактировать значения (но по условию это не требуется, но вдруг надо будет потом)

2. Сделать таблицу категорий, таблицу значений (все записи уникальны), и таблицу связи
- Через некоторое время таблица со значениями будет содержать 500-1000 тыс. записей.

Вопрос: Какой их вариантов более правильный и какой вариант будет создавать меньшую нагрузку на сервер.

 

[Aleksey]

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

 

[etc]

Тут простая связь многие-ко-многим, и думать нечего.

 

[Aleksey]

В любом случае первый вариант неприемлем, так как создать 100-300 таблиц и потом попытаться ими управлять - не лучший вариант.
Тут подходит второй вариант. Скорость работы обеспечат индексы.

Тут простая связь многие-ко-многим, и думать нечего.

А мне показалось, что связь один ко многим. То есть одна категория - много значений (это я по первому предложенному варианту решения делаю такой вывод: там написано, что "создать для каждой категории таблицу значений"...) . Просто значения не уникальны для категории, могут быть одинаковые значения для разных категорий. Из-за этого придется делать таблицу со связями. Хотя, если допустить дублирование записей в таблице значений, то можно обойтись двумя таблицами. Тут уж решать по количеству дублей.

 

[etc]

какой вариант будет создавать меньшую нагрузку на сервер.

Не вариант создает нагрузку а человек!

А мне показалось, что связь один ко многим.

а я делаю выводы по написанному:

Одно значение может относится сразу к нескольким категориям.

и

Значений будет примерно по 5-10 тыс.в каждой категории.

 

[MStek]

Тут простая связь многие-ко-многим, и думать нечего.

Ну я тоже склоняюсь к этому варианту, только у меня такой вот вопрос - ведь добавить уникальное значение в таблицу с 5-10 тыс. записей намного быстрее, чем в таблицу с 500 тыс. записей. Ну и читать данные из конкретной таблицы быстрее, чем выбирать эти данные из 500 тыс. значенией, вот поэтому то у меня и возник первый вариант. Или я не прав?

 

[etc]

добавить уникальное значение в таблицу

Не понял, про какое уникальное значение вы говорите?
А в принципе, практически пофик сколько там записей, разница конечно есть, но врядли вы ее ощутите.

читать данные из конкретной таблицы быстрее, чем выбирать эти данные из 500 тыс. значенией

Опять же - фиолетово, все зависит от того как спроектирована таблица, какие индексы у нее есть и т.д.
При правлильной структуре может оказаться, что быстрее будет не так как вы думаете.
Да и выборка из "5-10 тыс. записей" - кому нафик нужна? никому, поэтому это не кретерий.

 

[Aleksey]

Да, я перечитал и все же понял, каюсь, связь многие ко многим (тьфу-ты, как опростоволосился ). Хотел сказать, что если пренебречь дублированием значений в таблице записей, то можно получить связь один ко многим и избежать создания таблицы со связями.

MStek, поверьте, не стоит делать базу данных из 500 таблиц, если можно обойтись тремя (а то и двумя). Если же вас пугает объем в миллион строк, то это вовсе не та цифра, которая способна повалить сервер.

 

[MStek]

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

поверьте, не стоит делать базу данных из 500 таблиц, если можно обойтись тремя (а то и двумя). Если же вас пугает объем в миллион строк, то это вовсе не та цифра, которая способна повалить сервер.

Ну у меня был опыт, когда надо было из таблицы в 50 тыс. строк выбрать только уникальные значения, и эта операция длилась у меня чуть ли не минуту, вот и пугает меня 1 млн.

Вот и думаю, сколько времени будет занимать добавление в таблицу с 1 млн. строк уникально значения, я то так понимаю, что перед добавлением Mysql проверит, нет ли среди этого миллиона такого значения, которое я хочу добавить, а это же время. Или я опять ошибаюсь?

 

[Aleksey]

Никак из-за объемов дублируемых данных?

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

...все зависит от того как спроектирована таблица, какие индексы у нее есть и т.д.

 

[etc]

MStek Вы путаете белое с пушистым.