Книга: «Антипаттерны SQL. Как избежать ловушек при работе с базами данных»

[savostin]

SELECT c.*, COALESCE(b.description, f.description) AS description,

Это ж только если description и прочие is not null. Иначе вернет одно поле из одной таблицы, а второе из другой. Правда только если записи есть в обеих. Но все равно что-то неправильно выглядит

[Akina]

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

Безобразное решение. Вот стоило так долго обсуждать штатные средства поддержания ссылочной целостности и непротиворечивости, чтобы в конце их благополучно похерить?

Уж лучше бы соответствующие триггеры написали... но фреймворк, как обычно, этого не умеет. Он только себя полагает всеумелым и безгрешным, а БД - это так, коробка для данных.

[miksoft]

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

В хранилищах являются нормой базы без внешних ключей, даже если они поддерживаются технически в используемой СУБД. Тег Big Data же не просто так?

[AKimovd]

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

[Akina]

В хранилищах являются нормой базы без внешних ключей

Вопрос цены. Контроль всё равно нужен. А раз не используется контроль на стороне хранения - значит, он будет на стороне обработки. Если система обработки аппаратно позволяет кэшировать объём данных, достаточных для такого контроля (обеспечивающих высокий процент попадания) - всё в порядке. А если нет - то между хранилищем и обрабатывалищем начнут бессмысленно курсировать мегатонны данных. И чтобы система не встала колом, на неё придётся опять доставить оперативки... вопрос цены.

[Naf2000]

В 1С есть регистр сведений ПубличныеИдентификаторыСинхронизируемыхОбъектов, призванный для сопоставления сущностей текущей и внешних систем. И в нем есть поле Ссылка - которое может принимать значение практически любой сущности.
Если избавляться от данного антипаттерна - придется завести глобальную таблицу, куда будут писаться все сущности и ссылаться на нее?

[titan_pc]

Школьный уровень. 1й класс

[VanShi87]

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

Я считаю, must have

[vagon333]

CREATE TABLE BugsComments ( ... PRIMARY KEY (issue_id, comment_id), ...);

Несмотря на разумное решение с composite primary key в M:M junction table (issue_id, comment_id), все равно в своих дизайнах схемы настаиваю на правиле - первичный ключ должен быть всегда int/bigint (в данном случае bug_comment_id).
Согласен, лишнее поле, но в своих решениях не допускаю Primary Key Composition.

[FlyingDutchman2]

в своих решениях не допускаю Primary Key Composition

Почему?

[Sergey_VR]

Присоединяюсь. Почему?

[Akina]

настаиваю на правиле - первичный ключ должен быть всегда int/bigint 

То есть использование в качестве первичного ключа GUID, что сейчас достаточно модно, по вашему мнению - bad practice?

[Sergey_VR]

Интересная книга. Первая глава не впечатлила (про идентификаторы в строке), но вторая (про деревья) уже существенно интересней. Таблицу замыканий взял на заметку, для сложных случаев может подойти...