Почему у вас соотношение 1: 1 - дизайн базы данных?

Question

Я смотрю на существующую схему базы данных, и я немного запутался в отношении 1: 1 realtionship в примере ниже:

Event 
----- 
id int (PK) 
Title varchar 
Description varchar 
OrganizerId int (FK) 


EventSchedule 
------------ 
id int (Pk) 
EventId int (FK) 
Start datetime 
End datetime 
RepeatRule varchar (ical format for repeating events) 

Venue 
----- 
id int (PK) 
EventId (FK) 
Name varchar 
Address1 varchar 
Address2 varchar 
City varchar 
Region varchar 
Postcode varchar 
latitude float 
longitude float 

Событие только когда-либо происходит в одном месте, так что есть 1 : 1 между Событием и Местом. Аналогично, событие имеет отношение 1: 1 к EventSchedule - правило повторения повторяет повторяющиеся события.

Будет ли какая-либо причина или экземпляр для разделения таблиц как это? Что было бы неправильно в том, одну таблицу следующим образом:

Event 
----- 
id int (PK) 
Title varchar 
Description varchar 
OrganizerId int (FK) 
Start datetime 
End datetime 
RepeatRule varchar (ical format for repeating events) 
Venue varchar 
Address1 varchar 
Address2 varchar 
City varchar 
Region varchar 
Postcode varchar 
latitude float 
longitude float 

Некоторые советуют на плюсы/минусы каждого проекта будут оценены именно в этом контексте, чтобы сделать схему достаточно гибкими для любого дальнейшего рассмотрения, хотя я могу» возможно, подумайте о какой-либо причине, когда вышеупомянутые отношения будут когда-либо изменяться в реальном мире, например, с 1: 1 до 1: N и т. д.

Answer 1

Две причины, по которым я могу думать, нормализовать таблицу таким образом:

1. У вас есть ORM, который работает на EventSchedule/Venue, и только редко вас интересует название события, например
2. Миграции быстрее. Подумайте, что у вас есть 1M строк, и вам нужно добавить еще одну строку в таблицу событий из предлагаемого решения. Ваша миграция заблокирует таблицу в течение очень долгого времени. Миграция таблиц с меньшим количеством строк выполняется быстрее.

Answer 2

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

Еще одна причина для разделения заключается в том, что у вас есть отношения «один к одному», но кто-то может планировать будущее, если у вас нет отношения «один к одному». Я, конечно, видел такие вещи, когда события находятся в нескольких местах и ​​имеют несколько графиков.

И поскольку площадки, вероятно, будут повторно использоваться для разных событий, я бы разработал таблицу места и таблицу EventVenue, чтобы избежать повторения всех адресов и данных GPS.

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

Еще одна причина для разделения состоит в том, что многие люди предпочитают моделировать, основываясь на том, что логически падает.

Еще одна причина для разделения состоит в том, что таблицы с меньшей шириной имеют тенденцию быстрее запрашивать (особенно если вам не нужно всегда запрашивать другую информацию), и иногда все поля вместе составляют таблицу, которая чем эффективный размер строки для записи SQL Server. Если выполняется максимальный размер каждого поля, что может привести к тому, что вы не сможете добавить эти записи в эту таблицу, даже если SQL Server позволит вам создать его.

Answer 3

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

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

Answer 4

Еще одна причина: в архитектуре микросервиса у вас может быть несколько служб, каждый из которых несет ответственность за различные действия, такие как события и расписания.

Каждый из них был бы лучше изолирован, если бы у них были свои собственные таблицы, с обменом сообщениями между службами, используемыми для связи требуемых данных.