Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  17:27[Войти] | [Зарегистрироваться]
Обсуждение темы:
Синтетические и естественные ключи.

Добрый день.

Может кто поможет мне определиться в том, какие ключи лучше использовать в качестве первичных - синтетические или естественные. Я прочитал несколько статей на эту тему, но не уверен, что пришел к определенным выводам. С одной стороны преимущество синтетического ключа кажется неоспоримым исходя из того постулата, что любой объект реального мира подвержен изменениям, иногда кардинальным. Очень многое из того, что кажется незыблемым, может меняться и довольно быстро. Трудно придумать действительно уникальный естественный ключ, например, возьмем таблицу рабочих предприятия. Что взять в качестве первичного ключа? Не буду говорить банальности о смене ФИО, пола, паспорта и т.п. Взять за основу псевдо естественное поле - табельный номер (ведь для того его и придумали)? А теперь представьте ситуацию - предприятие работает долго, имеет обширные архивы на CD-ROM, база эксплуатируется практически непрерывно (вполне реальные параметры для серьезных баз данных). Руководство отделов кадров решило, что теперь табельный номер должен быть не числовой, а текстовой и нести в себе некую доп. информацию (причем это с точки зрения программиста ситуация весьма нестандартная, а с точки зрения отдела кадров проста и менять свои взгляды на формат табельного номера оно может раз в неделю, кстати, на период становления нового стандарта так оно и будет). Что делать? Ну, в общем-то "что" понятно, но, боюсь, что будет плохо и базе и программисту.

С другой стороны в примере с тем же табельным номером абсолютно ясно, что он должен оставаться уникальным на протяжении всей жизни базы и появление искусственного ключа мало того, что нарушает правило нормализации, так еще и противоречит фундаментальному философскому принципу Оккама - "сущности не следует умножать без необходимости" ("Entities should not be multiplied unnecessarily", William of Ockham). Я уж не говорю, что в справочниках, как правило, тоже есть естественные натуральные ключи, а их значения вставляются практически во все таблицы. В таких случаях кажется неестественным организовывать сложнейшие соединения таблиц по 10-20. Кроме того, чем больше синтетических ключей в таблице, тем меньше она несет информации сама по себе и тем больше чувствительна к потерям и ошибкам в связанных таблицах.

Я постарался объяснить, почему ответ - "используй синтетические ключи там, где нельзя использовать естественные", не кажется мне разумным. Т.е. это тот случай, когда желательно все же не действовать по принципу "и ты прав и ты тоже прав".

Sergey

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 290 сообщений

Добавить свое сообщение

Отслеживать это обсуждение
<<<... | 270—261 | 260—251 | 250—241 | ...>>>
Всего сообщений в теме: 290; страниц: 29; текущая страница: 4


№ 260   02-10-2009 08:01 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 258« (Как слышно? Приём!)
___________________________
Потому что без введения кодировки в данном случае создание серьезной базы практически невозможно. Я так и не понял почему, заставить всех соблюдать кодировку возможно, а получать идентификаторы не возможно. Короче зациклились.
Повторю в последний раз: если по каким-либо причинам невозможно использовать идентификаторы (синтетические ключи), то остаётся вводить кодировку (естесственные ключи) и тому подобные костыли. Только это не имеет отношения к обсуждению того, что выбрать. Также как не имеет смысла вопрос "Стоит ли ходить на костылях?". Человек со здоровыми ногами не будет ходить на костылях, а с больными не будет ходить без костылей. Ни одного довода в пользу того, что на костылях ходить лучше, чем пешком (при наличии выбора) я пока не увидел.
 Cep


№ 259   02-10-2009 07:29 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 255« (Cepгей Poщин)
___________________________
Имя, которое не связано с атрибутами объекта, тяжело к нему привязать.
Другой метод - графический, но это уже другая тема.


№ 258   02-10-2009 07:12 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 255« (Cepгей Poщин)
___________________________
>>> Вы не написали в результате чего всё накрылось медным тазом.

