|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Добрый день. Подскажите пожлуйста, у меня есть поля. airline_icao_code airline_name airline_call_sign country_ID. Первые три поля уникальны. По идее они прекрасно подходят для составного первичного ключа, однако этот же весь составной первичный ключ должен мигрировать в другие таблицы, я хочу избежать множество join в select. Могу ли я добавить сурогатный id, а первые три поля сделать уникальными? Не нарушвет ли это нормализацию? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 13:19 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13По идее они прекрасно подходят для составного первичного ключа Это плохая идея. Они даже для уникального ключа не подходят. И да, суррогатный первичный ключ на нормализацию никак не влияет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 13:27 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, То есть сурогатный с ограничением уникальности на три поля неплохое решение, как я понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 13:33 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
И еще вот один вопрос такой. Как сделать ограничение на то, чтобы поле содержала только верхний регистр? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 13:35 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13неплохое решение "Неплохость" решения зависит от его соответствия задаче. Нет задачи - нет оценки решения. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 13:46 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, задача стоит в том, чтобы нормализовать БД. Набор из первых строк представляет собой уникальную идентификацию аэропорта, например GRO Grodno airline GRODNO AIRLINE соответсвуют только одной авиакомпании по ICAO код, поэтому я и подумал, что эти три поля пододйдут для первичного ключа, но PK этой таблицу мигрирует в Полеты, и я не хочу мигрировать такой составной ключ в Полеты, вот и спросил про сурогатный ключ. Мне кажется, что поле страна айти тогда будет зависимть не только от сурогатного, но и от трех остальных полей. Очень надеюясь, что я понятно изложил суть своей проблемы ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 13:56 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13, у палки 2 конца 1. миграция 2. лукапы ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 14:00 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13адача стоит в том, чтобы нормализовать БД. "Неплохость" решения учебной задачи определяется исключительно преподавателем, её задавшим. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 14:03 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Понял то, что лучшего варианта нету, все зависит от задачи. Останавлюсь на сурогатном ключе, чтобы потом не делать три джойна на только на аодну табоицу. Спасибо всем ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 14:08 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 GRODNO AIRLINE соответсвуют только одной авиакомпании по ICAO код , поэтому я и подумал, что эти три поля пододйдут для первичного ключа Тогда у тебя тут налицо ФЗ левая сторона которой не является ключом, т.е. нарушение как минимум НФБК. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 14:18 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, вылетелело из головы ФНБК, если рассматривать составной ключ, тогда больше склоняюсь с сурогатному и ограничению по уникальности, чтобы не декомпозировать отношение. Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 14:30 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 тогда больше склоняюсь с сурогатному и ограничению по уникальности, чтобы не декомпозировать отношение. Декомпозировать все равно придется, потому что у тебя будет транзитивная ФЗ: ID -> Код ИКАО -> Авиакомпания. Нарушится 3 НФ. НФБК похожа на 3 НФ, но немного "нормальнее" и определение проще: "Левая часть любой неприводимой и нетривиальной ФЗ должна быть ключом". ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 14:41 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 Добрый день. Подскажите пожлуйста, у меня есть поля. airline_icao_code airline_name airline_call_sign country_ID. Первые три поля уникальны. По идее они прекрасно подходят для составного первичного ключа, однако этот же весь составной первичный ключ должен мигрировать в другие таблицы, я хочу избежать множество join в select. Могу ли я добавить сурогатный id, а первые три поля сделать уникальными? Не нарушвет ли это нормализацию? Да, можешь. Нет, не нарушит. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:00 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
MasterZiv, мне сообщением выше написали, что это нарушает 3НФ, хотя я думал, что нет, так как каждое поле зависит от сурагатного. Как вариант, я могу разбить все же на две сущности airline_icao_code => airline_name и airline_icao_code => airline_call_sign, country_ID ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:05 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Хотя делать связь 1 к 1 тоже не хочется, лишний джойн во время запроса ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:07 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, airline_icao_code => airline_name и airline_icao_code => airline_call_sign, country_ID со связью 1 к 1? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:17 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 Как вариант, я могу разбить все же на две сущности airline_icao_code => airline_name и airline_icao_code => airline_call_sign, country_ID Вообще, насколько я понимаю смысл полей тебе стоит просто добавить ключ ID и объявить альтернативным ключом (UNIQUE) airline_icao_code. А то и просто ничего не добавлять, а сделать airline_icao_code ключом из одного поля. Как-то так (если на MS SQL): Код: sql 1. 2. 3. 4. 5.
или с суррогатом: Код: sql 1. 2. 3. 4. 5. 6.
Можно, в принципе, еще поля name и sign сделать по отдельности уникальными, если это так. Лично мне с суррогатом нравится намного больше, но в данном случае это скорее дело вкуса. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:17 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, исходя из данных airline_call_sign тоже уникальный. По идее он тоже может быть альтернативным первичным ключом. Так как как и код и название он уникально идентифицирует афиакомпанию. Если рассматривать такой вариант, то я бы выбрал без сурогатного. Так как пусть имя и airline_call_sign так же уникально идентифицируют авиакомпанию, но по сути оба зависят от кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:35 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, по отдельности я не могу сделать эти поля, может быть только такой вариант для идентификации одной компании 'GRO', 'Grodno','Grodno_comp', других вариантов быть никак не может по стандарту. Каждое из этих полей может быть альтернативным первичным ключом ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:38 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, получается три альтернативных ключа. Но ограничение уникальности должно быть на 3 поля. От кода точно зависит имя, да и сигн, но они могут быть альтеративными первичными ключами. Что-то я совсем запутался ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:44 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, неправильно понял про уникальность на каждое поле, да, такой вариант правильнее, но id_ страны зависит не только от id авиакомпании. Я думаю над таким варинатом решение create table ttt ( airline_icao_code nvarchar(50) primary key, airline_name nvarchar(50) not null unique, airline_call_sign nvarchar(50) not null unique ); create table tt ( airline_icao_code nvarchar(50) primary key, country_ID int not null foreign key reference countries(ID) ); ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 15:58 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 но id_ страны зависит не только от id авиакомпании. Но, если Moneta13 create table tt ( airline_icao_code nvarchar(50) primary key, country_ID int not null foreign key reference countries(ID) ); то ИД страны как-раз таки зависит именно от ИД компании. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:20 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
fkthat, я наверное плохо выражаю свои мысли. Если все сделать в одном отношении, то первые три поля уникальны, и айди страны может зависеть от любого из этих полей. Но, когда я разбил на два отношения, то для себя уже выделил первичный ключ из двух альтернативных, и уже во втором отношении айди страны зависит только от первичного ключа. Может я не понимаю что или усложняю ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:25 |
|
Отказ от составного первичного ключа.
|
|||
---|---|---|---|
#18+
Moneta13 От кода точно зависит имя, да и сигн, но они могут быть альтеративными первичными ключами. Что-то я совсем запутался А в чем путаница-то? У сущности запросто может быть не один ключ (то, что называется "потенциальные ключи"). Объявление одного из них "primary" это, скорее, просто традиция (в сиквеле он не может быть null и по умолчанию создается в виде кластерного индекса - больше он, фактически, ничем от любого другого unique не отличается). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2021, 16:25 |
|
|
Start [/forum/topic.php?fid=32&msg=40065940&tid=1539799]: |
0ms |
get settings: |
56ms |
get forum list: |
7ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
39ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
2015ms |
get tp. blocked users: |
1ms |
others: | 220ms |
total: | 2346ms |
0 / 0 |