![]() |
| ||
|
|
Новости |
Поиск |
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 все поля базы? Имеет ли это смысл?
Запутался чего-то я...
Danilka (2005-10-07 08:09:00) [1][70] msguns © (06.10.05 17:02)
>Курдль ©
>Sergey13 ©
А не пройти ли вам в "потрепацца" ?
А разве вопрос: "зачем мне примарикей?" это не вопрос для потрепаловки? :)
msguns (2005-10-06 17:02:00) [2]>Курдль ©
>Sergey13 ©
А не пройти ли вам в "потрепацца" ?
Sergey13 (2005-10-06 16:55:00) [3]2[68] Курдль © (06.10.05 16:51)
>а по-простецки берут Rowid и юзают.
Я бы сказал корректно берут и корректно юзают. Но видимо
"Что положено Юпитеру, то не положено быку." (с) какой то бог вроде
Курдль (2005-10-06 16:51:00) [4]
> Sergey13 © (06.10.05 16:46) [67]
> 2[66] Курдль © (06.10.05 16:15)
> Выходит у разработчиков DOA интелект неестественный. Не
> знал. Спасибо. 8-)
Чувствуется окончание рабочего дня - по амплитуде отклонения от темы :)
Я имел в виду, что сами DOA не применяют искуственного интеллекта для поиска первичных ключей и т.п. в таблице для привязки к конкретной записи, а по-простецки берут Rowid и юзают.
Sergey13 (2005-10-06 16:46:00) [5]2[66] Курдль © (06.10.05 16:15)
Выходит у разработчиков DOA интелект неестественный. Не знал. Спасибо. 8-)
Курдль (2005-10-06 16:15:00) [6]
> Sergey13 © (06.10.05 15:52) [62]
> Не находишь в своих двух предложениях непримиримого противоречия?
Нет. Одно дело - проектировщики классов доступа типа DOA, SQLDirect и т.п., которые не знают, к каким таблицам придется привязываться их классам и что там у них за ПК.
А другое - носители естественного интеллекта - проектировщики и кодировщики, которые на момент написания запросов точно знают, что за ПК в той или иной таблице.
Sergey_Masloff (2005-10-06 16:11:00) [7]msguns © (06.10.05 15:55) [63]
>Они могут называть этот указатель хоть горшком, от этого он не может >быть полем записи, на которую указывает, физически, т.к. хранится >сервером совершенно в другом месте,
А, ну это очевидно. Кто ж спорит.
Отсюда все же вытекает неудобность письменного общения - на словах мы б за 3 секунды выяснили кто что имеет в виду. Как пример этого - сегодня за буквально 5 минут решили проблему лежавшую тяжким камнем месяц. А стоило собраться вживую троим из трех соседних комнат. Переписывались - переписывались и не смогли друг другу объяснить суть проблемы. Вот такие пироги. В из пяти минут 30 секунд заняло изложение проблемы и поиск решения (очевидного) три с половиной минуты я шел к рабочему месту 40 секунд набирал команду и 0.216 сек работал Oracle. И настала феличита минимут трем отделам и одному филиалу
Anatoly Podgoretsky (2005-10-06 15:58:00) [8]msguns © (06.10.05 15:55) [63]
И вроде бы во всех базах это неустойчиво и уж точно имеет совсем другое смысловое значение.
msguns (2005-10-06 15:55:00) [9]>Sergey_Masloff (06.10.05 15:41) [57]
>Ну, сами они (первоисточники) все же называют это полем. Хотя и "псевдо" ;-)
Они могут называть этот указатель хоть горшком, от этого он не может быть полем записи, на которую указывает, физически, т.к. хранится сервером совершенно в другом месте, со всеми остальными своими "собратьями". Его можно назвать "полем" только опосредовано, имея в виду, что в кэше считанные записи валяются вместе со своими указателями. В этом случае можно этот указатель обозвать "полем". Однако после удаления записи из кэша, у нее тут же это поле "кастрируют". До следующего раза ;)
Кстати, в некоторых базах, например dbf, этот указатель имеет вполне конкретное смысловое наполнение и содержит порядковый номер записи в таблице.
И вообще, механизм "кластирования" данных - штука ноухавная, хотя, как я слышал, периодически тупо воруемая и модифицируемая ;)
Sergey13 (2005-10-06 15:52:00) [10]2[60] Курдль © (06.10.05 15:47)
Не находишь в своих двух предложениях непримиримого противоречия? 8-)
Danilka (2005-10-06 15:49:00) [11]Андрей Жук © (06.10.05 15:46)
> Думаешь все идет через одну шахматку в гипотетической
> САМОЙ ГЛАВНОЙ налоговой инспекции? ;-)
Да, запрос на получение кода отправляется в Киев, откуда и присылается обратно. А как же еще?
Ну, например у нас первые 4 цифры это код налоговой. Остальные - незнаю.
Курдль (2005-10-06 15:47:00) [12]
> Sergey_Masloff (06.10.05 15:41) [57]
> а уж в Oracle rowid используют все кому не лень
Я бы сказал "кому лень следовать правилам хорошего тона при работе с ораклом". Другое дело, что его используют многие классы (компоненты) доступа, т.к. это удобное и очевидное средство привязки к записи.
Андрей Жук (2005-10-06 15:46:00) [13]
> Думаешь все идет через одну шахматку в гипотетической
> САМОЙ ГЛАВНОЙ налоговой инспекции? ;-)
Да, запрос на получение кода отправляется в Киев, откуда и присылается обратно. А как же еще?
Sergey_Masloff (2005-10-06 15:45:00) [14]Андрей Жук © (06.10.05 15:31) [56]
>Почему? Я родился 21.06.1982
А я родился тоже 21.06.1982 (к примеру, на самом деле намного раньше) и обратился в тот же день. Только ты в Жмеринке а я в Ужописе (есть такой город, серьезно. Родился я правда не в нем). И кто из нас первый? Думаешь все идет через одну шахматку в гипотетической САМОЙ ГЛАВНОЙ налоговой инспекции? ;-)
Sergey_Masloff (2005-10-06 15:41:00) [15]msguns © (06.10.05 15:15) [52]
>Если бы вместо "поле" прозвучало "указатель на физический адрес записи", >вопросов бы не было ;))
Ну, сами они (первоисточники) все же называют это полем. Хотя и "псевдо" ;-)
>Однако этот адрес - дело чисто сервера,- никакой клиент не может и не >должен его знать.
Знать может... Иногда полезно ;-) Тем более "клиентом" может быть и хранимая процедура на сервере
>Тем более, что это - величина далеко не постоянная ;)
Ну кто бы спорил...
Для интербейза классический пример с удалением дубликатов. Рекомендованый отцами - основателями (ну ладно, метерями - основательницами, учитывая пол Анны) вполне полагается на rdb$db_key
а уж в Oracle rowid используют все кому не лень
Андрей Жук (2005-10-06 15:31:00) [16]
> Если "номер по порядку того, кто обратился" считать
> "отфонарным", то их "+" тоже "отфонарный".
Почему? Я родился 21.06.1982
Получая номер (к примеру, я не знаю точного метода генерации) 2106198200001012 (обратился за номером 1012 из тех, кто родился в этот день).
Fay (2005-10-06 15:27:00) [17]2 Андрей Жук © (06.10.05 15:22) [53]
Если "номер по порядку того, кто обратился" считать "отфонарным", то их "+" тоже "отфонарный".
Fay (2005-10-06 15:24:00) [18]2 msguns © (06.10.05 15:15) [52]
Полностью согласен. Но с "полем" интереснее 8)
Андрей Жук (2005-10-06 15:22:00) [19]кстати, насколько я знаю, идентификационный номер, который в Украине выдается налоговой инспекцией, не генерируется отфонарно, я является как бы составным - дата рождения + номер по порядку того, кто обратился.
msguns (2005-10-06 15:15:00) [20]>Sergey_Masloff (06.10.05 14:13) [50]
Если бы вместо "поле" прозвучало "указатель на физический адрес записи", вопросов бы не было ;))
Однако этот адрес - дело чисто сервера,- никакой клиент не может и не долженего знать. Тем более, что это - величина далеко не постоянная ;)