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

Тема в разделе "SQL", создана пользователем MStek, 19 янв 2009.

  1. MStek

    MStek Гость

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

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

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

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

    Aleksey Гость

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

    etc Гость

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

    Aleksey Гость

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

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

    etc Гость

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


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

    MStek Гость

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

    etc Гость

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

    Aleksey Гость

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

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

    MStek Гость

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


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

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

    Aleksey Гость

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

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

     
  11. etc

    etc Гость

    MStek Вы путаете белое с пушистым.
     
Загрузка...

Поделиться этой страницей