Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Всем кто не читал советую прочитать статейку / 17 сообщений из 17, страница 1 из 1
18.06.2001, 07:46
    #32007679
Genady
Genady
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Вот в рассылке встретил ссылку на статью "Естественные ключи против искусственных ключей"
http://www.sql.ru/articles?id=182

Всем, кто занимается разработкой БД рекомендую почитать. Я сам тоже пользуюсь суррогатными ключами, а в статье двольно подробно описано почему это делать нужно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 08:28
    #32007683
andy
andy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Мне некоторые выводы автора показались ошибочными, что существенно подорвало доверие к статье в целом . Здесь явно есть, что обсудить.

Вот например, возьмем такую сущность как книга в библиотеке. Каждая книга однозначно характеризуется инвентарным номером, если это перестанет быть правдой, в работе библиотеке произойдут огромные перемены . Так зачем же собственно вводить дополнительный ключ?

ИМХО СК нужен тогда когда естественный ключ является составным, чтобы не волочить его в другие таблицы, да и запросы попроще. Или в том случае, когда он очень длинный.

А вот пример вывода, который на мой взгляд просто я вляется не верным:

"Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ, и ни одно из её неключевых полей не зависит функционально от любого другого неключевого поля.

То есть, речи о ключевых полях там не идёт вообще. Поэтому добавление ещё одного ключа в таблицу ни в коей мере не может нарушить 3НФ. Вообще, для таблицы с несколькими возможными ключами имеет смысл говорить не о 3 НФ, а о Нормальной Форме Бойса-Кодда, которая специально введена для таких таблиц."

Хм, ну так было ведь ключевое поле, которое стало неключевым, все остальные поля зависят от него, эта зависимость никуда не пропала. Это поле все равно является кандидат ключом, разве не так?

Насчет увеличения производительности: помоему наличие индекса (кластерного) практически уравнивает скорость выборки по int полю и скажем varchar. Другое дело, что может появиться ограничение на длину строки, если по ней нужно строить индекс. Но все-таки врядли речь идет о ключах типа varchar (200).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 08:46
    #32007685
Genady
Genady
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
>Вот например, возьмем такую сущность как книга в библиотеке.
Ну давайте возьмем такую сущность

И предположим, что ее инв. номер складывается из номера шкафа и номера полки и/или ячейки, а теперь предположим, что возникла необходимость книгу переставить, как будет проще отразить сей процесс в БД?

>То есть, речи о ключевых полях там не идёт вообще.

Неточность имеется, конечно, хотя на практике случаются ситуации когда в таблице нет естественных ключей, не так ли?

>Хм, ну так было ведь ключевое поле, которое стало неключевым,
Это как?

>Это поле все равно является кандидат ключом, разве не так?
Конечно так
Форма Бойса-Кодда как раз и отражает такое состояние


>Насчет увеличения производительности: помоему наличие индекса (кластерного) практически уравнивает скорость выборки по int полю и скажем varchar.

Да, но кластерный индекс может быть только один, Вы уверены, что хотите его всегда отдавать для PK?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 10:23
    #32007699
Epanch
Epanch
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Я практически всегда использую СК, т.к а) ничто не вечно под луной; б) размеры ЕК как правило длиннее, что сказывается на размерах таблиц, а то и составные;
Использование ЕК имеет смысл только в очень ограниченном числе случаев, чаше всего когда используются 1-2 буквенные обозначения типа амер. штатов.
Что касается наглядности данных, то виды через объединения обеспечивают полный спектр услуг, и если индексы сделаны правильно, то и на быстродействии это не сказывается.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 12:40
    #32007717
Павел
Павел
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
2 andy
>Вот например, возьмем такую сущность как книга в библиотеке. Каждая книга однозначно характеризуется инвентарным номером, если это перестанет быть правдой, в работе библиотеке произойдут огромные перемены. Так зачем же собственно вводить дополнительный ключ?

А инвентарный номер и есть СK
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 12:53
    #32007719
Genady
Genady
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
>А инвентарный номер и есть СK

необязательно, см. мой пример выше


Хотя, конечно, в моем примере получим составной ключ по двум или трем атрибутам, а если номер берется просто по порядку, тогда да
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 16:19
    #32007749
