Ответ на »сообщение 218« (Geo)
___________________________
Тимур, Вы сюда пофлеймить зашли или действительно обсудить вопрос? Пока впечатление такое, что все же имеет место первый вариант: Вы вмешались в чужую беседу, наприводили кучу цитат из букварей и сборников басен (не всегда к месту) и... и я даже не знаю, отвечать Вам по существу или нет.

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

>>> Преимущества исчезли?
Нет, но выбранное направление развития СУБД привело к серьезному уменьшению недостатков одного подхода. Недостатки же второго остались без изменения.

Если поддержка SEQUENCE, заложенная в стандарте SQL, снижает недостатки первого подхода, то, в таком случае, поддержка каскадных изменений, видимо снижает недостатки "второго подхода". Ниже тобой же сказано: Одним из основных недостатков естественных ключей является то, что атрибуты сущностей могут измениться (хоть и стараются для ключей использовать такие свойства объектов реального мира, которые мало подвержены изменениям). При таком изменении возникает необходимость пройти по всем подчиненным таблицам и поправить значения внешних ключей в соответствии с изменившимся значением первичного ключа основной таблицы. Механизм каскадного обновления берет выполнение этой задачи на себя, соответственно, этот недостаток тоже минимизируется.
Следовательно, недостатки "второго" тоже изменились. Сплошные противоречия.

>>> Обеспечение целостности данных не зависит от типа ключа
Перечитайте еще раз мои слова, на которые Вы отвечали, и укажите, где я говорил, что обеспечение целостности зависит от типа ключа.
Вот твои слова: Я после проб и ошибок склонился к искусственным ключам. Несмотря на наличе какадных обновлений, которые позволяли осуществлять связи по содержательным полям.
Каскадные изменения для того и предназначены, чтобы поддерживать ссылочную целостность, но несмотря на это выбираются искусственные ключи. Хотя они не исключают потребности в каскадных изменениях. Получается полная несуразица, что и было отмечено.

>>> Человек сваливает в одну кучу ключи и каскадные изменения, приводит, мягко говоря, странные решения надуманных проблем. И безапелляционно заявляет, что он выбирает искусственные ключи.
Надеюсь, я прояснил для Вас причины "странностей", и показал, что в данном случае "куча" -- это не хаотическая свалка, а специальным образом выстроенная куча, предназначенная для решения вполне конкретной задачи.

Да, "куча" совершенно неслучайна. Подбором нелепостей и банального незнания "букварей" делается очередная попытка доказать правильность своей позиции. Это, конечно, не ново, но очень показательно.

Если Вы любитель строгих бесед, то давайте с Вами будем беседовать строго.
Не будем, на дверь мне уже указали. Оставайся при своем мнении. Сочетание такого апломба, такой "грамотности" и желания избавиться от неугодного собеседника, делает общение пустой перепалкой.

Тимур, Вы сюда пофлеймить зашли или действительно обсудить вопрос? Пока впечатление такое, что все же имеет место первый вариант: Вы вмешались в чужую беседу, наприводили кучу цитат из букварей и сборников басен (не всегда к месту) и... и я даже не знаю, отвечать Вам по существу или нет.

Но давайте пока попробуем...

>>> Преимущества исчезли?
Нет, но выбранное направление развития СУБД привело к серьезному уменьшению недостатков одного подхода. Недостатки же второго остались без изменения.

>>> Проектировать базы лучше на основе знаний теории баз данных и предметной области. А инструмент (СУБД) выбирать, исходя из задачи.
Цитата из букваря. К моему сообщению не имеет ни малейшего отношения. Потому что я говорил о том, что практически во всех современных СУБД имеются более или менее развитые средства поддержки искусственных ключей. Так что какую ни выбирай, а...

>>> Какое отношение имеют каскадные изменения к выбору ключа?
Одним из основных недостатков естественных ключей является то, что атрибуты сущностей могут измениться (хоть и стараются для ключей использовать такие свойства объектов реального мира, которые мало подвержены изменениям). При таком изменении возникает необходимость пройти по всем подчиненным таблицам и поправить значения внешних ключей в соответствии с изменившимся значением первичного ключа основной таблицы. Механизм каскадного обновления берет выполнение этой задачи на себя, соответственно, этот недостаток тоже минимизируется.

>>> Самоуверенность не признак ума
Врачу! Исцелися сам.

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

