Правильный макет базы данных MySQL

Question

Создание пользовательской системы CRM Я столкнулся с стеной, выясняя правильный способ компоновки MySQL. Система должна быть динамичной, т.е. расширяемый для нескольких новых продуктов с течением времени. Каждый продукт должен иметь индивидуальный биллинг, и каждый контакт должен иметь несколько продуктов.

Должен ли я использовать таблицы, как это:

Contacts{ ID } 
Product_1{ ID; FK_ID; +Custom columns} 
Product_2{ ID; FK_ID; +Custom columns} 
Product_3{ ID; FK_ID; +Custom columns} 
+ 15 more products (Expanding) 

Или я должен использовать что-то вроде этого:

Contacts{ ID } 
Products{ ID; FK_ID; +100 other columns (expanding)} 

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

Последний пример будет проще настраивать в PHP, но будет беспорядок, смотрящий на таблицу.

Любые другие идеи? Что из них быстрее? Что является наиболее «общим»?

У меня такое ощущение, что ни одно из этих решений не оптимально, должен быть лучший способ?

Answer 1

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

Product_1{ Product_ID (PK); +Custom columns} 
Product_2{ Product_ID (PK); +Custom columns} 
... 

Теперь возьмите это шаг Furt ее с этими таблицами:

Product {ID (PK auto increment); Contact_ID (FK), Type_ID (FK)} 
Product_Type {Type_ID (PK); Type_Name} 

Вставка столько строк в product_type, как у вас есть таблицы пользовательских продуктов (Product_1, Product_2 и т.д.). Каждый раз, когда вы создаете новую конкретную таблицу продуктов, добавьте строку в таблицу Product_Type.

Также введите Product_n.Product_ID внешний ключ (и НЕ автоинкремент) до Product.ID.

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

Если вы хотите, чтобы сделать его полностью пуленепробиваемым, вы можете добавить Type_ID столбец каждой таблицы Product_n, включить его в ПК (наряду с Product_n.Product_ID) и добавить проверочное ограничение такое, что Product_1.Type_ID == 1, Product_2.Type_ID == 2 и так. Это гарантирует, что вы не можете испортить отношения между Product и Product_n, даже если попробуете, но, честно говоря, я думаю, что это слишком много, и у меня не было проблем с «непункерной» версией.

Answer 2

Вы могли бы рассмотреть третью таблицу для хранения динамической «особенности»:

Contacts{ Id; } 
Products{ Id; } 
ProductFeature{ Id; ProductId; FeatureName, FeatureValue } 

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