Три задачи требований к данным

[Akina]

Первичные ключи помечаю 🔑, внешние — 🔐.

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

Вообще в этой схеме нет места много чему. Например, совершенно непонятно, где описываются триггеры и вообще хранимые объекты. Или как описывать DEFERRED бизнес-правила.

[vpgromov]

Составной первичный ключ — несколько полей с 🔑. Если поле одновременно является частью первичного ключа и внешним ключом — ставлю оба: 🔑🔐. В моей практике такие случаи встречаются, и нотация с этим справляется.

По триггерам и хранимым объектам — в моих проектах они не используются, поэтому в шаблоне их нет. Как и написал в статье, шаблоны заточены под мой контекст — PostgreSQL, достаточно стандартные реляционные схемы. Для проектов со сложной логикой на уровне БД шаблон нужно расширять.

[Akina]

Если поле одновременно является частью первичного ключа и внешним ключом — ставлю оба: 🔑🔐. В моей практике такие случаи встречаются, и нотация с этим справляется.

Гм... пример.

field0 🔑

field1 🔑🔐

field2 🔑🔐

Понятно, что тут составной ключ. Но вот теперь скажите - у меня один внешний ключ из 2 полей или 2 внешних ключа? По вашей нотации пока получается, что оба варианта дают одно и то же показанное мной описание.

[vpgromov]

В таблице эти обозначения — маркеры, для быстрого чтения. Мы понимаем, что они участвуют во внешнем ключе. Но как конкретно — описывается в отдельном разделе "Ключи и связи". На самом деле, не могу утверждать, насколько это понятно и не запутывает ли разработчиков. С таким на практике не сталкивался. Но всегда есть уточнение в нижнем разделе, которое дает понять, как именно ключи связаны.

То есть, если у нас будет составной внешний ключ, мы запишем как-то так:

## Ключи и связи

* 🔑 Первичный ключ: (field0, field1, field2)
* 🔐 Внешние ключи:
  * (field1, field2) → other_table.(id1, id2)

А если они разные, то:

* 🔐 Внешние ключи:
  * field1 → table_a.id
  * field2 → table_b.id

[Akina]

Ааа, вот оно чё, Михалыч...