Курс по SQL

[iifat]

rockclimber в сообщении #1324516 писал(а):

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

Таки главное неудобство естественных ключей — в их отсутствии. Ключ должен быть уникален и неизменен. Какой естественный ключ идентифицирует человека? Упоминались ФИО и день рождения — во-первых, на большой базе неизбежны дубли; во-вторых, все (все!) эти параметры можно изменить. Ну вот разве генетический код подошёл бы, но это дорого во всех смыслах.
Ну и чтоб два раза не вставать:

rockclimber в сообщении #1324294 писал(а):

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

Это не так.
Вот пишем БД бланков паспортов. Ну, тех книжечек, которые есть у каждого. Для завода-производителя. По ним же надо отчитываться. Сделали новую партию; нечаянно порвали пару (затопило канализацией пару ящиков); храним на складе; отправили куда полагается — подозреваю, там нужен индивидуальный учёт и отчётность.
Естественно, сделали суррогатный ключ — двусоставной, серию и номер.
А как выдали человеку — всё: наш суррогатный ключ волшебным образом превратился в естественный атрибут человека. Он вписывается в (ну, почти) все документы и хранится в (почти) всех БД наряду с фамилией и прочим.
И это всё, что нужно знать об отличиях суррогатного ключа от натурального.

[rockclimber]

iifat в сообщении #1325073 писал(а):

Естественно, сделали суррогатный ключ — двусоставной, серию и номер.

Не согласен, это естественный.

-- 08.07.2018, 03:35 --

beroal в сообщении #1325050 писал(а):

rockclimber в сообщении #1324557 писал(а):

beroal в сообщении #1324552

wrote:
Следующий шаг — сделать первичные ключи абстрактными Ээээ... А можно вас попросить уточнить, чем абстрактный ключ отличается от суррогатного?

Да не вопрос, конечно, можно. Абстрактному ключу программист не назначает тип данных, не назначает автоинкремент или генератор значений ключа (зависит от СУБД). Всё равно эти параметры стандартны и не зависят от задачи.

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

beroal в сообщении #1324552 писал(а):

Вообще-то, понятия «естественный ключ» и «суррогатный ключ» нужно убрать из учебного курса.

Будете писать свой курс - уберете. А в моем курсе эти понятия нужно оставить.

[iifat]

rockclimber в сообщении #1325075 писал(а):

Не согласен, это естественный

Что в нём естественного? Чем отличается (пока не заполнены данные) одна книжечка от другой? Серия — типичный счётчик.

[realeugene]

iifat в сообщении #1325073 писал(а):

Таки главное неудобство естественных ключей — в их отсутствии. Ключ должен быть уникален и неизменен. Какой естественный ключ идентифицирует человека? Упоминались ФИО и день рождения — во-первых, на большой базе неизбежны дубли; во-вторых, все (все!) эти параметры можно изменить. Ну вот разве генетический код подошёл бы, но это дорого во всех смыслах.

Любая БД со своими внутренними логическими связями между объектами, используемыми в процессе нормализации - это некоторая абстракция, лишь отражающая естественные объекты и связи между ними, нужные для некоторой задачи. Понятно, что в мире нет ничего неизменного. Но для некоторой конкретной задачи, например, в рамках одного дня, те же ФИО могут считаться уникальными идентификаторами.

[upgrade]

rockclimber в сообщении #1324516 писал(а):

Главное неудобство естественных ключей в том, что вы должны ссылаться из другой таблицы на полный ключ (потому что часть ключа ключом не является). Допустим, у вас в таблице PERSON первичный ключ определен как (FIRST_NAME, LAST_NAME, BIRTHDATE). Тогда, делая ссылку на человека из таблицы PHONE_NUMBER, вы должны и в ней создать поля FIRST_NAME, LAST_NAME, BIRTHDATE. Потом вы создадите таблицу для, например, инвентаризации оборудования и будете заполнять, кому какое оборудование выдали. И туда эти три поля добавите.

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

[iifat]

realeugene в сообщении #1325103 писал(а):