Павел
Павел
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
2 Genady:
>Хотя, конечно, в моем примере получим составной ключ по двум или трем атрибутам, а если номер берется просто по порядку, тогда да.

По порядку, не по порядку - ключ это только ключ и ничего больше!Главная задача ключа - однозначно идентифицировать запись. А уж как он будет генериться - дело десятое, лишь бы обеспечивал уникальность. Что касается номеров шкафа, полки и/или ячейки - это всего лишь атрибуты, так что переставляйте! А вот если работники библиотеки привыкли извлекать из инвентарного номера полезную для себя информацию о книге или ее расположении, то надо быть готовым, что рано или поздно эта информация перестанет быть актуальной.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 16:49
    #32007754
JINX
JINX
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Возможно кому-то интересно будет прочитать обсуждение по этой теме - там довольно много аргументов как в пользу естественных так и впользу синтетических ключей.

http://www.delphikingdom.com/cgi-bin/talk.cgi?ID=152


ИТстина же скорее в компромиссе - кажому овощу свое место
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.06.2001, 16:57
    #32007756
Garya
GaryaПривилегированный пользователь
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Как человек, имеющий некое отношение к автоматизации библиотек, решил бряцнуть мыслёй по звеньям данной ветки .
>Каждая книга однозначно характеризуется инвентарным номером, если это перестанет быть правдой, в работе библиотеке произойдут огромные перемены...

Считайте, что уже произошли. Не все книги имеют инвентарные номера! Инвентарные номера положены для достаточно ценных книг и для книг малой экземплярности. При этом каждый экземпляр книги числится под отдельным инвентарным номером. А вот ежели ВУЗ-овская библиотека закупает 1000 экземпляров одного учебника, то библиотекари никогда под под каждый из них не заводят отдельный инвентарный номер. В этом случае все 1000 экземпляров числятся на одной учетной карточке скопом. А кроме литературы, которая числится на учетных карточках и под инвентарными номерами существует еще брошюрный фонд (малоценная литература, не имеющая заявленной ценности и списываемая по бухучету сразу по приходу), но числящаяся в составе брошюр в голом количестве без стоимости. А еще есть периодика - это вообще отдельная песня.
Когда все это берешься автоматизировать, то может выясниться, что одно и то же наименование литературы вдруг числится одновременно и на учетных карточках, и по инвентарным номерам, и в брошюрном фонде. Я привожу не голые измышления, а случай из практики - сначала была очень ценная брошюра всего в двух экземплярах на инвентарных номерах, потом появилась возможность купить сразу полсотни экземпляров и ценность ее снизилась, а потом почти за бесценок взяли целый грузовик и сгрудили в брошюрный фонд. И какой же тогда ЕК? Если думаете, что наименование, то тоже ошибаетесь. Одно и то же наименование книги, но несколько раз переизданное, рассматривается библиотекарями как разные сущности.
Я делаю просто - создаю СК и предоставляю библиотекарям решать, что является сущностью. И даю возможность этой сущности числиться во всех системах учета и фондах одновременно. И библиотекарям это нравится.
Предпочитаю никогда не использовать ЕК. Что является ЕК для человека? Номер паспорта? А если он потеряет паспорт, или сменит гражданство, или очередной закон потребует изменить форму паспорта (что уже происходило)? Что, от этого изменится сущность? Человека как сущность вообще ничем не возможно идентифицировать естественно. Эта идентификация производится скорее на абстрактном уровне, и он не систематизируется. Даже две абсолютно внешне идентичные биологически личности могут оказаться клонами или близнецами, и разными сущностями. Фамилии изменчивы, номера регистрационные тоже. Предоставьте пользователю принимать решение - та же перед ним сущность или уже другая, если у этой сущности а) выдернули зуб б) отрубили руку г) испепелили д) отпочковали клона.

Не говоря уже о том, что большинство ЕК по размерам существенно превосходят СК. И не содержат встроенных средств для устранения конфликтов репликации . Даже ИНН может совпасть, если речь идет о двух организациях, зарегистрированных в разных странах (в России и на Украине, например).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2001, 05:23
    #32007776
Genady
Genady
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
>А вот если работники библиотеки привыкли извлекать из инвентарного номера полезную для себя информацию о книге или ее расположении, то надо быть готовым, что рано или поздно эта информация перестанет быть актуальной.

Так я об этом и говорю, разве нет ?

