SuperNickВопрос – все же лучше кое-где использовать составные ключи или при первой же возможности вводить для сочетания столбцов свое уникальное значение (типа счетчика) и использовать в качестве ключа уже его?С логической точки зрения нет никакой необходимости в замене составных ключей на "простые", состоящие из одного поля. С физической точки зрения, это может позволить иногда сократить объем БД и упростить написание запросов, так как понадобиться указывать меньше условий связи для сливаемых таблиц. Тем не менее, такой подход может вызвать снижение производительности, так как в случае составных ключей вы получаете возможность параллельного слияния иерархически зависимых таблиц.
Пример: в случае "простого" ключа такое слияние должно выполняться последовательно, так как данные для "деда" о "внуке" вы сможете получить только через "сына", и наоборот. В случае составного ключа, "внук" уже знает код "деда", что позволяет избежать лишнего слияние с таблицей-посредником("сыном"/"отцом"), либо, если в запросе требуется информация и о "посреднике", дает возможность выполнять независимого слияния с обоими предками параллельно, что может способствовать росту общей производительности.
В то же время, неплохо бы провести сравнения производительности типовых запросов в вашей конкретной ситуации, так как выигрыш/проигрыш обоих вариантов может быть практически неощутим и тогда на первое место может выйти более простой для понимания/программирования вариант, но это будет уже вашим индивидуальным выбором. Лично я предпочитаю разумное использование составных ключей бездумному использованию простых.

iscrafmвводите "бездумно" :) сурогатный ключ и не напрашивайтесь на проблемы с модификацией. Если конечно нет "разумного" желания по всей иерархии менять коды, если кому-то вздумается заменить код владельца.Или я не понял вашей глубокой мысли, или вы что-то путаете. Суррогатный ключ никак не является альтернативой составному, так как последний совсем необязательно построен на естественных ключах, а вполне даже на суррогатных, и он совершенно не становиться от этого естественным. А насчет каскадности, выигрываете в одном, проигрываете в другом. Именно этим и надо руководствоваться при выборе ключей в конкретной ситуации, а не категоричными советами, подобно вашему. Следуя ему буквально, можно получить вполне даже осязаемое падение производительности в результате излишнего "утяжелению" БД кучей совершенно ненужной избыточной информации в виде суррогатных значений, не несущих никакого иного смысла, кроме дополнительной идентификации сущности.

apapacyОтветьте на простой вопрос. Что является избыточным? Добавить в таблицу суррогат BIGINT и ссылаться на этот BIGINT во всех связанных таблицах - или хранить естественный ключ (char(100), char(100)) и таскать его за собой во все связанные таблицы?Ответьте на простой вопрос. Вы только писатель или читать тоже умеете ? Раз у вас вопрос ко мне, то еще раз, и внимательно, прочтите, что я писал по теме выше. И, надеюсь, тогда вы сами сможете ответить на свой вопрос.

P.S. На всякий случай напомню тему топика, если ее случайно не заметили: речь идет о составных ключах vs простых, а не о естественных vs суррогатных.

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

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

ModelRБеда в том, что выбор идентифицирующая/неидентифицирующая не диктуется природой данных. В частности, чему противоречит неидентифицирующая связь документа с его явно присутствующим в отдельнойтаблице типом?Разумеется, она диктуется в первую очередь моделью, которую мы строим. Мне казалось, что я это подчеркнул. Данные вне системы их интерпретации сами по себе ничего не значат. Если тип документа не является определяющей сущностью для документа, то вполне может быть и неидентифицирующая связь. С другой стороны, такое достаточно безболезненно возможно только если состав и смысл атрибутов документов совпадает. В противном случае, можно получить неоднократно упоминаемый в этом топике геморрой, но уже не мнимый, а совершенно явный, когда атрибуты документа перестанут соответствовать типу документов. Впрочем, мы, IMHO, уже начинаем все сильнее отходить в сторону от основной линии топика.
Для топикстартера, как мне кажется, пока это не важно, так как он, если правильно понимаю, пытается разобраться на некоей абстрактной модели. Хотя по хорошему, конечно, надо рассматривать эти вопросы без отрыва от конкретной ситуации.
Сергей ВаскецовВы утверждаете, что поле(я) ссылки на заголовок документа в таблице строк состава документа обязательно входит(ят) в первичный ключ таблицы строк состава документа?При традиционном, реляционном, подходе и наиболее распространимой модели учета, должна входить, так как позиция является сущностью целиком и полностью зависимой от документа. Но, по большому счету, никто не мешает исключить идентификатор документа из первичного ключа позиции, а сделать неидентифицирующую связь, воспользовавшись хотя бы, ранее упомянутым "правилом 99%". В результате, первейшим кандидатом на первичный ключ скорее всего станет суррогатный ключ, необходимость которого совсем не очевидна.
Насколько мне известно, к такому подходу нередко склоняются, когда поверх реляционной модели сначала пытаются построить универсальную объектную(фреймворковую) модель, которая обычно подразумевает обязательность уникального идентификатора для любого "объекта", и на которую, в свою очередь, "натягивают" уже предметную область. Но это уже офтопик и здесь не вижу смысла углубляться в него дальше.
Какие еще, по вашему, есть вменяемые причины, которые могуть побудить исключить идентификатор документа из первичного ключа его позиции("строки состава"), кроме упомянутых здесь ранее.

