как разрешить вашему коду хранить неопределенное количество столбцов?

Question

Я думаю, что мой вопрос может быть неясным, но я попытаюсь объяснить это на примере.

скажем, что у нас было около 100 различных моделей автомобилей, очевидно, что все машины имели бы общие части или спецификации, но невсе детали поделены между всеми этими 100 марками автомобилей

. Какова наилучшая практика хранения этих спецификаций в этом случае ??

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

доктрина упрощает эту операцию с помощью этих типов данных (массив-объект). Считаете ли вы это хорошей идеей или не могли бы вы поделиться со мнойваш опыт

вот моя идея в 2 простых таблицах

Table 1
|-------|--------|-------|-------|-------|
| Id    | brand  |engine |desiel | blah..|
|-------|--------|-------|-------|-------|
| 1     | old car|   1.6 | yes   | blah..|
|-------|--------|-------|-------|-------|


Table 2 
|-------|--------|----------------------|
| Id    | car_id |  un common info      |
|-------|--------|----------------------|
| 1     |    1   |array of informations |
|-------|--------|----------------------|

я думаю, что моя идея плохая, потому что она нарушает возможности поиска

Answer 1

Если вам нужно придерживаться MySQL, то, как говорят Пол и Netcoder, EAV будет решением для выбора.

Однако, если EAV не управляется должным образом, возникают проблемы с масштабируемостью, и ваш вариант использования выглядит так, как будто бы его лучше решить с помощью решения NoSQL (нереляционной базы данных), такого как Couch или Mongo.

Базы данных, ориентированные на документы, подобные этим, строятся вокруг логики, согласно которой у объекта нет фиксированного числа полей, например, продукта, и данные обо всех его изображениях будут находиться в одном «документе».

Answer 2

Возможно, вам нужна схема Entity-Attribute-Value (EAV).Это может позволить вам иметь записи с различным количеством информации, но может быть сложным для запроса.

Answer 3

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

Answer 4

Разве невозможно принудительно определить количество и типы столбцов? Даже если вы допускаете несколько расплывчатых? Если бы вы могли определить столбцы, комплексное решение не понадобилось бы. Может быть наименее болезненным вариантом. Просто мысль.

Answer 5

Обычно используемое решение состоит в том, чтобы иметь таблицу, которая принимает пары ключ-значение (обычно называемые EAV):

|-------|--------|-------|
| carId | name   | value |
|-------|--------|-------|
| 1     | engine | 4cyl  |
|-------|--------|-------|