Primary Key и Unique key

← →
Desdechado © (2005-10-05 22:17) [40]

Anatoly Podgoretsky © (05.10.05 18:56) [37]
> Зачем?
Мне так нравится больше :)

← →
ANB © (2005-10-06 09:24) [41]

> У меня вполне конкретный вопрос - если PK нужен чисто для
> целостности ссылок - то при наличии всего одной таблицы
> - он не нужен?

А у меня чисто конкретный ответ - если работаешь на оракле, то не очень (там еще есть rowid, но использование его не по теме не приветствуется), если на любой другой базу - то очень желателен, причем суррогатный на генераторе. Так как через него легче всего находить конкретную запись. SQL сервера - это не DBF и тут нельзя просто прогуляться по таблице и удалить конкретную запись. Плюс никто не может гарантировать, что в дальнейшем к этой таблице не будет связок. Я на такие грабли уже наступал - завел талицу, по логике ей было достаточно иметь составной ключ. Через неделю выяснилось, что на эту таблицу нужно сделать ссылку. А составная ссылка - жуткие грабли.

← →
msguns © (2005-10-06 09:29) [42]

>Piter © (05.10.05 18:15) [34]
>а если в логике приложения таблица только одна. PK не нужен?

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

Просто пример для наглядности.
Мне как-то пришлось ремонтировать свое кресло, для чего я его разобрал. И ужаснулся, ибо все его деревянные части были сделаны из нестуганной сосны, даже грубым рубанком не прошлись, шаромыжники. Просто гвоздями грубо сбит каркас из неструганных досок и брусов, а сверху обтянуто материей.
Этим летом ездил к маме в Волгоград и она меня попросила посмотреть покосившееся кресло из румынского гарнитура, купленного в начале 70-х.
Разобрал, глянул.. Все деревянные части сделаны из отполированных брусков хороших сортов дерева, без сучков и трещин. Крепеж исключительно на уголках и вкладышах болтами и винтиками, которые даже спустя 30 лет легко отвинтились. Поневоле отдал дань уважения Мастерам, сделавшим его.

← →
Fay © (2005-10-06 12:23) [43]

2 Piter © (04.10.05 22:45) [2]
>> Ок, а чем это тогда отличается от Unique key?
Лучше+короче [1], наверноё, не скажешь.

2 Piter © (04.10.05 23:03) [6]
>> чисто из принципов построения СУБД наверное следует.
Вы уже большой мальчик. Пора бы знать точно.

>> если же это поле не будет задано - то база сама создаст дополнительное
>> поле и обеспечит его уникальность
Это вопрос, или бред?

← →
Fay © (2005-10-06 12:25) [44]

2 Sergey_Masloff (04.10.05 23:09) [8]
> Нет это дополнительное поле представляющее адрес
> записи будет создано в любом случае - задавай ты
> праймари кей или не задавай.

Покажете как-нибудь?

← →
Fay © (2005-10-06 12:33) [45]

2 Piter © (05.10.05 18:58) [38]
Вы вАщЕ понимаете смысл слова constraint?

Как верно заметил msguns ([42]), у некоторых людей отлично получается делать мебель. И многие из них её действительно делают, не спрашивая "А почему нельзя гвоздями? Чем они хуже тех же шурупов и т.д.?". Таким замечательным мастерам я простил бы вопрос типа "зачем нужен Primary Key?"...

← →
Курдль © (2005-10-06 12:59) [46]

Ой, как интересно все! Скока слов написано!!!

Только мне кажется, что обучать автора топика стали не с той стороны (мягко говоря).

Если опустиить все злобные советы читать книжки, а не лезть за разъяснениями на форум, то все равно стоит внести кое-какие дополнения.

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

← →
Desdechado © (2005-10-06 13:27) [47]

Курдль © (06.10.05 12:59) [46]
вот только "волшебные слова" никак не объясняют разницу между PK и UQ, а тем более этогоне сделают CASE-средства
концептуальную модель создает аналитик, а вот структуру БД создает проектировщик
так вот мы рассматриваем не поведение аналитика, а поведение проектирощика

← →
Sergey_Masloff (2005-10-06 13:37) [48]

Fay © (06.10.05 12:25) [44]
>Покажете как-нибудь?
select rowid from ANYTABLE -- ORACLE
select rdb$db_key from ANYTABLE -- InterBase

← →
msguns © (2005-10-06 13:44) [49]

