| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Primary Key и Unique key
Piter © (2005-10-04 22:19:00)Объясните, пожалуйста, человеческим языком - зачем нужен Primary Key?
Большинство отвечает - чтобы создать уникальное поле. Ок, а чем это тогда отличается от Unique key?
Большинство отвечает, что в Primary Key можно указывать несколько полей.
Это весь функционал этих директив?
А что физически в базе происходит при этом? Так ли важно задавать первичный ключ? Если первичный ключ - одно поле, то можно легко заменить на Unique key?
А если у меня все поля могут быть одинаковые - то Primaty Key не нужен?
А если уникальность нужна только для всех полей - допустим указывать в Primary Key все поля базы? Имеет ли это смысл?
Запутался чего-то я...
Fay (2005-10-06 15:10:00) [21]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 - это индекс.
Sergey_Masloff (2005-10-06 14:13:00) [22]msguns © (06.10.05 13:44) [49]
Да, похоже я высказался туманно ;-) Нет этодополнительное
Может это сбило ;-) Я просто хотел сказать что поле с системными адресами записей есть в любом случае. Но они НЕ праймари кей и никоем образом не оправдывает его отсутствие. И никаких его функций не выполняет.
Надеюсь никто не понял меня так что раз dbkey есть то праймари не нужен? Такого я не мог не то что сказать - даже в бреду подумать ;-)))
msguns (2005-10-06 13:44:00) [23]>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 13:37:00) [24]Fay © (06.10.05 12:25) [44]
>Покажете как-нибудь?
select rowid from ANYTABLE -- ORACLE
select rdb$db_key from ANYTABLE -- InterBase
Desdechado (2005-10-06 13:27:00) [25]Курдль © (06.10.05 12:59) [46]
вот только "волшебные слова" никак не объясняют разницу между PK и UQ, а тем более этогоне сделают CASE-средства
концептуальную модель создает аналитик, а вот структуру БД создает проектировщик
так вот мы рассматриваем не поведение аналитика, а поведение проектирощика
Курдль (2005-10-06 12:59:00) [26]Ой, как интересно все! Скока слов написано!!!
Только мне кажется, что обучать автора топика стали не с той стороны (мягко говоря).
Если опустиить все злобные советы читать книжки, а не лезть за разъяснениями на форум, то все равно стоит внести кое-какие дополнения.
БД проектируются не от ключей, индексов, полей и правил.
Они проектируются от автоматизируемых бизнес-процессов и концепции хранения данных. Т.е. первым делом разрабатывается КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ.
И нет в ней никаких ключей, индексов и даже таблиц.
Есть "сущности" или "элементы" (entity) и связи (relations). Поэтому она и называется еще "ER-модель".
Словестное описание таких моделей не содержит и упоминания о ключах и т.п.
Например: "В БД предусмотрена сущность ТОВАР (имя, срок годности), связанная, как "один-ко-многим" с сущностью СДЕЛКА(дата, цена). Последняя, в свою очередь, связана как "много-к-одному" с сущностью КОНТРАГЕНТ(имя, ИНН). И т.д.
Вот эти волшебные слова "связана", "много-к-одному" ... - и скрывают в себе необходимость иметь идентификаторы и внешние ключи.
А дальше уже можно ничего не знать о внутренней структуре БД и все равно успешно ее создать средствами CASE. А вот чтобы писать прикладные программы под такую БД ее структуру знать придется.
Fay (2005-10-06 12:33:00) [27]2 Piter © (05.10.05 18:58) [38]
Вы вАщЕ понимаете смысл слова constraint?
Как верно заметил msguns ([42]), у некоторых людей отлично получается делать мебель. И многие из них её действительно делают, не спрашивая "А почему нельзя гвоздями? Чем они хуже тех же шурупов и т.д.?". Таким замечательным мастерам я простил бы вопрос типа "зачем нужен Primary Key?"...
Fay (2005-10-06 12:25:00) [28]2 Sergey_Masloff (04.10.05 23:09) [8]
> Нет это дополнительное поле представляющее адрес
> записи будет создано в любом случае - задавай ты
> праймари кей или не задавай.
Покажете как-нибудь?
Fay (2005-10-06 12:23:00) [29]2 Piter © (04.10.05 22:45) [2]
>> Ок, а чем это тогда отличается от Unique key?
Лучше+короче [1], наверноё, не скажешь.
2 Piter © (04.10.05 23:03) [6]
>> чисто из принципов построения СУБД наверное следует.
Вы уже большой мальчик. Пора бы знать точно.
>> если же это поле не будет задано - то база сама создаст дополнительное
>> поле и обеспечит его уникальность
Это вопрос, или бред?
msguns (2005-10-06 09:29:00) [30]>Piter © (05.10.05 18:15) [34]
>а если в логике приложения таблица только одна. PK не нужен?
В некоторых случаях, например, надо сделать простенький список и положить его в БД, он, вероятно, не нужен вовсе.
Но, понимаешь ли, существуют правила, каноны, стиль, если хочешь. Привив себе определенные привычки, просто научишься работать профессионально, правильно.
Просто пример для наглядности.
Мне как-то пришлось ремонтировать свое кресло, для чего я его разобрал. И ужаснулся, ибо все его деревянные части были сделаны из нестуганной сосны, даже грубым рубанком не прошлись, шаромыжники. Просто гвоздямигрубо сбит каркас из неструганных досок и брусов, а сверху обтянуто материей.
Этим летом ездил к маме в Волгоград и она меня попросила посмотреть покосившееся кресло из румынского гарнитура, купленного в начале 70-х.
Разобрал, глянул.. Все деревянные части сделаны из отполированныхбрусков хороших сортов дерева, без сучков и трещин. Крепеж исключительно на уголках и вкладышах болтами и винтиками, которые даже спустя 30 лет легко отвинтились. Поневоле отдал дань уважения Мастерам, сделавшим его.
ANB (2005-10-06 09:24:00) [31]
> У меня вполне конкретный вопрос - если PK нужен чисто для
> целостности ссылок - то при наличии всего одной таблицы
> - он не нужен?
А у меня чисто конкретный ответ - если работаешь на оракле, то не очень (там еще есть rowid, но использование его не по теме не приветствуется), если на любой другой базу - то очень желателен, причем суррогатный на генераторе. Так как через него легче всего находить конкретную запись. SQL сервера - это не DBF и тут нельзя просто прогуляться по таблице и удалить конкретную запись. Плюс никто не может гарантировать, что в дальнейшем к этой таблице не будет связок. Я на такие грабли уже наступал - завел талицу, по логике ей было достаточно иметь составной ключ. Через неделю выяснилось, что на эту таблицу нужно сделать ссылку. А составная ссылка - жуткие грабли.
Desdechado (2005-10-05 22:17:00) [32]Anatoly Podgoretsky © (05.10.05 18:56) [37]
> Зачем?
Мне так нравится больше :)
sniknik (2005-10-05 20:05:00) [33]> если PK нужен чисто для целостности ссылок
но он нужен не только "чисто для целостности".
перечитай написанное, видать не проникся.
Piter (2005-10-05 18:58:00) [34]Anatoly Podgoretsky © (05.10.05 18:44) [35]
не проникся духом написанного? Это ответ программиста или священика?
У меня вполне конкретный вопрос - если PK нужен чисто для целостности ссылок - то при наличии всего одной таблицы - он не нужен?
Anatoly Podgoretsky (2005-10-05 18:56:00) [35]Desdechado © (05.10.05 18:47) [36]
Зачем, в данном случае это поле(я) кандидат на ПК
Desdechado (2005-10-05 18:47:00) [36][34]
можно обойтись уником, если он не очень длинный и прироста таблиц не ожидается
но я бы все равно сделал суррогатный PK
по нему потом легче позиционироваться при UPDATE|DELETE|SELECT - быстрее на сервере и в коде понятнее
Anatoly Podgoretsky (2005-10-05 18:44:00) [37]Если ты еще не проникся духом выше написаного, то просто прими за правило делать первичный ключ в любой таблице. Это ничего не стоит.
Piter (2005-10-05 18:15:00) [38]msguns © (05.10.05 9:55) [18]
Основное семантичесое (смысловое) назначение PK - поддержка межтабличных связей
а если в логике приложения таблица только одна. PK не нужен?
ANB (2005-10-05 11:58:00) [39]
> Danilka © (05.10.05 11:28) [32]
- точно точно. Я сам задрался ругаться. В фоксе не всегда работает контроль на дубли, к тому же при приеме сведений от других источников этот контроль не ведется даже в новых системах. Куча дублей получается и при объединении районных налоговых.
Danilka (2005-10-05 11:28:00) [40]msguns © (05.10.05 10:08)
- суррогатный, т.е. реально не сущестующий, но необходимый для однозначной идентификации объекта хранения атрибут-поле. Как пример - ИНН (индивидуальный налоговый номер).
брат, когда еще работал в налоговой, рассказывал, что у них в базе есть куча людей с одинаковыми ИНН :)))
конечно, такого быть не должно и как-то они их разруливают, но, всетаки, на PK он не тянет.
| |
Страницы: 