«Настройки поездки», дизайн базы данных

Question

Я ищу для создания базы данных для покупок в магазине. Поездки имеют Location, a Mode и Preferences. (Все они являются сущностями или классами). Предположим теперь, что у каждого Trip может быть только один Preferences, а Preferences может быть частью нескольких поездок.

Теперь я смоделировал его таким образом:

Trips(id, attr1, attr2, ..., prefs); 
Preferences(id, pref1, pref2, pref3); 

Где 'префы' является FK (и pref1, pref2 и pref3 являются булевыми типами).

Хорошо, когда я храню поездку (с идентификатором = 1) с pref1, pref2 и pref3 к истине, и другая поездка (с ID = 2) с теми же значениями предпочтения, у меня будет что-то вроде этого:

+------+----+-------+-----+---------------+ 
| Trip | id | attr1 | ... | prefs   | 
+------+----+-------+-----+---------------+ 
|  | 1 | X | ... | 10   | 
+------+----+-------+-----+---------------+ 
|  | 2 | X | ... | 20   | 
+------+----+-------+-----+---------------+ 


+-------------+------+-------+-------+---------+ 
| Preferences | id | pref1 | pref2 | pref3 | 
+-------------+------+---------------+---------+ 
|    | 10 | True | True | True | 
+-------------+------+---------------+---------+ 
|    | 20 | True | True | True | 
+-------------+------+---------------+---------+ 

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

Возможно, проблема связана с моим приложением, а не с моим дизайном базы данных?

Спасибо.

(Извините за мой основной английский).

Answer 1

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

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

Что-то вроде этого:

Trips 
(id 
, attr1 
, attr2 
) 

Preferences 
(id 
, description 
) 

Trip_Preferences 
(trip_id 
, preference_id 
, value -- If the value is true/false, then you have the option of leaving this out 
     -- and just using the presence or absense of a record in this table as the 
     -- indication of the value. 
) 

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