>Sergey_Masloff (06.10.05 13:37) [48]
>select rowid from ANYTABLE -- ORACLE
>select rdb$db_key from ANYTABLE -- InterBase

И как это соотноситься с [8], а именно

Нет это дополнительное поле представляющее адрес записи будет создано в любом случае - задавай ты праймари кей или не задавай.

???

Сереж, видимо, ты просто коряво выразил свою мысль,- вот у Фэя возникли непонятки. Как, впрочем и у меня, только я промолчал, прибитый авторитетом ;)))

← →
Sergey_Masloff (2005-10-06 14:13) [50]

msguns © (06.10.05 13:44) [49]
Да, похоже я высказался туманно ;-) Нет это дополнительное
Может это сбило ;-) Я просто хотел сказать что поле с системными адресами записей есть в любом случае. Но они НЕ праймари кей и никоем образом не оправдывает его отсутствие. И никаких его функций не выполняет.
Надеюсь никто не понял меня так что раз dbkey есть то праймари не нужен? Такого я не мог не то что сказать - даже в бреду подумать ;-)))

← →
Fay © (2005-10-06 15:10) [51]

2 Sergey_Masloff (06.10.05 13:37) [48]
>select rowid from ANYTABLE -- ORACLE
> select rdb$db_key from ANYTABLE -- InterBase
Некий смысл имеет только rowid в Oracle.
Говорить rdb$db_key (и т.п.) так же занимательно, как утверждать, что PK - это индекс.

← →
msguns © (2005-10-06 15:15) [52]

>Sergey_Masloff (06.10.05 14:13) [50]

Если бы вместо "поле" прозвучало "указатель на физический адрес записи", вопросов бы не было ;))
Однако этот адрес - дело чисто сервера,- никакой клиент не может и не должен его знать. Тем более, что это - величина далеко не постоянная ;)

← →
Андрей Жук © (2005-10-06 15:22) [53]

кстати, насколько я знаю, идентификационный номер, который в Украине выдается налоговой инспекцией, не генерируется отфонарно, я является как бы составным - дата рождения + номер по порядку того, кто обратился.

← →
Fay © (2005-10-06 15:24) [54]

2 msguns © (06.10.05 15:15) [52]
Полностью согласен. Но с "полем" интереснее 8)

← →
Fay © (2005-10-06 15:27) [55]

2 Андрей Жук © (06.10.05 15:22) [53]
Если "номер по порядку того, кто обратился" считать "отфонарным", то их "+" тоже "отфонарный".

← →
Андрей Жук © (2005-10-06 15:31) [56]

> Если "номер по порядку того, кто обратился" считать
> "отфонарным", то их "+" тоже "отфонарный".

Почему? Я родился 21.06.1982
Получая номер (к примеру, я не знаю точного метода генерации) 2106198200001012 (обратился за номером 1012 из тех, кто родился в этот день).

← →
Sergey_Masloff (2005-10-06 15:41) [57]

msguns © (06.10.05 15:15) [52]
>Если бы вместо "поле" прозвучало "указатель на физический адрес записи", >вопросов бы не было ;))
Ну, сами они (первоисточники) все же называют это полем. Хотя и "псевдо" ;-)

>Однако этот адрес - дело чисто сервера,- никакой клиент не может и не >должен его знать.
Знать может... Иногда полезно ;-) Тем более "клиентом" может быть и хранимая процедура на сервере

>Тем более, что это - величина далеко не постоянная ;)
Ну кто бы спорил...

Для интербейза классический пример с удалением дубликатов. Рекомендованый отцами - основателями (ну ладно, метерями - основательницами, учитывая пол Анны) вполне полагается на rdb$db_key

а уж в Oracle rowid используют все кому не лень

← →
Sergey_Masloff (2005-10-06 15:45) [58]

Андрей Жук © (06.10.05 15:31) [56]
>Почему? Я родился 21.06.1982
А я родился тоже 21.06.1982 (к примеру, на самом деле намного раньше) и обратился в тот же день. Только ты в Жмеринке а я в Ужописе (есть такой город, серьезно. Родился я правда не в нем). И кто из нас первый? Думаешь все идет через одну шахматку в гипотетической САМОЙ ГЛАВНОЙ налоговой инспекции? ;-)

← →
Андрей Жук © (2005-10-06 15:46) [59]

> Думаешь все идет через одну шахматку в гипотетической
> САМОЙ ГЛАВНОЙ налоговой инспекции? ;-)