БД ... - это некоторая абстракция

Забыли добавить, что Волга впадает в Каспийское море.

realeugene в сообщении #1325103 писал(а):

например, в рамках одного дня, те же ФИО могут считаться уникальными идентификаторами

Пока к вам не прибежит такой радостный полярный лис: «Ой, а я три дня назад женился/замуж вышла, вот, вчера паспорт новый получил(а)!»

upgrade в сообщении #1325109 писал(а):

пытаюсь вообще не использовать ключи

Эээ... Не понял. Ключи, как они определены вот тут, это вообще свойство предметной области. Люди — предмет индивидуального учёта. А, к примеру, сахар на сахарном заводе — нет.

[upgrade]

iifat в сообщении #1325114 писал(а):

Ключи, как они определены вот тут, это вообще свойство предметной области. Люди — предмет индивидуального учёта. А, к примеру, сахар на сахарном заводе — нет.

Ключ - это не данные, вернее он не используется как данные, он используется как указатель на данные. Я не использую указатели, а работаю только с данными везде где это возможно. Т.о. существуют только операции объединения множеств, пересечения, исключения ... важно лишь верно определить как строить требуемое множество. В таком подходе в ключах нет необходимости. Но без ключей не обеспечить целостность данных, насколько я понимаю. Конкретная строка - это элемент множества, куча строк (таблица) - это всё множество. Набор множеств - это база данных. Если каждой строке назначить идентификатор (ключ) то будет пронумерованное (упорядоченное?) множество. Задать поле данных, данные в котором не могут повторяться и не могут быть пустыми, можно и без использования ключей.
Работа с БД в данном случае сводится к различным вариантам перебора подмножеств.

[iifat]

upgrade в сообщении #1325147 писал(а):

Я не использую указатели, а работаю только с данными везде где это возможно

Это как? Вместо чтоб использовать ключ сущности, вставлять всю сущность? Это, простите, вообще бред. Сущность может в себя включать при нормальном подходе пару десятков таблиц по нескольку строк в каждой.

upgrade в сообщении #1325147 писал(а):

В таком подходе в ключах нет необходимости

Этот подход вообще перпендикулярен использованию ключей.

upgrade в сообщении #1325147 писал(а):

Работа с БД в данном случае сводится к различным вариантам перебора подмножеств

Работа с БД вообще в любом случае «сводится к различным вариантам перебора подмножеств» и никак иначе.

[upgrade]

iifat в сообщении #1325156 писал(а):

Это как? Вместо чтоб использовать ключ сущности, вставлять всю сущность?

Чтобы узнать какой ключ использовать все равно придется это делать.

[realeugene]

iifat в сообщении #1325114 писал(а):

Пока к вам не прибежит такой радостный полярный лис: «Ой, а я три дня назад женился/замуж вышла, вот, вчера паспорт новый получил(а)!»

Завтра будет новая таблица.

[beroal]

upgrade в сообщении #1325147 писал(а):

куча строк (таблица) - это всё множество

Есть нюанс: таблица есть мешок (мультимножество). Это важно, когда используются агрегирующие функции.

[rockclimber]

iifat в сообщении #1325076 писал(а):

rockclimber в сообщении #1325075 писал(а):

Не согласен, это естественный

Что в нём естественного? Чем отличается (пока не заполнены данные) одна книжечка от другой? Серия — типичный счётчик.

Это суррогатный ключ с точки зрения государства, но естественный - с точки зрения всех остальных. Когда государство взаимодействует с человеком, для государства "естественным ключом" является ФИО, дата рождения, родители и прочая информация. Но это все ведет к проблемам, озвученным выше. Поэтому государство придумывает суррогатный ключ - серию и номер паспорта, которые просто являются счетчиками по сути. А вот когда вы автоматизируете какую-то деятельность, где вы должны взаимодействовать с гражданами государства (например, банки обязаны, согласно требованиям ЦБ, перед каждой операцией установить личность человека, то есть потребовать документы, причем граждан разных государств в некоторых случаях можно обслуживать по-разному), там для вас идентификатором гражданина государства является документ, выданный этим государством, а атрибуты этого документа (серия, номер и пр.) являются для вас естественным ключом.