>>> Ключ - это подмножество атрибутов, уникальным образом определяющие некоторую запись (кортеж) в составе множества записей (отношения).
>>> Внешний ключ - механизм обеспечения ссылочной целостности. Внешнему ключу ссылочной таблицы должен соответствовать первичный ключ главной таблицы.
Очередные цитаты из букваря. Вы даже не поняли, что я определял назначение ключей. И не поняли, почему я это определял. Так часто бывает, когда влезаешь в чужую беседу, услышав всего лишь последнюю фразу в разговоре. Да, сформулировал я не лучшим образом, но я не букварь писал, а давал вполне конкретные пояснения вполне конкретному человеку. И моя корявая формулировка цели достигла.

>>> Если человек имеет <...>
То же самое. Я приводил упрощенный пример для пояснения собственной мысли, а вовсе не занимался проектированием реальной базы данных. Когда в шестом классе средней школы вводят понятие "ускорение свободного падения" то решают задачи, в которых Земля считается плоской, ускорение свободного падения постоянно, а сопротивлением воздуха пренебрегают. И тут появляетесь Вы (весь в ослепительно белом) и "открываете всем глаза" на то, как на самом деле устроен мир.

>>> Человек сваливает в одну кучу ключи и каскадные изменения, приводит, мягко говоря, странные решения надуманных проблем. И безапелляционно заявляет, что он выбирает искусственные ключи.
Надеюсь, я прояснил для Вас причины "странностей", и показал, что в данном случае "куча" -- это не хаотическая свалка, а специальным образом выстроенная куча, предназначенная для решения вполне конкретной задачи.

Если Вы любитель строгих бесед, то давайте с Вами будем беседовать строго. Но тогда уже без ссылок на Эзопа. И это... изучили бы теорминимум по правилам хорошего тона.

Ответ на »сообщение 216« (Cepгей Poщин)
___________________________

Ответ на »сообщение 213« (Тимур и Ко)
___________________________
"Виноград зелен, объявила всем лиса, не сумев его достать" (Эзоп). Лисы едят мясо!
От за это, я и не люблю философию, куча глубокомысленных замечаний и не одного по существу.
Нет здесь "философии". Человек сваливает в одну кучу ключи и каскадные изменения, приводит, мягко говоря, странные решения надуманных проблем. И безапелляционно заявляет, что он выбирает искусственные ключи. Вот так и рождаются мифы о "зеленом винограде".

Ответ на »сообщение 213« (Тимур и Ко)
___________________________
"Виноград зелен, объявила всем лиса, не сумев его достать" (Эзоп). Лисы едят мясо!
От за это, я и не люблю философию, куча глубокомысленных замечаний и не одного по существу.

Ответ на »сообщение 209« (Geo)
___________________________

Ответ на »сообщение 207« (Как слышно? Приём!)
___________________________
Давайте все же определимся, что именно мы понимаем под ключом. Вообще-то базданщики первичными и внешними ключами (primary key, foreign key) понимают способ реализации отношений на таблицах за счет механизмов СУБД.

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

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

Если человек имеет более одной квартиры или в базе данных появляются несколько домов с одинаковыми номерами квартир, то "проектировщики" "чешут Гондурас".
Неудачное решение: приписывать свои проблемы всем проектировщикам.

Ответ на »сообщение 205« (Geo)
___________________________

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

Обеспечение целостности данных не зависит от типа ключа.

Ответ на »сообщение 200« (Geo)
___________________________

Ответ на »сообщение 199« (Тимур и Ко)
___________________________
Просто сначала люди еще колебались, какие ключи использовать. Свои преимущества были и у того, и у другого подхода.

Преимущества исчезли?

А сточки зрения поддержки со стороны СУБД оба подхода были равноценны. И каждый человек сам для себя решал, как лучше проектировать базы.

Проектировать базы лучше на основе знаний теории баз данных и предметной области. А инструмент (СУБД) выбирать, исходя из задачи.

Я после проб и ошибок склонился к искусственным ключам. Несмотря на наличе какадных обновлений, которые позволяли осуществлять связи по содержательным полям.

Какое отношение имеют каскадные изменения к выбору ключа? Составными могут быть, как ЕК, так и СК.
"Виноград зелен, объявила всем лиса, не сумев его достать" (Эзоп).

А теперь уже, наверное, и в голову никому не придет использовать естественные ключи (за исключением, разве что, особых экзотических случаев).

Самоуверенность не признак ума.

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

Ответ на »сообщение 210« (Как слышно? Приём!)
___________________________
>>> только после того, как ей будет присвоено "абстрактное уникальное число"
Аргументация десятилетней давности. Сейчас это "абстрактное уникальное число" СУБД присваивает новой записи сама. Причем, СУБД гарантирует уникальность значения в рамках таблицы БД.

В рограммировании Вы заводите новую переменную, ей назначается определенный адрес (абстрактное уникальное число). Вас этот момент не смущает? ;-)