Да, запрос на получение кода отправляется в Киев, откуда и присылается обратно. А как же еще?

← →
Курдль © (2005-10-06 15:47) [60]

> Sergey_Masloff (06.10.05 15:41) [57]
> а уж в Oracle rowid используют все кому не лень

Я бы сказал "кому лень следовать правилам хорошего тона при работе с ораклом". Другое дело, что его используют многие классы (компоненты) доступа, т.к. это удобное и очевидное средство привязки к записи.

← →
Danilka © (2005-10-06 15:49) [61]

Андрей Жук © (06.10.05 15:46)

> Думаешь все идет через одну шахматку в гипотетической
> САМОЙ ГЛАВНОЙ налоговой инспекции? ;-)

Да, запрос на получение кода отправляется в Киев, откуда и присылается обратно. А как же еще?

Ну, например у нас первые 4 цифры это код налоговой. Остальные - незнаю.

← →
Sergey13 © (2005-10-06 15:52) [62]

>Sergey_Masloff (06.10.05 15:41) [57]
>Ну, сами они (первоисточники) все же называют это полем. Хотя и "псевдо" ;-)

Они могут называть этот указатель хоть горшком, от этого он не может быть полем записи, на которую указывает, физически, т.к. хранится сервером совершенно в другом месте, со всеми остальными своими "собратьями". Его можно назвать "полем" только опосредовано, имея в виду, что в кэше считанные записи валяются вместе со своими указателями. В этом случае можно этот указатель обозвать "полем". Однако после удаления записи из кэша, у нее тут же это поле "кастрируют". До следующего раза ;)

Кстати, в некоторых базах, например dbf, этот указатель имеет вполне конкретное смысловое наполнение и содержит порядковый номер записи в таблице.

И вообще, механизм "кластирования" данных - штука ноухавная, хотя, как я слышал, периодически тупо воруемая и модифицируемая ;)

msguns © (06.10.05 15:55) [63]
И вроде бы во всех базах это неустойчиво и уж точно имеет совсем другое смысловое значение.

← →
Sergey_Masloff (2005-10-06 16:11) [65]

msguns © (06.10.05 15:55) [63]
>Они могут называть этот указатель хоть горшком, от этого он не может >быть полем записи, на которую указывает, физически, т.к. хранится >сервером совершенно в другом месте,
А, ну это очевидно. Кто ж спорит.
Отсюда все же вытекает неудобность письменного общения - на словах мы б за 3 секунды выяснили кто что имеет в виду. Как пример этого - сегодня за буквально 5 минут решили проблему лежавшую тяжким камнем месяц. А стоило собраться вживую троим из трех соседних комнат. Переписывались - переписывались и не смогли друг другу объяснить суть проблемы. Вот такие пироги. В из пяти минут 30 секунд заняло изложение проблемы и поиск решения (очевидного) три с половиной минуты я шел к рабочему месту 40 секунд набирал команду и 0.216 сек работал Oracle. И настала феличита минимут трем отделам и одному филиалу

> Sergey13 © (06.10.05 15:52) [62]
> Не находишь в своих двух предложениях непримиримого противоречия?

Нет. Одно дело - проектировщики классов доступа типа DOA, SQLDirect и т.п., которые не знают, к каким таблицам придется привязываться их классам и что там у них за ПК.
А другое - носители естественного интеллекта - проектировщики и кодировщики, которые на момент написания запросов точно знают, что за ПК в той или иной таблице.

> Sergey13 © (06.10.05 16:46) [67]
> 2[66] Курдль © (06.10.05 16:15)
> Выходит у разработчиков DOA интелект неестественный. Не
> знал. Спасибо. 8-)

Чувствуется окончание рабочего дня - по амплитуде отклонения от темы :)

Я имел в виду, что сами DOA не применяют искуственного интеллекта для поиска первичных ключей и т.п. в таблице для привязки к конкретной записи, а по-простецки берут Rowid и юзают.

2[68] Курдль © (06.10.05 16:51)
>а по-простецки берут Rowid и юзают.
Я бы сказал корректно берут и корректно юзают. Но видимо
"Что положено Юпитеру, то не положено быку." (с) какой то бог вроде

[70] msguns © (06.10.05 17:02)
>Курдль ©
>Sergey13 ©

А не пройти ли вам в "потрепацца" ?

А разве вопрос: "зачем мне примарикей?" это не вопрос для потрепаловки? :)

Primary Key и Unique key Найти похожие ветки