Ivan ShkuropadskyПоявилась необходимость ввести такой атрибут "Организации" как "Основной телефон". Соответственно, для этого в таблицу "Организации" добавляется ссылка на запись дочерней таблицы "Телефоны". А поскольку первичный ключ у "Телефонов" составной, то получается нечто странное и некрасивое:

"Организация" ссылается на "Телефон", который зависит от "Организации".

И вот получается, что внешний ключ "Организации" так же как и первичный "Телефонов" тоже должен состоять из двух полей.... Но какой смысл в таблице "Организации" иметь свой собственный ID в составе внешнего ключа....А в чем трагедия-то ? Как раз это и является гарантией, что основной телефон будет принадлежать именно этой организации, а никакой другой. Так что нет повода к панике, все нормально.
А вот если сделать телефоны независимой сущностью с собственным идентификатором, то организации можно будет привязать в качестве основного любой телефон, даже никак не относящийся к этой организации. Или придется контролировать корректность номера кодом в тригере или процедуре.

P.S. IMO, предпочтительнее контролировать корректность данных стандартным механизмом СУБД с помощью внешних ключей. Не надо бояться составных ключей.

mcureenabChA,
нехорошесть в том, что придётся сначала создать организацию, потом прописать к ней телефоны, а потом в организации указать основной телефон. Т.е. в транзакции как минимум лишний update нужен, а то ещё и запрос к телефонам за ID основного, или такая экзотика, как отложенная проверка ограничений целостности.А зачем собственно ? Ссылка на телефон запросто может быть nullable, в постановке явно не указывается наличие основного телефона в организации. Посему необходимость в столь длинной транзакции или отложенной проверки не очевидна. Но если уж номер указан, то обязан принадлежать этой организации, что и будет контролировать составной внешний ключ.
Хотя, честно скажу, пока писал предыдущий пост, также склонялся к варианту с дополнительной таблицей. Он, IMO, лучше всего соответствует озвученной постановке проблемы.
mcureenabПоиск по основному номеру будет очень неэффективным, поскольку для определения этого признака придётся заглядывать в "Организации" (или наоборот, перебирать все организации и смотреть какие у них основные телефоны).Вы же не считаете все запросы в которых участвует больше одной таблицы неэффективными ? При нормальной нормализации, простите за тавтологию, таких запросов большинство. К тому, что не увидел сути проблемы, что куда-то надо будет "заглядывать", так как в большинстве случаев это приходиться делать всегда.
mcureenabВидимо от таблиц нужно подняться на более высокий уровень абстракции и повторно выполнить нормализацию и поосторожнее обходиться с сурогатными ключами.При условии, если мы начнем расширять постановку задачи, например, в сторону ранжирования телефонов. Пока она не кажется очевидной.

mcureenabChAНо если уж номер указан, то обязан принадлежать этой организации, что и будет контролировать составной внешний ключ.Если этот признак в таблице "Телефоны", то принадлежность телефона организации выполняется автоматически без каких либо вспомогательных FK и проверок.Правильно, но тогда могут быть нарушены другие условия. От отсутствия основного номера, что по постановке не страшно, до того что все существующие могут стать основными, что явно некорректно. Декларативным механизмом стандартных ограничений СУБД уже сложно выразить наличие только одного(!) основного номера, посему контроль придется переложить на некий исполняемый код. Не то, чтобы это смертельно, но, IMO, где можно обойтись без него, лучше обойтись.
В некоторых СУБД в CHECK можно использовать запросы, но всё равно вариант с полем "основной" в таблице телефонов мне кажется сомнительным. Бросается его явная избыточность, из множества телефонов только один является основным, но признак присутствует у всех. Таким образом вариант с отдельной таблицей "основной номер организации" считаю наиболее правильным.
mcureenabChAК тому, что не увидел сути проблемы, что куда-то надо будет "заглядывать", так как в большинстве случаев это приходиться делать всегда.В данном случае есть простое решение, которое позволяет не делать лишних движений. Довольно странно плодить "тяжёлые" запросы только потому что в системе таковые уже имеются.Честно говоря уже перестал понимать, о каком множестве "тяжелых" запросов идет речь. Пользователю не нужны идентификаторы организации и телефонов, а то, что за ними стоит, т.е., наименование организации и номер телефона в его естественной форме. В таком случае, с учетом раздельности сущностей организации и телефонов, слияние между ними придется делать по любому. А вот если номер телефона ввести в основной ключ таблицы телефонов(ид_орг,номер), то, при обратной связи в таблицу организаций, номер в своём естественном виде и так будет представлен в таблице организаций, что как раз и удовлетворяет пожелание избегать любых мало-мальских осложнений при выполнении запросов.

