|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 и айди страны может зависеть от любого из этих полей. Ну и в чем проблема? Вообще любое поле автоматически зависит от любого потенциального ключа. Просто потому что в отношении вообще не может быть два кортежа с одним и тем же потенциальным ключом, следовательно не может быть и двух кортежей у которых потенциальный ключ одинаковый, а зависимое поле разное. Само по себе определение ФЗ такое: (X, Y, ....) -> Z значит что для любых двух записей у которых одинаковые наборы (X, Y, ...) будет одинаков и Z. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:30 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, я вроде как разобрался. Пробелы в теории, додумался только сейчас погуглить. неключевой атрибут может спокойно зависеть от первичного ключа и от альтернативных ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:33 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, вроде бы разобрался, путаница в пробеле по теории соображением погуглить только сейчас. Неключевой атрибут может зависеть как от первичного, так и от альтернативного. Тогда путаница сразу спадает ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:36 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, спасибо большое ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:37 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 неключевой атрибут может спокойно зависеть от первичного ключа и от альтернативных Так не просто "может", а "обязательно будет". Вопрос нормализации сводится к тому не будет ли он при этом зависеть еще и от других неключевых аттрибутов. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:38 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, да, понял, сталкивался с ситуациями, когда только один ПК, без потенциальных, вот как то и не задумывался об зависимости от потенциальных ключей. Жил по определени. 3НФ от хабра до этого Отношение находится в 3НФ, когда находится во 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. Спасибо большое ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:42 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 Спасибо большое За что ? За то, что взявшись за руки, дружно походили вокруг одного столба ? Нарисуйте вокруг этой таблицы хотя бы несколько связанных таблиц и сделайте связи - сразу всё станет на свои места... Можно долго спорить о том, как можно и нельзя на столбе сушить трусы, но пока не вкопаешь второй столб и не натянешь между ними веревку - ничего не получится... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 17:21 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 Первые три поля уникальны. По идее они прекрасно подходят для составного первичного ключа Выбросьте эту идею нафиг. Moneta13 однако этот же весь составной первичный ключ должен мигрировать в другие таблицы Верно. Мне однажды пришлось тащить данные из базы, в которой составные первичные ключи доходили до 12 полей - именно из-за миграции. Писать к ней запросы было... невыразимым удовольствием. Moneta13 Могу ли я добавить сурогатный id Скорее, "должны". Вообще, "добавить суррогатный id" - это в 99% случаях абсолютно правильная идея, а в оставшемся 1% случаев - "неплохая и вполне приемлемая идея". Moneta13 а первые три поля сделать уникальными? Меня немного смущает такая постановка вопроса. Неужели у ИКАО в самом деле могут быть одинаковые комбинации кода и позывного, отличающиеся только названием? Мне кажется, здесь Вам нужно присмотреться получше. Moneta13 Не нарушвет ли это нормализацию? Нет. Зато это избавляет от уймы геморроя, особенно когда окажется, что какая-нибудь авиакомпания сменила название (что происходит весьма регулярно). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 18:15 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
softwarer Вообще, "добавить суррогатный id" - это в 99% случаях абсолютно правильная идея Я бы сказал, что в 100. Часто еще не берут во внимание тот факт, что при заполнении какого-то поля (например СНИЛС) может быть ошибка (девочка-оператор не на ту кнопку нажала), и если этот, например, СНИЛС используется как естественный PK вместо суррогатного, то исправление этой ошибки в БД позже может вылиться в адов гемморой, когда эта опечатка растечется еще по дюжине таблиц в виде FK. Речь, впрочем, не идет о таблицах типа много-ко-многим, типа {UserId, RoleId} - тут ключ хоть и составной, но по сути, тоже суррогатный, т.к. состоит ведь из "суррогатных" аттрибутов. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 00:18 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 Жил по определени. 3НФ от хабра до этого В общем-то определение НФБК проще и не зависит от 2НФ. И ситуация, когда отношение в 3НФ но не в НФБК весьма экзотичная - я так сходу и придумать пример не смогу. Насколько я помню, для этого нужно наличие как минимум двух составных ключей, которые при этом еще и пересекаются по аттрибутам. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 00:21 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
softwarer в которой составные первичные ключи доходили до 12 полей По-моему для фактов в Star/Snowflake это может быть вполне нормально. Впрочем, если тут специалисты по OLAP есть, они точнее смогут сказать. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 00:24 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat Moneta13 Жил по определени. 3НФ от хабра до этого В общем-то определение НФБК проще и не зависит от 2НФ. И ситуация, когда отношение в 3НФ но не в НФБК весьма экзотичная - я так сходу и придумать пример не смогу. Насколько я помню, для этого нужно наличие как минимум двух составных ключей, которые при этом еще и пересекаются по аттрибутам. НФБК: отношение находится в 3НФ и каждый детерминант ФЗ является потенциальным ключом. Вот пример: Сессия(НомерЗачКнижки, КодСтудента, Дисциплина, Дата, Оценка) Потенциальные ключи: НомерЗачКнижки+Дисциплина+Дата КодСтудента+Дисциплина+Дата ФЗ: НомерЗачКнижки+Дисциплина+Дата->Оценка КодСтудента+Дисциплина+Дата->Оценка НомерЗачКнижки->КодСтудента КодСтудента->НомерЗачКнижки Есть два детерминанта, которые не являются потенциальными ключами. 1 возможная декомпозиция: С2( КодСтудента, Дисциплина, Дата , Оценка) С3(НомерЗачКнижки, КодСтудента) 2 возможная декомпозиция: С2( НомерЗачКнижки, Дисциплина, Дата , Оценка) С3(НомерЗачКнижки, КодСтудента) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 12:45 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
ИВП Вот пример: Сессия(НомерЗачКнижки, КодСтудента, Дисциплина, Дата, Оценка) Потенциальные ключи: НомерЗачКнижки+Дисциплина+Дата КодСтудента+Дисциплина+Дата По-моему это будет нарушать даже 2НФ. Есть ФЗ КодСтудента+Дисциплина+Дата -> НомерЗачКнижки которая является приводимой , что, как раз, условия 2НФ нарушает. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 13:08 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat ИВП Вот пример: Сессия(НомерЗачКнижки, КодСтудента, Дисциплина, Дата, Оценка) Потенциальные ключи: НомерЗачКнижки+Дисциплина+Дата КодСтудента+Дисциплина+Дата По-моему это будет нарушать даже 2НФ. Есть ФЗ КодСтудента+Дисциплина+Дата -> НомерЗачКнижки которая является приводимой , что, как раз, условия 2НФ нарушает. Что значит "приводимой"? Приводимой к чему? или приводимой куда? Для 2НФ требуется отсутствие зависимостей неключевых атрибутов от частей составного ключа. От каждой из частей ключа НомерЗачКнижки, Дисциплина, Дата ни один НЕКЛЮЧЕВОЙ атрибут не зависит. ФЗ КодСтудента+Дисциплина+Дата -> НомерЗачКнижки - зависимость ЧАСТИ ключа от составного ключа. Поэтому и есть нарушение НФБК. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 14:55 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
ИВП Что значит "приводимой"? Приводимой к чему? или приводимой куда? Ты не знаешь что такое "приводимая ФЗ"? Так загляни в учебник. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 17:29 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
ИВП Для 2НФ требуется отсутствие зависимостей неключевых атрибутов от частей составного ключа. Впрочем, ты сам же и сказал. Приводимая ФЗ, это из левой части которой можно выкинуть часть атрибутов не нарушая её. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2021, 17:33 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
А разве ICAO сам по себе не годится на роль натурального PK? Уникальный, короткий. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2021, 07:42 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
НеофитSQL, Главная проблема в натуральных ключах типа ICAO это то, что вы их не контролируете. Периодически они могут меняться, и если вы, в порыве безудержного оптимизма, сделали FK-ссылку на такой ключ, то ваши варианты либо on update cascade (что не всегда возможно), либо тонны геморроя каждый раз, когда такое случается. Объявить код ICAO альтернативным ключом - да, безусловно. Делать его первичным - я бы не рискнул. Ну или если реально невтерпеж, то (в зависимости от СУБД, наверное - за все не скажу) FK может ссылаться на AK вместо PK. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2021, 07:53 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Ennor Tiegael НеофитSQL, Главная проблема в натуральных ключах типа ICAO это то, что вы их не контролируете. Периодически они могут меняться, и если вы, в порыве безудержного оптимизма, сделали FK-ссылку на такой ключ, то ваши варианты либо on update cascade (что не всегда возможно), либо тонны геморроя каждый раз, когда такое случается. Объявить код ICAO альтернативным ключом - да, безусловно. Делать его первичным - я бы не рискнул. Ну или если реально невтерпеж, то (в зависимости от СУБД, наверное - за все не скажу) FK может ссылаться на AK вместо PK. Изменение кодов ICAO повело бы к огромным неудобствам, поскольку они были придуманы как ключи, и с ними уже обращаются как с ключами (не только в БД, а в более широком смысле). Они не используютсе повторно. Мне как раз предстоит принять очень похожее решение в другой области, и я собирался использовать уникальные и одноразовые международные коды в качестве натурального ключа. Они фиксированной длины и вроде бы подходят идеально, но тоже мной не контролируются, как Вы указали выше. В чем состоит проблема внешнего контроля PK организацией? Возьмем например коды стран: допустим РФ по какой-то загадочной причине решит называться вместо "ru" - "rf". Подав петицию, после долгого период международного обсуждения, и при условии положительного решения, будет многомесячный, или даже многолетний период перехода. За это время мне придется добавить новую строку в таблицу стран, "rf, Russia", и обновить ссылки ru->rf. После чего пометить "ru" как удаленную и добавить сторожевой код на предмет попыток использования недействительного исторического ключа. Звучит довольно несложно на мой взгляд не особо обремененный опытом проектирования БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2021, 13:51 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
НеофитSQL В чем состоит проблема внешнего контроля PK организацией? При идеально правильной схеме данных и бизнес-логике она терпима (то есть может быть решена разумными усилиями). Поэтому на игрушечных примерах в книгах и учебных задачах, где нет развития по времени, её не особо видно. В то же время на практике идеал недостижим, а любое отступление от него эта проблема очень жестоко наказывает. В этом случае она мигом раздувается до охрененных размеров геморроя, совершенно несоразмерного тем копеечным преимуществам, которые автор хотел извлечь из такого PK. Как пример. Согласно законодательству РФ, зарплаты должны выплачиваться в рублях и только в рублях. Можно предполагать, что ряд программных решений соответствует этому требованию. А теперь представим себе, что взяла и повторилась весёлая пляска с российским рублём RUR (код 810) и российским рублём RUB (код 643). Я своими глазами наблюдал, как в примерно подобном случае большая команда (> 60 человек) порядка трёх месяцев сидела на работе ночами и выходными, практически забросив все другие задачи и занимаясь только исправлением в системе всего, что затронула такая "проблема". ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2021, 14:59 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Спасибо за подробный ответ. Я сам не могу оценить риск такого решения, но проникся что вы настоятельно советуете против такого подхода. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2021, 03:30 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
НеофитSQL, Понимаете, в некотором смысле вы правы - такие изменения исключительно редки. Именно поэтому далеко не каждый, как softwarer выше, в состоянии привести вам реальный пример из жизни . Немногие с таким сталкиваются в принципе, и при этом многие проектируют БД без привязки к натуральным ключам, избегая оного геморроя в принципе. Чаще бывает несколько иная ситуация, когда в систему нужно добавить новое измерение, и учесть его везде, где только можно. У меня, например, был случай, когда в работающей системе надо было реализовать мультивалютность. До этого в ней были только рубли, и даже мысли ни у кого не возникало, что понадобится что-то еще. Справочник валют, конечно же, был, но из кода к нему не было обращений - зачем, ведь там всего одна строчка, и мы все знаем, какая именно. В результате я потратил изрядное количество времени, добавляя параметр @CurrencyId в куче мест и одновременно вычищая код вида Код: sql 1. 2. 3. 4.
Это не совсем то же самое, но причины те же и объем геморроя вполне сопоставим. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2021, 04:17 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Мне это чем-то напомнило реакцию молодых программистов когда речь заходит о временных поясах, или локализации. В России то все компы двуязычные, народ худо бедно в кодировках шарит. Может тут дело ещё и не в ключе, а в монокультуре которая накладывает невидимые ограничения и стреножит мозг. Мне интересно попробовать натуральные ключи в нескольких таблицах моего проекта, с ограничениями и преимуществами смысло-нейтральных целочисленных ключей я уже знаком. Они популярны, наверное эффективно реализованы почти везде. С другой стороны, я бы лучше увидел != "'EUR" в коде чем ...!= 3 -- '3' это евро. Везде пишем троечку ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2021, 07:41 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
НеофитSQL, Попробуйте, конечно, кто ж запрещает. Потом нам расскажете. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2021, 07:52 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
НеофитSQL С другой стороны, я бы лучше увидел != "'EUR" в коде чем ...!= 3 -- '3' это евро. Везде пишем троечку С натуральными кажется проще, но до первого столкновения с изменчивостью мира. Суррогатные ключи обычно и компактнее, и сравниваются быстрее, сравнивать строки сильно дороже, чем целые числа. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2021, 12:03 |
|
|
Start [/forum/topic.php?answer_author=%D0%9D%D0%B5%D0%BE%D1%84%D0%B8%D1%82SQL&do_answer=40070778&fid=32&msg=40070778&tid=1539799]: |
0ms |
get settings: |
15ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
27ms |
get topic data: |
4ms |
get forum data: |
1ms |
get page messages: |
1331ms |
get tp. blocked users: |
1ms |
others: | 200ms |
total: | 1587ms |
0 / 0 |