-- 09.07.2018, 10:43 --

upgrade в сообщении #1325109 писал(а):

rockclimber в сообщении #1324516 писал(а):

Главное неудобство естественных ключей в том, что вы должны ссылаться из другой таблицы на полный ключ (потому что часть ключа ключом не является). Допустим, у вас в таблице PERSON первичный ключ определен как (FIRST_NAME, LAST_NAME, BIRTHDATE). Тогда, делая ссылку на человека из таблицы PHONE_NUMBER, вы должны и в ней создать поля FIRST_NAME, LAST_NAME, BIRTHDATE. Потом вы создадите таблицу для, например, инвентаризации оборудования и будете заполнять, кому какое оборудование выдали. И туда эти три поля добавите.

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

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

[rascas]

mustitz в сообщении #1322924 писал(а):

Есть гарантия неизменности в пределах сессии. Иначе зачем бы он вообще был нужен?

Не верное утверждение. В пределах сессии ROWID вполне может поменяться. Пример для СУБД Oracle:

Используется синтаксис SQL

SQL> CREATE TABLE test1 (c1 NUMBER);
 
TABLE created
 
SQL> INSERT INTO test1 SELECT rownum FROM user_objects WHERE rownum<4;
 
3 ROWS inserted
 
SQL> SELECT rowid,c1 FROM test1;
 
ROWID                      C1
------------------ ----------
AAAdCmAAEAAAAClAAA          1
AAAdCmAAEAAAAClAAB          2
AAAdCmAAEAAAAClAAC          3
 
SQL> ALTER TABLE test1 move;
 
TABLE altered
 
SQL> SELECT rowid,c1 FROM test1;
 
ROWID                      C1
------------------ ----------
AAAdCnAAEAAAACrAAA          1
AAAdCnAAEAAAACrAAB          2
AAAdCnAAEAAAACrAAC          3
 
SQL> 
 

[upgrade]

rockclimber в сообщении #1325332 писал(а):

Первичный ключ гарантирует уникальность (отсутствие дубликатов)

"Иванов Иван" в ключевом поле значение 1
"Иванов Иван" в ключевом поле значение 2
Всё равно используемые данные проверять на уникальность перед присвоением ключа, либо в ключе должны содержаться данные.

rockclimber в сообщении #1325332 писал(а):

внешний ключ - ссылочную целостность (отсутствие записей, ссылающихся "вникуда", корректность существующих ссылок)

Вот только это (целостность данных), но я уже целых пару лет обхожусь проверкой на "Null" таких ссылок...в таблицах количеством где-то штук 10 и общим объемом уникальных данных 2 Гб...
Может это и неправильно, у нас же как - фундаментальная ошибка вылезает когда уже ничего поправить нельзя. Вот и не хочется ошибиться.

[rascas]

upgrade в сообщении #1325403 писал(а):

rockclimber в сообщении #1325332 писал(а):

внешний ключ - ссылочную целостность (отсутствие записей, ссылающихся "вникуда", корректность существующих ссылок)

Вот только это (целостность данных), но я уже целых пару лет обхожусь проверкой на "Null" таких ссылок...в таблицах количеством где-то штук 10 и общим объемом уникальных данных 2 Гб...
Может это и неправильно, у нас же как - фундаментальная ошибка вылезает когда уже ничего поправить нельзя. Вот и не хочется ошибиться.

Видите ли в чём дело, различные ограничения БД (constraints) нужны в основном для того, чтобы уменьшить число ошибок в приложении. Эти ограничения позволяют выявить некорректность данных на ранних этапах, и быстро создать качественное приложение.
А так конечно все эти Foreign Key, Not Null, Check, и т.п. создают нагрузку на БД, и для безошибочно работающего приложения не нужны
(Кстати поле Foreign Key может быть и Null. Null не нарушает это ограничение)