guest_20040621Я знаю два типа логики: Галилея и Аристотеля. Боюсь, MasterZiv, оба прошли мимо Вас.Судя по лёгкости перехода на личности, рядом с Вами они тоже не задерживались. Отсутствие логики и вменяемых аргументов всегда можно заменить оскорблениями.
Непонятно, зачем временами прикрываетесь Дейтом, он ведь тоже типичный баран. И вместо железной уверенности, что основной ключ может быть только атомарным, блеет какую-то ерунду про фунциональные зависимости подмножеств атрибутов и выбор основного ключа из множества потенциальных.

guest_20040621Дружище, задолбало, когда одни и те же люди дают одни и те же идиотские советы.Меня тоже, дружище. Один и тот же участник нередко несёт откровенный вздор без всяких пояснений. Вероятно, считает категоричность достаточным критерием истины. Сдается, мне, что кто-то сильно его обманул. То ли Галилей, то ли Аристотель.guest_20040621Проблема в том, что он пишет для баранов, его работа так и называется "Введение...". Понимаете? Т. е. он очень доступно излагает примитивные вещи, чтобы бараны получили хотя бы поверхностное представление о проектировании. Соответственно, примеры из его работы носят исключительно теоретический характер. И если бы бараны внимательно читали Дейта, то безусловно обратили бы внимание на требование независимости ключа.Браво. В то время как Дейт рассуждает о подмножествах ключевых и неключевых атрибутов, нормализации и функциональных зависимостях, активно пользуясь примерами с составными ключами, некто из независимости ключа легко выводит его атомарность. Аристотель с Галилеем в этот момент явно были в другом месте.guest_20040621объясните, почему при проектировании баз данных следует использовать логику в интерпретации Галилея, а не Аристотеля. Опционально: в чем с точки зрения проектирования заключается принципиальная разница между логикой Аристотеля и логикой Галилея?Если этот вопрос Вас действительно сильно беспокоит, то настоятельно рекомендую погуглить, можете даже начать с Википедии. Доступно излагаю ? Сами справитесь ? Потом доложите. Ну, а если не одолеете, ничего страшного, просто не чешите, само пройдёт.

guest_20040621ChA, дружище, Вам даже Дейта читать рано, несмотря на то, что он пишет очень просто. Начните с логики. Любой.guest_20040621, дружище, если судить по дефектам Вашей, то читать вообще вредно. Хотя, надеюсь, что выборка непредставительная и просто имеет место индивидуальная непереносимость.guest_20040621Дорастете до пояснений - получите их. Пока просто читайте.Дружок, от Вас никто никогда ничего не получит. Кроме раздутых щёк и непомерного самомнения. Боюсь, это неизлечимо.

P.S. Благодаря таким вот "проектировщикам" базы и "засраны" суррогатными ключами при одновременном дублировании фактической информации и нарушении ссылочной целостности. Тоже наверное читали Галилея с Аристотелем, а потом много думали.

guest_20040621ChA, меняйте работу. Мало того, что Вы напрасно получаете деньги за проектирование баз данных, Вы просто глупый человек.Дружище, не плюйтесь в экран. Посмотритесь в зеркало и Ваше душевное равновесие будет восстановлено. Кстати, неплохо также познакомиться с Гегелем и Кантом, они тоже сильно помогают в проектировании БД, надо только их внимательно слушать.

guest_20040621Я испытываю сожаление, что напрасно потратил время на контакт с Вами: тупость - худшее из человеческих качеств.Поздравляю, дружок, осознание своих недостатков - верный путь к выздоровлению.

NafИМХО, примарный ключ должен быть:
1. суррогатным
2. атомарным
Можете обосновать необходимость суррогатного атомарного основного ключа в таблицах, реализующих, например, связи сущностей M:N ?

MasterZiv
ChA, не надоело ещё на троллей время и нервы тратить ?
Ты не пиши ничего -- он и заткнётся.
Да, нет, даже забавно стало :) Впрочем, ты прав, общаясь с троллем сам понемногу в него превращаешься, надо завязывать.

P.S. Просто "задолбало" наблюдать, как любой топик с участием анонима превращается в топик самолюбования. Вот все вокруг такие бараны, и один он, весь из себя такой красивый, прямо в центре стада