Несвязанные таблицы и временные интервалы

Question

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

У меня есть следующие таблицы:

user (id, name, lastname)

role (id, name)

user_role (user_id, role_id, from_date, to_date)

period (id, name, from_date, to_date)

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

В этом случае я упоминаю только таблицы user, role и user_role, но есть еще много таблиц с периодами.

Цель таблицы периодов состоит в том, чтобы действовать как система маркировки для различных периодов, которые существуют в таблицах моей модели. Эта таблица никак не связана каким-либо внешним ключом с другими таблицами. Чтобы выполнить поиск и связать другие таблицы с этим, соединение выполняется с использованием дат от и дат до.

Например, кортеж таблицы user_role может иметь дату с и дату до тех пор, пока она не охватит несколько периодов, определенных в таблице периодов, поэтому она будет помечена именами периодов, которые она содержит.

Хорошо ли, чтобы таблица period была не связанной таблицей? Он служит только для присвоения названий периодам, поэтому я так выразился. Можете ли вы придумать другой лучший способ поднять его? Должна ли таблица периодов быть связана с другими таблицами каким-либо другим способом?

Заранее спасибо.

Answer 1

Вы делаете измерение времени в терминах хранилища данных. И вам не нужно иметь отношения с другими таблицами. Эта таблица используется только для поиска и может использоваться на основе интервала дат.

Answer 2

Итак, у вас есть две ситуации.

Ситуация первая, (внешний ключ) Вы ссылаетесь на период из другой таблицы. Допустим, таблица x ссылается на таблицу периодов через period_id , Если вам нужно обновить период для многих строк, которые используют один и тот же период, вам нужно обновить только одну строку в таблице периодов. Преимущество этого решения заключается в том, что если в таблице x имеется 1000 строк, относящихся к одному периоду, вам нужно только обновить период, а не 1000 строк. Кроме того, если несколько строк в нескольких таблицах ссылаются на один и тот же период, необходимо обновить только одну строку в таблице периодов. Недостатком является то, что если вы хотите, чтобы период отличался от существующих периодов, вы должны создать новый период и обратиться к периоду из таблицы x, а не обновлять только таблицу x.

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

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

Answer 3

Таблицы (базы, представления и результаты запросов) представляют отношения (связи). Ограничения FK (внешний ключ) иногда называют «отношениями (кораблями)», но это не так. Это констатация факта. Говорят, что в другом месте subrows появляются как PK (первичный ключ) или UNIQUE; что лица участвуют в другом месте один раз. Значения таблицы необходимы и достаточны для запроса. Ограничения - включая PK, UNIQUE, NOT NULL, CHECK & FKs - не являются ни необходимыми, ни достаточными для запроса. Они предназначены для обеспечения целостности СУБД. (Но когда ограничения сохраняются, дополнительные запросы возвращают те же результаты, что и запросы, которые не предполагают ограничения.)

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

Запрос и ограничения.

Answer 4

Вопрос о том, может ли таблица периодов быть несвязанной таблицей, наконец, является бизнес-вопросом и может отвечать только вам / вашим бизнес-требованиям ...;) Если, например, ваша роль пользователя относится к одному или нескольким периодам, должен быть FK в таблице ролей пользователя вместо начальной и конечной даты / или, если много ко многим - таблица отношений. Если определение периодов следует другому логике c и допускает перекрывающиеся периоды или асинхронные назначения от событий к датам / периодам, у вас все в порядке с несвязанными.

Answer 5

period относится к user_role, у них обоих есть столбцы from_date и to_date, которые относятся друг к другу.

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

Я не думаю, что есть лучший способ спроектировать это, так как ваши периоды произвольны и имеют отношение многие-ко-многим к вашим user_roles .