Одна таблица mysql со многими полями или многими (сотнями) таблицами с меньшим количеством полей?

Question

Я проектирую систему для клиента, где он может создавать формы данных для различных продуктов, которые он продает сам. Число полей, которые он будет использовать, не будет более 600-700 (наихудший сценарий). Похоже, он, вероятно, будет в диапазоне от 400 до 500 (макс.).

У меня было 2 методов в виду, для создания базы данных (с помощью мета-данные):

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

или

б) использовать одну единственную таблицу со всеми полями формы Availabe (любого диапазона от тока 300 до макс 700), в результате чего в одной таблице, которая будет иметь много полеев, из которых только около 10% будет использоваться для каждой записи продукта (продукт обычно не должен использоваться более 50-80)

Какое решение лучше всего подходит? имея в виду, что обслуживание таблиц (создание, обновление и изменение) в таблице (таблицах) будет выполняться с использованием метаданных, поэтому мне не нужно будет делать изменения в таблице (таблицах) вручную.

Спасибо!

/**** UPDATE *****/

Просто обновление, даже после долгого времени (и ALLOT дополнительного опыта, накопленного) я должен упомянуть, что не normalizing база данных страшная идея. Более того, не нормализованная база данных почти всегда (как всегда из моего опыта) также указывает на неправильный дизайн приложения.

Answer 1

Ваш ключевой решающий фактор заключается в том, требуется ли normalization. Даже при том, что вы добавляете данные только с помощью приложения, вам все равно придется обслуживать аномалии, например. что произойдет, если номер телефона человека изменится, и они вставляют несколько строк в течение всего срока службы приложения? В какой строке содержится правильный номер телефона?

В качестве примера вы можете обнаружить, что у вас будет repeating groups, как у одного человека с несколькими номерами телефонов; вместо трех столбцов, называемых «Phone1», «Phone2», «Phone3», вы разделите эти данные на свою собственную таблицу.

Другие проблемы при нормализации, такие как транзитивные или неключевые зависимости. Эти концепции, надеюсь, приведут вас к дизайну таблицы базы данных без modification anomalies, как и следовало ожидать!

Answer 2

я бы есть 3 таблицы:

• продукта

  • идентификатор
  • имя
  • что еще нужно

• поле

  • идентификатор
  • имя поля
  • что-нибудь еще может понадобиться

• product_field

  • ID
  • PRODUCT_ID
  • FIELD_ID
  • значение поля

Answer 3

Pulegiums решение является хорошим способом пойти.

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

Answer 4

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

Вам необходимо проанализировать потенциальные структуры таблиц, чтобы гарантировать, что каждое поле содержит не более одной информации (например, «2 молотка, 500 гвоздей» в одном поле плохо) и что каждая часть информации не имеет более одного поля, где оно принадлежит (например, phone1, phone2, phone3 полей плохо). Любая из этих ситуаций указывает, что вы должны перенести эту информацию в отдельную связанную таблицу с внешним ключом, соединяющим ее с исходной таблицей. Как показал pulegium, этот метод может быстро разрушить вещи до трех таблиц, всего около десятка полей.