Лучший дизайн для объектов с несколькими значениями

Question

Скажем, у вас есть объект, подобный транспортному средству, о котором вы собираете подробную информацию. Автомобиль, который вы хотите запечатлеть, окрашен в красный, черный и белый цвета. Передние шины Bridgestone 275 / 35-18, а задние шины 325 / 30-19. И иногда вы можете иметь только две шины (да, это будет мотоцикл, который является типом транспортного средства) и иногда 18 шин, которые могут быть разными. Тогда есть некоторые поля, которые всегда имеют одно значение, например, размер двигателя (если мы даем волю воображению, мы можем думать о многодвигательных транспортных средствах, но я пытаюсь сохранить это простым).

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

Answer 1

Если вы используете реляционную базу данных, ваше предложение является практически единственным способом сделать это. Теория нормальных форм 1002 * даст вам больше информации о ней - статьи в Википедии о ней довольно хороши, хотя и немного тяжелы, потому что это сложный теоретический предмет, когда вы переходите на более высокие уровни нормализации. Хотя примеры в основном здравого смысла.

Предполагая, что у вас есть таблица Vehicle, таблица Color и таблица TyreType (извините за британскую орфографию), вы, вероятно, определяете таблицы VehicleTyre и VehicleColour, которые действуют как соединение между соответствующими парами таблиц. Эта структура на самом деле довольно здорова. Он не только инкапсулирует информацию, которую вы хотите напрямую, но также позволяет естественным образом фиксировать такие вещи, как, например, какая шина (например, передний левый - Bridgestone 275 / 35-18) или какая часть автомобиля окрашена в красный цвет (например, с помощью процентное поле в таблице VehicleColour).

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

В моей компании есть множество схем, которые работают именно на этой основе - действительно, наша объектно-реляционная структура автоматически создает их для управления отношениями «многие ко многим» (а иногда даже для отношений «один ко многим» в зависимости от того, как мы их моделируем). ). Некоторые из наших приложений имеют более 150 сущностей и более 100 из этих таблиц соединения. Нет проблем с производительностью и нет значимого влияния на управляемость данных, за исключением того, что некоторые имена таблиц раздражающе длинные.

Answer 2

Если это возможно для вашего приложения, вы можете изучить couchdb .

Answer 3

Ваша текущая стратегия правильная. Вы отслеживаете очень много видов данных, поэтому вам понадобится много таблиц. Вот только как это. СУБД жалуется?

Answer 4

Это на самом деле зависит от того, имеют ли сами переменные только одну переменную (пример: у вас может быть переменное количество шин одного типа или заданное количество шин переменного типа).

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

Если у вас есть несколько полей, у которых просто есть набор значений для выбора (скажем, 2, 4 или 6 окон), вы можете просто использовать enum или определить новый тип поля с помощью пользовательских доменов (в зависимости от какую СУБД вы используете).

Answer 5

Если вы используете SQL Server, не бойтесь хранить Тип данных XML . Я обнаружил, что это делает такие вещи намного, намного проще.

Answer 6

Похоже, вы смотрите на то, что называется Иерархическая модель .

Или, может быть, подойдет простой список пар (attr, value)?

Answer 7

Вы описываете Схема звезды . Я думаю, что это довольно стандартная практика в вашем случае

Редактировать: На самом деле ваша схема немного изменена по сравнению со звездообразной схемой, вы используете первичный ключ таблицы фактов в каждой из таблиц измерений для объединения, чтобы вы могли иметь несколько цветов краски и т. Д. В любом случае, я думаю, что это хорошо способ справиться с вашей сущностью. Вы можете пойти еще дальше и нормализовать таблицы измерений, и тогда у вас будет схема снежинки