как спроектировать это отношение в схеме БД

Question

У меня есть таблица Car в моей базе данных, одна из колонок - buyDate. Я хочу иметь возможность пометить каждую машину несколькими политиками (ограничено 10 политиками). У каждой политики есть время жизни (ttl, продолжительность, например, «5 лет», «10 месяцев» и т. Д.), То есть сколько времени может быть применено с момента покупки автомобиля.

Мне нужно выполнить следующие действия:

• при вставке автомобиля будет установлено несколько политик (хотя бы одна из них установлена)
• иногда автомобиль будет обновляться для добавления / удаления политики
• поиск должен быть выполнен с учетом даты / политики, например: «выбрать все автомобили, которые не охвачены какой-либо политикой на сегодняшний день»

Мой текущий дизайн (политики pol0..pol9):

CREATE TABLE Car (
 id int NOT NULL IDENTITY(1,1),
 purchaseDate datetime NOT NULL,
 //more stuff...
 pol0 smallint default NULL,
 pol1 smallint default NULL,
 pol2 smallint default NULL,
 pol3 smallint default NULL,
 pol4 smallint default NULL,
 pol5 smallint default NULL,
 pol6 smallint default NULL,
 pol7 smallint default NULL,
 pol8 smallint default NULL,
 pol9 smallint default NULL,
 PRIMARY KEY  (id)
)

CREATE TABLE Policy (
 id smallint NOT NULL,
 name varchar(50) collate Latin1_General_BIN NOT NULL,
 ttl varchar(100) collate Latin1_General_BIN NOT NULL,
 PRIMARY KEY (id)
 )

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

1. Вместо «int IDENTITY» было выбрано smallint в качестве идентификатора политики, чтобы сэкономить место, так как количество записей об автомобилях будет составлять миллионы. Это просто добавляет сложности при создании Политики, поскольку мы должны обрабатывать идентификатор и т. Д. Стоило ли это делать?

2. Я думаю, что, может быть, есть гораздо лучший дизайн? Очевидно, что мы могли бы перенести отношение «политика / машина» на свой собственный стол CarPolicy, преимущества были бы:

   • нет ограничений на 10 полисов на машину
   • добавление / удаление и т.д. намного проще
   • когда применяется только политика по умолчанию (когда не применяется ни одна другая, которая называется политикой по умолчанию), мы могли бы сигнализировать, что, не имея какой-либо записи в CarPolicy, теперь это просто делается путем вставки идентификатора политики по умолчанию в один из столбцы.

   Минусы в том, что нам нужно изменить классы DB, ORM и т. Д. Что бы вы порекомендовали?

3. Может быть, есть еще один умный способ реализовать это, которого мы не знаем без использования таблицы CarPolicy?

Answer 1

1. Прошло много времени с тех пор, как для экономии места стоило использовать smallint;вы не увидите значительного различия в производительности, если будете делать это таким образом, это просто создает потенциальные головные боли.

2. Отдельная таблица CarPolicy, безусловно, является правильным способом сделать этопричины вы перечислили.Для внесения изменений необходимо потратить время на предварительную оплату, но как только это будет сделано, оно будет сделано, и оно окупится много раз в спасенных бедах.

Answer 2

Я бы порекомендовал изменить его, чтобы у вас была таблица политик с идентификатором автомобиля. Таким образом, вместо ссылки на кучу политик в таблице Car, вы ссылаетесь на один Car в таблице Policies. Затем вы включаете столбец TTL и столбец Status, чтобы срок их действия истек, и вы можете делать запросы, используя идентификатор автомобиля в таблице политик.

Пока на одну политику может быть только 1 Автомобиль и ровно 1 Автомобиль (у кого есть политика без автомобиля, верно?), Тогда это хороший способ сделать это.

ОБНОВЛЕНИЕ: Ах, тогда я неправильно понял. Если это много ко многим, сделайте, как все говорили, и сделайте таблицу CarPolicy.

Answer 3

Я бы порекомендовал дать отношению его собственную таблицу, содержащую идентификатор автомобиля и идентификатор политики.