Ответ на »сообщение 209« (Geo)
___________________________
>>> каждой квартире нужно поставить в соответствие некоторое абстрактное уникальное число,
>>> и в запись для человека прописывать это самое число, а не номер квартиры.

Правильно.
И если появляется неучтённая квартира, то операции с ней можно делать
только после того, как ей будет присвоено "абстрактное уникальное число".

Ответ на »сообщение 207« (Как слышно? Приём!)
___________________________
>>> Если же база данных должна общаться с внешним миром, то либо подавай естественные ключи с правилами их формирования, либо налаживай сервис присвоения искусственных ключей.
Вот и стала ясна причина спора ;-)

Давайте все же определимся, что именно мы понимаем под ключом. Вообще-то базданщики первичными и внешними ключами (primary key, foreign key) понимают способ реализации отношений на таблицах за счет механизмов СУБД. К пользовательскому интерфейсу это не имеет никакого отношения. Пусть у нас БД, учитывающая, в частности, квартиры многоквартирного дома, и людей, которые в этих квартирах живут. Имеется таблица людей (с их атрибутами) и таблица квартир (с их атрибутами). Для реализации отношения "Человек проживает в такой-то квартире" сторонники естественных ключей считают, что надо в записи для человека ввести поле, в котором прописывать номер квартиры. А сторонники искусственных ключей считают, что каждой квартире нужно поставить в соответствие некоторое абстрактное уникальное число, и в запись для человека прописывать это самое число, а не номер квартиры.

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

Ответ на »сообщение 207« (Как слышно? Приём!)
___________________________
Если же база данных должна общаться с внешним миром, то либо подавай естественные ключи
с правилами их формирования Это устоявшееся заблуждение. Результат: всякие там ОКОНХ, ОКПО, ИНН, и прочие числа зверя. По сути это пережитки тех времен, когда в каждом уездном городке изобретали свою систему учета. Достаточно было бы для всех объектов учета иметь только один идентификатор, тогда даже бумажные квитанции заполнять было бы гораздо проще. Тем более, что так или иначе для регистрации любого ларька требуется отправить данные в какие-то центральные БД, нет ни каких проблем получить значение нового идентификатора исключив вероятность повторения.

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

Ответ на »сообщение 205« (Geo)
___________________________
Вот Ваши слова
>>> искуссвтенные первичные ключи предназначены только для того, чтобы обеспечивать целостность данных внутри системы, не вылезая наружу.

Вот мои
>>> Но если БД эксплуатируется с выходом и входом в реальную жизнь, например, на бумажные носители,
>>> то некий сервис обработки и поддержания естественных ключей неизбежен.

Не видно корреляции?

Ответ на »сообщение 201« (Как слышно? Приём!)
___________________________
>>> Как тебе песенка 38652004?
>>> Не-а, мне больше 79223133 по душе :)
...
>>> Тут придумывают ИНН с процедурами регистрации - сервис поддержки суррогатных ключей
У меня складывается впечатление, что Вы не совсем себе понимаете, что такое искусственные ключи и зачем они нужны. Но сначала (как водится) аналогия

-- А как мне в Вашей программе ввести ФИО пользователя?
-- Откройте форму TForm1 ;-)

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

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

Ответ на »сообщение 202« (Cepгей Poщин)
___________________________
>>> Речь о случаях когда например по табельному номеру выстраиваются связи главный подчиненный.

Это да.
Но если база живая то табельный номер для налоговой, скажем, или страховой компании,
которые собирают данные с нескольких предприятий не проходит.
Тут придумывают ИНН с процедурами регистрации - сервис поддержки суррогатных ключей.

Ответ на »сообщение 202« (Cepгей Poщин)
___________________________
>>> по табельному номеру выстраиваются связи главный подчиненный
Не люблю быть ни главным, ни подчинённым.
Поэтому я табельные номера и не перевариваю :)

>>> Да, не люблю [философию].
Вот в этом углу философия, а в том - эклектика и софистика.

Ответ на »сообщение 201« (Как слышно? Приём!)
___________________________
Как тебе песенка 38652004? По моему это несколько не то. Речь о случаях когда например по табельному номеру выстраиваются связи главный подчиненный.
Не любите Вы философию :) Да, не люблю. Потомучто под любую ситуацию можно найти соответствующее изречение и в результате тот, кто лучше владеет искусством софистики и эклектики, оказывается прав, только какое это имеет отношение к практической целесообразности.

Ответ на »сообщение 200« (Geo)
___________________________
>>> в голову никому не придет использовать естественные ключи

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

Представляю, скажем, обсуждение музыкальных записей.
Как тебе песенка 38652004?
Не-а, мне больше 79223133 по душе :)

>>> Для создания идентификаторов все пользуются стандартными средствами безо всякой философии.

Не любите Вы философию :)
А, по моему, при росте скорострельности техники на четыре-пять порядков
использовать прежние подходы неестественно по философским основаниям.