В итоге, пришло озарение, что все 7 формальных правил отношений между сущностями есть в жизни между людьми, предметами и т д и т п.
Т е по сути эти отношения были просто формализованы, а не придуманы человеком.
Ну в принципе как и многое мы берем из окружающего мира уже готовое и адаптируем под наши нужды. Вон тот же самолет похож на птицу. Ну грубо, но думаю идея понятна.
Довольно интересный подход!
Чем-то напоминает способ запоминания, когда изученный материал рассказываешь так, чтобы понял 8-летний ребенок.
На самом деле это не так — как минимум nvarchar и identity будут не во всех СУБД.
Убрал identity с глаз долой :)
nvarchar решил оставить, на сколько я знаю, в больших СУБД он есть. Даже если это не так, то думаю, что заменить тип не составит труда.
Выбран очень странный стиль написания имён объектов — где-то используется схема, где-то не используется.
Исправил — обращаюсь ко всем объектам через схему.
Плюс, вы много где объявляете поле как nvarchar, а вставляете туда varchar — не надо так)
Тоже исправил.
Ещё хотелось бы добавить, что у явно объявленных связей есть определённые сайд-эффекты, о которых тоже хотелось бы получить информацию в таком «справочном» посте. Связи требуют определённой стратегии индексирования, которая зависит от предполагаемого использования данных.
В ближайшее время немного подробнее опишу foreign key.
Связи один-к-одному не такие уж и редкие. На больших объемах данных возникает необходимость в вертикальном секционировании для ускорения работы запросов.
Если некий объект имеет множество атрибутов, часть из которых используется очень часто, а часть очень редко, целесообразно хранить их отдельно друг от друга, чтобы уменьшить расходы на чтение диска.
Довольно-таки логично, спасибо за дополнение!
«вторичный ключ» перекликается с «альтернативный ключ» — по этому это название плохо применимо для «foreign key» = «внешний ключ».
Здравствуйте! Статья оригинальная и не была взята из какой-то методички или книжки. В ней я хотел рассказать свое виденье темы и максимально просто ее объяснить, без всяких заумных терминов. На Хабре я не нашел похожих статей, потому решил написать свою, посколько я считаю, что понимание связей между таблицами очень важно при проектировании бд.
Большое спасибо!
Довольно интересный подход!
Чем-то напоминает способ запоминания, когда изученный материал рассказываешь так, чтобы понял 8-летний ребенок.
Убрал identity с глаз долой :)
nvarchar решил оставить, на сколько я знаю, в больших СУБД он есть. Даже если это не так, то думаю, что заменить тип не составит труда.
Исправил — обращаюсь ко всем объектам через схему.
Тоже исправил.
В ближайшее время немного подробнее опишу foreign key.
Довольно-таки логично, спасибо за дополнение!
Благодарю, заменил на «внешний ключ».
Спасибо, внес правки в статью.
Планирую написать отдельную статью по ним. Мне кажется, что впихнуть их сюда это будет лишним, потому что статья именно про связи.