Комментарии 26
Мне кажется, или это статья о том, что преподается на 1 курсе любого вуза, есть в 1 главе любой книги по бд и тонне статей даже для самых маленьких?
Тут бы хоть про нормальные формы написать, чтобы помяснее было, но нет...
Написанный мною код должен работать и на других СУБД, поскольку запросы являются универсальными и не используют специфических конструкций языка T-SQL.
На самом деле это не так — как минимум nvarchar и identity будут не во всех СУБД.
Выбран очень странный стиль написания имён объектов — где-то используется схема, где-то не используется. ИМХО, в «справочном» посте стиль должен быть унифицирован.
Плюс, вы много где объявляете поле как nvarchar, а вставляете туда varchar — не надо так):
create table dbo.Person
(...
FirstName nvarchar(64) not null,
LastName nvarchar(64) not null,
...)
insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (5, 'John', 'Doe', 25)
Ещё хотелось бы добавить, что у явно объявленных связей есть определённые сайд-эффекты, о которых тоже хотелось бы получить информацию в таком «справочном» посте. Связи требуют определённой стратегии индексирования, которая зависит от предполагаемого использования данных.
Просто, в качестве примера, рассмотрим вот эту таблицу:
create table dbo.Phone
(
PhoneId int identity primary key,
PersonId int foreign key references Person(PersonId),
PhoneNumber varchar(64) not null
)
При удалении записи из таблицы Person будет происходить полное сканирование таблицы Phone — а это прямой путь к избыточным блокировкам и/или дедлокам.
На самом деле это не так — как минимум nvarchar и identity будут не во всех СУБД.
Убрал identity с глаз долой :)
nvarchar решил оставить, на сколько я знаю, в больших СУБД он есть. Даже если это не так, то думаю, что заменить тип не составит труда.
Выбран очень странный стиль написания имён объектов — где-то используется схема, где-то не используется.
Исправил — обращаюсь ко всем объектам через схему.
Плюс, вы много где объявляете поле как nvarchar, а вставляете туда varchar — не надо так)
Тоже исправил.
Ещё хотелось бы добавить, что у явно объявленных связей есть определённые сайд-эффекты, о которых тоже хотелось бы получить информацию в таком «справочном» посте. Связи требуют определённой стратегии индексирования, которая зависит от предполагаемого использования данных.
В ближайшее время немного подробнее опишу foreign key.
“Invalide” — не очень хорошее название для таблицы. Лучше “disability” или “employee_disability”. Звучит несколько более этично.
Спасибо, внес правки в статью.
Это для славян легко написать invalid\invalide для людей (или как в одной истории про дизайнера — он сокращал button до butt, и в проекте у него были цвета с размерами, так что даже дошло до black_big_butt), но для англоязычных это слова и у них есть свой смысл.
Интересно, что бы сказали, если бы в коде на 1С (кстати, а где еще в продакшене пишут по русски?) встретили «ВЫБЕРИТЕ ИМЯ ИЗ НЕВЕРНЫХ ГДЕ ВОЗРАСТ > 30» и т.д. (или если про дизайнера — увидев переменную «большая_черная_жопа» %) )?
PS: это я пытаюсь усилить вашу позицию, что оно не просто «звучит неэтично», на него все хорошо-англоговорящие сразу делают внутренний «эээээ, вы точно это имели в виду?» (так же как и хорошо-русскоговорящие на фразу иностранца «этот чурка»).
Связи один-к-одному не такие уж и редкие. На больших объемах данных возникает необходимость в вертикальном секционировании для ускорения работы запросов.
Если некий объект имеет множество атрибутов, часть из которых используется очень часто, а часть очень редко, целесообразно хранить их отдельно друг от друга, чтобы уменьшить расходы на чтение диска.
«вторичный ключ» перекликается с «альтернативный ключ» — по этому это название плохо применимо для «foreign key» = «внешний ключ».
Связи один-к-одному не такие уж и редкие. На больших объемах данных возникает необходимость в вертикальном секционировании для ускорения работы запросов.
Если некий объект имеет множество атрибутов, часть из которых используется очень часто, а часть очень редко, целесообразно хранить их отдельно друг от друга, чтобы уменьшить расходы на чтение диска.
Довольно-таки логично, спасибо за дополнение!
«вторичный ключ» перекликается с «альтернативный ключ» — по этому это название плохо применимо для «foreign key» = «внешний ключ».
Благодарю, заменил на «внешний ключ».
Статья явно не будет лишним для тех, кто только начинает проектировать схему БД, а также чтобы вспомнить некоторые моменты.
Однако, мне в ВУЗе долго не доходило какую связь использовать между сущностями (3 курс).
В итоге, пришло озарение, что все 7 формальных правил отношений между сущностями есть в жизни между людьми, предметами и т д и т п.
Т е по сути эти отношения были просто формализованы, а не придуманы человеком.
Ну в принципе как и многое мы берем из окружающего мира уже готовое и адаптируем под наши нужды. Вон тот же самолет похож на птицу. Ну грубо, но думаю идея понятна.
Так что если не удается понять технические детали-лучше посмотреть именно суть-что мы хотим сделать, а затем оглянуться вокруг и найти решение уже в этом реальном мире. После чего формализовать этот существующий процесс и адаптировать для достижения нужной цели. На сколько хорошо были проведены формализация и адаптация покажет время, а также необходимость как можно дольше кардинально не изменять созданное решение.
В итоге, пришло озарение, что все 7 формальных правил отношений между сущностями есть в жизни между людьми, предметами и т д и т п.
Т е по сути эти отношения были просто формализованы, а не придуманы человеком.
Ну в принципе как и многое мы берем из окружающего мира уже готовое и адаптируем под наши нужды. Вон тот же самолет похож на птицу. Ну грубо, но думаю идея понятна.
Довольно интересный подход!
Чем-то напоминает способ запоминания, когда изученный материал рассказываешь так, чтобы понял 8-летний ребенок.
На самом деле можно изучить что-то на следующих уровнях:
1) чтобы понять, но не смочь сделать
2) чтобы понять и сделать (обычно здесь останавливаются, т к дальше нет необходимости в работе)
3) чтобы обучить и передать знания и хорошо сделать
4) чтобы быстро и легко обучить и также передать знания, а также быстро и долговечно сделать
В статье не хватает акцента с необязательной и обязательной связью.
Всего в жизни 7 формальных правил, а именно:
1) один к одному с обязательной связью (у каждого гражданина РФ есть паспорт гражданина РФ и он только один)
2) один к одному с необязательной связью (у каждого человека может быть заграничный паспорт и если да, то только один)
3) один ко многим с обязательной связью (у каждого гражданина есть несколько документов, подтверждающих его личность)
4) один ко многим с необязательной связью (у каждого человека могут быть дети)
5) многие к одному с обязательной связью (у детей есть биологический отец/мать)
6) многие к одному с необязательной связью (у детей может быть отец/мать и если да, то только один/одна или сирота)
7) многие ко многим (женщины и мужчины-могут быть любовницами и любовниками причем не только относительно одного человека, а могут и не быть)
Причем отношения могут меняться-смотря как формализовать и для чего.
В этом весь фокус.
Т е можно взять детей и родитель (мама/папа)-если рассматривать без учета сирот, то связь будет обязательна, а если с сиротами-то не обязательна (многие к одному)
А вот если перевернуть: родитель (мама/папа) и дети, то необязательна-если допустить, что детей может не быть и обязательна, если дети точно есть (хотя бы один) (один ко многим).
Если же допустить в предыдущих вариантах, что ребенок может быть только один, то отношение станет 1:1 (с обязательной или необязательной связью соответственно).
А если рассмотреть вообще попечителей и детей, то получаем отношение многие ко многим.
Т е в принципе все 7 формальных правил действуют по отношении между одними и теми же сущностями. Важно формализовать ту, которая нужна для реализации (для достижения конкретной цели в предметной области).
И т д и т п
Большое спасибо!
jobgemws Извините, а разве пункты 3 и 5, 4 и 6 это не одно и тоже?
Уважаемый Bob_1, по проектированию БД опубликовал 7 формальных правил:
Основы правил проектирования базы данных
Связи между таблицами базы данных