Потому что без введения кодировки в данном случае создание серьезной базы практически невозможно.

А то другой случАй - в Иваново материальный учёт таких же сетей вёлся на основе как бы табельных номеров.
В результате некоторые участки были учтены по два и более раз после капитальных ремонтов, в основном.
Когда разгребли эти завалы оказалась недостача на многие миллионы рублей - балансовая стоимость трасс
весьма существенна, а потеряли где-то десять процентов из них.
Заперли мастеров в кабинете директора и пока они не напридумывали трасс (и подписали их существование) не выпускали.


№ 257   02-10-2009 07:05 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 253« (Geo)
___________________________
>>> Запросы строятся по всему дереву?
:)

Понимаете, какое дело.
На реляционных базах (которые, строго говоря, таковыми не являются) свет клином не сошёлся.

А в пансионах, как известно, три главные предмета составляют основу человеческих добродетелей:
французский язык, необходимый для счастия семейственной жизни, фортепьяно,
для доставления приятных минут супругу, и, наконец, собственно хозяйственная часть:
вязание кошельков и других сюрпризов.
Впрочем, бывают разные усовершенствования и изменения в методах, особенно в нынешнее время;
все это более зависит от благоразумия и способностей самих содержательниц пансиона.
В других пансионах бывает таким образом, что прежде фортепьяно, потом французский язык,
а там уже хозяйственная часть. А иногда бывает и так, что прежде хозяйственная часть,
то есть вязание сюрпризов, потом французский язык, а там уже фортепьяно.
Разные бывают методы.


Кстати, вот хороший вопрос:
почему все(!) практические базы данных не удается сделать строго реляционными?
Это вот про хаос в реальности и математический порядок в головах.

>>> Ну, если начальник дурак, то тут ничего сделать не получится.
Нет, начальник вполне симпатичный в смысле ума человек.
Просто в этом вопросе он, как говорится, обезображен высшим образованием.


№ 256   02-10-2009 06:35 Ответить на это сообщение Ответить на это сообщение с цитированием
Еще о ключах в реальном мире.

Современное российское предприятие имеет чертову уйму кодов: его регистрируют в налоговой, в пенсионном фонде, в статорганах и т.д.
При оформлении договора приходится вписывать 3, а то и 5 кодов.
Это все, вроде бы, искусственные ключи реального мира.
Но, дело в том, что эти искусственные ключи представляют собой не порядковый номер, а несут информацию о территориальной и отраслевой принадлежности, т.е. по сути, являются цифровой записью сложного естественного ключа. Поэтому все эти ОКОНХ, ОКПО, ИНН и т.д. будут со временем меняться: при переезде, при изменении границ между территориями и т.д. Типичный пример - банковский счет из 30 десятичных цифр. Это не номер (кому может понадобиться такая прорва номеров?), а сложный естественный ключ в цифровой записи. Сейчас при смене адреса приходится менять часть кодов и, соответственно, сообщать об этом ВСЕМ контрагентам. Это могут быть десятки тысяч. 

Если бы любая фирма получала бы единственный уникальный код госрегистрации, а потом под ним же регистрировалась во всех службах, то документооборот был бы проще. При изменении адреса, организационной формы, перерегистрации и т.д. этот номер не должен меняться. Если его еще закатать на круглую печать, то можно заметно упростить форму договоров.

Это сложнее автоматизировать? Да. Но если принимается закон о сохранении номера мобильного телефона при смене оператора, и это не считается чем-то не реализуемым, то относительно фирм все можно сделать еще проще.

То же самое относительно людей. В США есть, присваиваемый при рождении номер социальной страховки. Его поменять невозможно, в отличии от фамилии имени и пола. Построение баз данных принципиально упрощается.
У нас присвоение личного номера много раз обсуждалось. Как всегда, проблемы возникли из за небрежности в формулировках. Люди, из религиозных соображений, не хотят, чтобы им присваивали номер. В США он и считается не номером человека, а номером карточки страхования. У нас же никто против номера паспорта не протестует.