Сергей ВаскецовС моей точки зрения все наоборот. Не вижу вообще причин в данном случае пихать в PK детали ссылку на мастера.Убедительно. Не пихайте.

Сергей ВаскецовНе очень понимаю, что значит выделенное. Давайте на примере попроще.
Как по-Вашему, в составе документа в БД могут быть идентичные строки (с одной ценой, номенклатурой и т.п.), как их тогда различать? Предложите свой вариант PK для строки состава документа, обсудим, в частности, как ссылаться на такие строки.Уж куда проще-то ? Если честно, то мне уже надоедает говорить о вполне очевидных вещах, тем более многое уже сказано выше, но вы, похоже, это пропустили и просто зацепились за одну из фраз. Последний раз.
Это азы РМД. Любая сущность должна иметь первичный ключ, и этот ключ должен позволять однозначно определять ее как в БД, так и в "реальном" мире, иначе вы не просто сможете их отождествить, а соотвественно, грош цена тем данным, которые непонятно какую сущность описывают. Т.е., "естественный" ключ должен быть всегда, другое дело, что по вполне очевидным причинам мы, как правило, делаем его альтернативным, а вместо него делаем суррогатный, который всегда остается внутри системы. Для зависимых сущностей этот ключ будет составным, именно потому, что они зависимые и, вообще говоря, не могут существовать вне сущности "родителя", поэтому к идентификатору сущности "родителя", добавляется идентификатор этой сущности в рамках родителя.
Я не знаю, как еще объяснить, что позиция счет-фактуры, например, сама по себе не существует, если нет счет-фактуры, ее содержащей. И эта позиция обязательно чем-то отличается от других ей подобных в этом документе. В простейшем случае, это ее номер. Именно он позволяет вам качать права, если поставщик вам недопоставил товар. Вы тыкаете поставщика носом в эту строку и говорите, вот по этой позиции мне недодали. Не в суррогатный идентификатор, которого вообще не представлен, я надеюсь, в распечатанном документе. В некоторых случаях, это может быть код товара, например, если таковы принятые правила игры в данной фирме. Соотвественно в таком документе не может быть двух позиций содержащих один и тот же товар. Предлагаю не обсуждать целесообразность такого подхода, это всего лишь один из возможных вариантов. Но в любом случае, есть поле, комбинация полей, которые позволяет явно отличить одну строку от другой в данном документе, как внутри БД, так и вне ее, причем сделать взаимооднозначное соотвествие. Естественно, мы исходим из того, что позиция обычно принадлежит только одному документу, а не нескольким одновременно. Определяя для нее простой "сквозной" суррогатный ключ в общем случае вы добавляете совершенно ненужные данные не считая того, что отсутствие идентификатора документа в первичном ключе может привести к тому, что позиция может быть легко приписана другому документу, так как идентификация позиции перестает зависеть от документа. Более-менее разумные причины все-таки добавлять такой суррогатный ключ уже упоминались в этом топике ранее.

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

guest_20040621Азы РМД, дружище ChA, никак не связаны с Вашей интерпретацией этих азов. Написанное Вами про составные ключи - чушь.Да, да, я в курсе. Право, не стоило беспокоиться. Когда захотите сказать нечто более существенное, с удовольствием почитаю.

apapacyЕсли документ "проводится/перепроводится/отменяется" и имеется на него ссылка в регистре/регистрах с привязкой по строкам документа. Как Вы посоветуете поступать? Хранить в регисте ссылку на (№документа, №строки) или вводить суррогат?Об этом уже неоднократно было сказано выше. Хотите проще, добавляете для строки суррогатный ключ и ссылаетесь на нее, не хотите - используете составной ключ, который может принести некоторые дивиденды. Хотя я, скорее, пересмотрел бы модель, неидентифицирующие ссылки на зависимые объекты меня обычно настораживают. Возможно есть более приемлимое решение.

guest_20040621Ну в общем, ничего другого и не ожидалось. Как обычно, никаких внятных аргументов. Соответственно, отсутствует смысл дальнейшего общения.
И что Вы здесь-то побираетесь ? Хотите заработать, предложите свои услуги на форуме "Работа". Уверен, Вы будете пользоваться там большим успехом.

