Как хранить конкретные данные (например, опросы) в базе данных MySQL?

Question

Допустим, я хотел бы сохранить голоса для опросов в базе данных mysql.

Насколько я знаю, у меня есть два варианта:

1 . Создайте одну таблицу (скажем, голоса ) с такими полями, как poll_id, user_id, selected_option_id, voice_date и т. Д.

2 . Создайте новую базу данных для голосов (скажем, voice_base ) и для каждого опроса добавьте таблицу к этой базе (таблицу, которая содержит идентификатор опроса в названии), скажем, poll [ идентификатор опроса] .

Проблема с первой опцией заключается в том, что стол очень скоро станет большим. Допустим, у меня есть 1000 опросов, и каждый опрос имеет 1000 голосов - это уже миллион записей в таблице. Я не знаю, сколько из скоростных характеристик это будет стоить.

Проблема с второй опцией заключается в том, что я не уверен, является ли это правильным решением с точки зрения правил программирования. Но я уверен, что с этой опцией будет (намного?) Быстрее найти все голоса в каком-либо опросе.

Или, может быть, есть лучший вариант?

Answer 1

Ваш первый вариант - лучший вариант. Это более конструктивно. Миллионы строк в таблице не проблема из MySQL. Новая таблица для каждого опроса является антипаттерном.

РЕДАКТИРОВАТЬ для первого комментария:

Даже для миллиарда и более голосов MySQL должен справиться. Индексы являются ключом здесь. В чем разница между одной базой данных со 100-кратной одинаковой таблицей или одной таблицей со 100-кратным количеством строк?

Технически, второй вариант тоже работает. Иногда это может быть даже лучше. Но мы часто видим это:

• Вместо одной таблицы пользователи с 10 столбцами
• Составьте 100 таблиц users_uk, users_us, ... в зависимости от того, откуда пользователи.

Отлично, нет? Работает да? Что ж, это так, пока вы не хотите выбрать всех пользователей мужского пола или присоединить таблицу пользователей к другой таблице. У вас будет огромный СОЮЗ, и вы даже не будете знать столы заранее.

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

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

Answer 2

Первый вариант лучше, без сомнения. Просто убедитесь, что вы указали INDEX для полей, которые вы будете использовать для поиска данных (например, poll_id), и у вас не возникнет проблем с производительностью. MySQL - это СУБД, прекрасно способная обрабатывать такое количество строк. Не волнуйтесь.

Answer 3

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