№ 255   02-10-2009 03:56 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 251« (Как слышно? Приём!)
___________________________
Я Вам примеры ситуаций, а Вы - про раздолбаев.
...
В городе Ярославле потребовалось создать схему
...
В результате всё накрылось медным тазом.
Не вижу противоречий :)
Вы не написали в результате чего всё накрылось медным тазом. Все послали указанного товарища по известному адресу? Товарищч редко появлялся в кабинете и было невозможно узнать у него идентификатор чего-либо? Деньги попилили и на сайт не хватило?
надо провести единую перекодировку - не так и сложно Если не смогли ввести раздачу порядковых номеров, то единую перекодировку тем паче не смогли бы ввести.
 Cep


№ 254   02-10-2009 03:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 251« (Как слышно? Приём!)
___________________________
>>> Но начальник АСУ начал толкать тему об индексации по номерам с автоинкрементом.
>>> Типа пусть ко мне обращаются за идентификаторам
Ну, есди начальник дурак, то тут ничего сделать не получится. Только к чему этот пример? Он показывает как не надо использовать искусственные ключи, но не более того.
 Geo


№ 253   02-10-2009 03:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 250« (Как слышно? Приём!)
___________________________

Не в смысле работающие в сети (антилокальные), а с сетевой парадигмой.
http://ru.wikipedia.org/wiki/Сетевая_СУБД

Прочитал статью. Бестолковая какая-то. Ничего непонятно. Цели введения сетевыз БД не определены. Само понятие тоже не определено (Это принципиально другая СУБД или принцип орагнизации данных в реляционных базах? Сервер оддин или несколько? Запросы строятся по всему дереву или только в рамках своей локальной БД а целостность обеспечивается за счет синхронизации данных?).

Повторюсь... У нас в системе орагнизована иерархическая репликация данных между удаленными базами. Работает как часы. Актуальность данных порядка 10 минут. Объем передаваемых данных небольшой (для выхода в инет в листьях дерева используются даеж радиомодемы). Конфликтов не возникает.

Чем не решение?

>>> Или номер в концлагере
Или номер в концлагере. А чем Вам такой пример не нравится?
 Geo


№ 252   02-10-2009 02:30 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 248« (Geo)
___________________________
>>> Тот же самый табельный номер, по сути, представляет собой искусственный первичный ключ докомпьютерных времен.

Или номер в концлагере.


№ 251   02-10-2009 02:28 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 249« (Cepгей Poщин)
___________________________
>>> Ну так давайте говорить не о достоинствах естественных ключей, а о том, что да, мы раздолбаи

Вот не надо передёргивать!
Речь о том, что реальные (не академические) задачи связаны с хаосом естественным образом.
Кто спорит, что с разжёванной и разложенной по полочкам задачей работать лучше?
Кто спорит, что и машине и программисту легче с целыми числами работать?

Я Вам примеры ситуаций, а Вы - про раздолбаев.

Приведу пример.
В городе Ярославле потребовалось создать схему тепловых сетей.
У них в обозначениях камер код А1 и подобные повторяются в документации несколько раз
для разных камер, разбросанных то там, то сям.
Коды - основа для сбора документации на бумаге от мастеров и инспекторов.
Я им втолковываю, что надо провести единую перекодировку - не так и сложно.
Но начальник АСУ начал толкать тему об индексации по номерам с автоинкрементом.
Типа пусть ко мне обращаются за идентификаторам -
и по телефону, и ногами, и по интернету, и по элпочте, и с центрального сервера.
В результате всё накрылось медным тазом.
А человек принципиальность проявил и вроде в правильном ключе ...


<<<... | 270—261 | 260—251 | 250—241 | ...>>>
Всего сообщений в теме: 290; страниц: 29; текущая страница: 4


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования