Как спроектировать таблицы для поддержки, имеет много связей со значением по умолчанию?

#sql #database-design #has-many

#sql #база данных-дизайн #имеет-many

Вопрос:

Как спроектировать таблицы для поддержки имеет много связей со значением по умолчанию?

Например:
В стране много городов. По умолчанию для страны используется один город.

Вариант проектирования таблиц 1:
В таблице City будет логическое поле — is_default.

Вариант проектирования таблиц 2:
В таблице Country будет поле внешнего ключа — default_city.

Запросы, которые будут написаны:
Обновить и получить город по умолчанию и изменить, какой город используется по умолчанию.

Какой вариант лучше и почему?

Заранее благодарю.

Ответ №1:

У этого вопроса есть философские аспекты, а также практические аспекты.

Философский вопрос заключается в том, «какой объект должен знать о статусе по умолчанию — страна или город?». Может ли страна существовать без города по умолчанию? Является ли «defaultness» атрибутом, который вы можете связать с городом? Существуют ли какие-либо другие атрибуты, которые могут применяться к связи между городом и страной?

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

Кстати, я не знаю ответов, но стоит обсудить это с вашей командой — я считаю, что решением по умолчанию должно быть «делайте то, что лучше всего соответствует модели домена».

Затем возникают некоторые практические проблемы.

Как пишет @SaadAhmad, если «город по умолчанию» в качестве атрибута country, и вы хотите сделать его обязательным, запись city должна существовать до того, как вы создадите страну, а это невозможно, потому что «country» является обязательным полем для «city».

Другой практический вопрос заключается в том, «как мне обеспечить соблюдение бизнес-правила о том, что в стране должен быть 1 и только 1 город по умолчанию»? Это легко сделать, создав «город по умолчанию» в качестве ненулевого поля для country, но трудно сделать с «is_default», являющимся атрибутом city — уникальный индекс в «country_id, is_default» означает, что в каждой стране может быть только один город по умолчанию, но не обеспечивает соблюдение правила, согласно которому их должно быть не менее 1.

Итак, ответ таков:

  • сначала выясните, что сообщает вам бизнес-домен.
  • сделать «is_default» атрибутом city практически проще всего, потому что вам не нужно беспокоиться о существующих городах при создании страны.
  • вам приходится иметь дело с бизнес-правилом, требующим, чтобы для каждой страны был ровно один город по умолчанию

Ответ №2:

В долгосрочной перспективе по мере развития использования хранение города в стране может оказаться не лучшим. Лучше иметь атрибут city. И затем вместо логического значения сделайте это кодом, где, скажем, 1 означает значение по умолчанию. Позже другие города могут начать нести другие атрибуты, такие как финансовый капитал, capital и т.д. Поэтому, вероятно, лучше предоставить городам их атрибуты.

Например, в компании есть сотрудники, и один сотрудник является генеральным директором. Поэтому лучше иметь заголовок employee в employee vs company, имеющий down entity of employee.

Также при создании записи о стране, поскольку городов еще не существует, вы не сможете создать запись. Вы оставите это поле пустым, создадите city, а затем вернетесь к установке по умолчанию.