Сергей ВаскецовПроще были бы DDL-ки табличек заголовка, состава и, например, налогов по строке состава, которые ссылаются на состав (если по Вашей логике налоги "захардкодены" прямо в строке состава - не беда, придумайте сами любую табличку, которая бы ссылалась на строку состава и на любой другой совершенно "левый" справочник). А мы бы рассмотрели. А то все такие теоретики, аж жуть.Лучше пообщались бы с топикстартером, если вам есть что сказать. А я вам ничем не обязан, по большому счету, поэтому какие-либо требования или претензии ко мне неуместны. Сергей ВаскецовНа кой, простите, требовать от PK идентификации объекта в реальном мире? И вообще, где это написано?Пожалуйста, не вырывайте фразы из контекста, читайте внимательнее и желательно вдумываясь в общий смысл. Сергей ВаскецовА Вы уверены, что оно всегда мне надо? Как пример в Вашем случае, контроль уникальности №пп я вполне могу оставить до момента утверждения документа, а не выдумывать жесткие констрейнты и затем яростно обходить их при необходимости банального копирования строки. Или просто в ситуации, когда софт установлен у большого количества заказчиков, имеющих различное представление о том, какая же все-таки комбинация полей является уникальной в составе документа.Можно придумать еще много разных эмоциональных ситуаций и что дальше ? Не надо, не делайте, другими словами это уже предлагалось ранее. Сергей ВаскецовКто Вам сказал такую глупость? Есть множество ситуаций (некоторые я привел выше в этом же сообщении), когда никакой естественный ключ на таблице не может существовать как декларативное ограничение.Внимательно перечитал, увидел только надуманные проблемы реализации. Совершенно не обязательно моментальная фиксация изменений в БД в процессе редактирования объекта. Как правило, она выполняется в тразакции по окончании редактирования. А теперь попробуйте ответить себе сами, как пользователь отличает одну позицию от другой ? По суррогатному ключу ? Сергей Васкецов ChAДля зависимых сущностей этот ключ будет составным, именно потому, что они зависимые и, вообще говоря, не могут существовать вне сущности "родителя"Опаньки! То есть, в PK включаются как минимум все обязательные поля в таблице?Хоть убейте, не понимаю логики, которая привела вас к такому выводу.
Сергей Васкецов ChAпоэтому к идентификатору сущности "родителя", добавляется идентификатор этой сущности в рамках родителяВопрос в целесообразности такого включения, а не в том, что если к PK добавить еще и ссылку на родителя, он останется не менее уникальным, чем был PK.Безусловно. Аргументы для включения, как и против, были рассмотрены ранее. Похоже все-таки просто зацепились за фразу и таки не удосужились прочитать топик с начала. Сергей ВаскецовЕсли ее (строки состава без заголовка) нет в реальном мире, то это не значит, что в БД не может быть связи, в которой на заголовок вообще пофигу и нет необходимости учитывать, что он должен быть. Как раз наоборот, раз есть строка состава, то и заголовок есть, так как ссылка на заголовок в составе - обязательное поле.Или я вас не понимаю, или вы сами себе противоречите, но никак не мне.
А строка существует в реальном мире, как только пользователь ее ввел. Может ее еще и нет в БД, но на экране она точно присутствует. И пользователь прекрасно отличает одну похожую строчку от другой. Всего и надо-то понять, каким образом он это делает.
Сергей Васкецов ChAИ эта позиция обязательно чем-то отличается от других ей подобных в этом документе.В простейшем случае, это ее номерПока документ в БД не утвержден, с ним можно делать почти что угодно, и в первом приближении не очевидно, что дял копирования строк состава необходимо уметь на лету править №пп.Забавно, сами же себе ответили на свой же, поставленный выше, вопрос. И, что характерно, он не сильно отличается от моего. Сергей Васкецов ChAВы тыкаете поставщика носом в эту строку и говорите, вот по этой позиции мне недодалиПодозреваю, в такой иллюзорной ситуации (разборки на основании счета-фактуры, а не счета или накладной) используется вовсе не №пп строки состава документа в БД, а то, что на бумажном носителе. У нас №пп хранится в строках состава и им можно управлять, хотя я вполне допускаю, что №пп может формироваться у кого-то только при печати.И что у нас на бумажном носителе ? Я предполагаю, что строки, выведенные в определенном порядке, который однозначно можно восстановить по БД. Хотя для меня лично выглядит несколько абсурдно появление в одной СФ(или накладной) нескольких абсолютно идентичных строк, различающихся, например, только количеством, или только ценой. Если, например, это один и тот же товар, то разумного объяснения такого разбиения я не нахожу. Интересно также, как будут выдавать товар в подобной ситации. Типа, чешем в затылке, потом говорим, это вот из этой кучи, а это из вон той ? Сергей Васкецов ChAНо в любом случае, есть поле, комбинация полей, которые позволяет явно отличить одну строку от другой в данном документе, как внутри БД, так и вне ее, причем сделать взаимооднозначное соотвествиеВо-первых, вообще говоря, неочевидна сама необходимость идентификации строк в БД теми методами, которые Вы предлагаете. Как минимум, потому что, во-вторых, не очевидно, что идентификация "как внутри БД, так и вне ее" должна быть одинаковой; почему бы не иметь различную идентификацию "как внутри БД, так и вне ее"? И уж совсем не понятно, зачем необходимо "взаимооднозначное соотвествие".Вполне возможно, об этом также упоминалось, но вот как вы собираетесь обойтись без соответствия я не понимаю. Данные в БД отражают некую модель реальной жизни, а не находятся в БД сами по себе. Они могут не соотвествовать реальной картине, но тогда, простите, какой в них смысл, кроме задач тестирования производительности СУБД, например ? Сергей ВаскецовДанные в БД можно испоганить множеством способов, изменить ссылку на заголовок в составе - далеко не самый нетривиальный из них.Совершенно верно. Поэтому, если есть возможность избежать их хоть в малейшей мере( смотрите замечания ModelR по поводу составных ключей), то почему бы этого не сделать ?