Вон Garya, все подтверждает

Народ заходите в обсуждение материалов сайта, статейки читайте
пообсуждаем, там еще есть статья о трехзначной логике в БД (О допустимости значений Null) я ее пока не прочитал, но полагаю тоже всем будет интересно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2001, 07:04
    #32007787
Chicago
Chicago
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Один довод против использования ЕК. Как раз на примере инвентарного номера. Ясно, что в нем не один и не два символа. Соответственно, оператор при его ввводе может элементарно ошибиться. И эта ошибка очень даже вероятно может быть замечена только после того как на данную ошибочную запись появятся ссылки в других таблицах. И как тогда ошибочно введенный номер исправлять при наличии referential integrity? Хорошо, если есть каскадное обновление. А если нет? Писать специальную хранимую процедуру, которая будет бегать по всем зависимым таблицам и вносить исправления? А если система будет обновляться уже в ходе эксплуатации? Вы сразу вспомните о необходимости коррекции этой чертовой процедуры, когда в схеме данных появится новая зависимость? Или когда система при первом обращении к этой хп оператора пошлет? С суррогатным ключом этих проблем просто не будет. Изменение можно будет внести только в базовую таблицу для инвентарных номеров.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2001, 08:19
    #32007799
andy
andy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
2 Garya: где не заводят, а где и заводят и еще и штрих код наклеивают.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2001, 08:40
    #32007805
Александр Гладченко
Александр Гладченко
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Chicago < И№ можно строить автоматически или предоставляя пользователю возможность собирать его, как в конструкторе, оперируя понятными ему элементами. Например, у нас И№ - это балансовый счёт, который можно составить выбрав главу баланса и т.д., а хвостик вычислить автоматически, как просто следующий по порядку в этой группе номер.
Тогда подобных ошибок оператора не будет (по крайней мере, так часто... )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2001, 08:45
    #32007808
Genady
Genady
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
>Например, у нас И№ - это балансовый счёт, который можно составить выбрав главу баланса и т.д., а хвостик вычислить автоматически, как просто следующий по порядку в этой группе номер.

Это как? Совмещается ЕК с СК?
Пока не знаю почему, но что-то мне здесь не равится
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2001, 08:30
    #32007901
Chicago
Chicago
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
Александру Гладченко

> И№ можно строить автоматически или предоставляя пользователю возможность собирать его, как в конструкторе,
> оперируя понятными ему элементами.

Хорошо, если так. А у нас собственно нет И№, а есть банковский расчетный расчетный счет. С нашей точки зрения (как клиентов банка) он не состоит из понятных нам элементов, для нас это всего лишь 20 цифр, которые надо забить в платежное поручение перед его экспортом из нашей информационной системы в банковскую. В большинстве случаев это приходится делать вручную, так как документы, получаемые от контрагентов, отличаются ну очень большим разнообразием в части размещения на них банковских реквизитов и автоматическое сканирование невозможно. Естественно, ошибки неизбежны. К счастью, есть ключевание счетов, но оно спасает не всегда. Иногда об ошибке узнаешь только из очередной выписки, извещающей об отклонении платежки. Так что я просто счастлив, что в нашем справочнике счетов ключ суррогатный.

Электронные документы это вообще мечта, даже и не знаю, когда наши ДУМОрощенные юристы определятся с их легитимностью. В Германии вот Закон об электронной подписи кодифицировали (надеюсь, что последнее слово воспроизвел точно, не смейтесь надо мной специалисты). В общем... В Москву... В Москву... Простите, в Мюнхен!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2001, 16:34
    #32007965
andy
andy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
2Genady:

Думаю так:
ИН - тип документа, который лежит в отдельной таблице

№ - его номер, уникальный внутри типа

ключ - тип_айди + номер. Если на него нужно делать ссылку из других таблиц, может быть удобнее добавить СК. Это уже каждый сам решает.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2001, 05:26
    #32007976
Genady
Genady
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Всем кто не читал советую прочитать статейку
>Если на него нужно делать ссылку из других таблиц, может быть удобнее добавить СК. Это уже каждый сам решает.

Так я потому и обратил внимание на статью, что по моему в ней доходчиво описано, что СК удобнее практически в любом случае.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Всем кто не читал советую прочитать статейку / 17 сообщений из 17, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]