ModelR ChA Любая сущность должна иметь первичный ключ, и этот ключ должен позволять однозначно определять ее как в БД, так и в "реальном" мире, иначе вы не просто сможете их отождествить, а соотвественно, грош цена тем данным, которые непонятно какую сущность описывают. Везет же людям. А мне почему-то некоторые нехорошие сущности совсем ничего должны :(.Ну Вы-то хоть не отрывайтесь от контекста. Вот вам простой пример. Берем 10 болванок и записываем на них, например, разную музыку. А теперь вы хотите сохранить информацию в вашем каталоге(БД). Каким образом Вы сможете потом однозначно идентифицировать какому диску в каталоге соответствует реальный диск ?
proposed amendmentкогда мне нужно идентифицировать объект реального мира я вешаю на него инвентарный номер, а не пытаюсь засунуть его целиком в БДВот про это и речь. Самый простой способ решения предыдущей задачи - подписываем диск. Вот вам и первичный ключ в реальном мире. В противном случае, вам придется тупо перебирать все диски на предмет соотвествия содержимого записи в каталоге, что, кстати, тоже может играть роль первичного ключа, пусть и не очень эффектвного.

P.S. У меня такое впечатление, что все только и заняты вылавливанием конкретных фраз, вместо того, чтобы понять, о чем речь.

ModelRДык в простом примере конечно все просто.Так я и повторял неоднократно о том, что решается все в каждом конкретном случае, учитываются все плюсы и минусы того или иного решения. Ну нет универсальных рецептов, типа, вводи суррогатные ключи и хаос исчезнет. Да никуда он не денется.
ModelRА вот если диски вдруг обретут волю и способность менять присвоенные им метки самостоятельно? Или менее фантастический вариант - мы не застрахованы от изменения меток кем-то третьим?Если нет способа их идентифицировать, то какой тогда толк от информации в БД ? Что она описывает ? Вы будете вынуждены снова идентифицировать их тем или иным образом. А если информация в БД не будет коррелировать с доступной на диске, например, диски - RW. Какой смысл от каталога ? Что когда-то были диски с какими-то метками и там содержалось какая-то информация ? А насколько правдоподобна эта информация ? Ведь проверить, опять же, нельзя.
Вообще, здесь можно накрутить много фантастических и не очень ситуаций, но в любом случае смысл информации в БД теряется, если ее невозможно отобразить на то, ради чего она создавалось. Собственно, эту несложную мысль в последних постах я и пытался донести. Я полагал, что она очевидна, но создается впечатление, что большинство наоборот занимаются сферическими конями в вакууме, которые к реальности не имеют ни малейшего отношения.
ModelRНаконец вот . Для системы выглядит как таблетки самопроизвольно меняют свое наименование.Это обычные ошибки, которые исправляются в рабочем порядке, включая массу действий, в том числе и организационного характера. Уже давно сказано, что автоматизация хаоса не делает хаос упорядоченным. Но даже в этом примере можно увидеть, что возможность взаимоднозначного отображения все-таки осталась. Если бы ее не было, то БД можно было бы смело стирать, потому что от нее уже не было бы никакой пользы, по крайней мере той, ради которой она создавалась.