2014 dxdy logo

Научный форум dxdy

Математика, Физика, Computer Science, Machine Learning, LaTeX, Механика и Техника, Химия,
Биология и Медицина, Экономика и Финансовая Математика, Гуманитарные науки




На страницу Пред.  1, 2, 3, 4, 5, 6  След.
 
 Re: Курс по SQL
Сообщение08.07.2018, 02:27 
rockclimber в сообщении #1324516 писал(а):
Главное неудобство естественных ключей в том, что вы должны ссылаться из другой таблицы на полный ключ
Таки главное неудобство естественных ключей — в их отсутствии. Ключ должен быть уникален и неизменен. Какой естественный ключ идентифицирует человека? Упоминались ФИО и день рождения — во-первых, на большой базе неизбежны дубли; во-вторых, все (все!) эти параметры можно изменить. Ну вот разве генетический код подошёл бы, но это дорого во всех смыслах.
Ну и чтоб два раза не вставать:
rockclimber в сообщении #1324294 писал(а):
искусственно придуманный ключ, значения которого не имеют практического смысла за пределами базы данных
Это не так.
Вот пишем БД бланков паспортов. Ну, тех книжечек, которые есть у каждого. Для завода-производителя. По ним же надо отчитываться. Сделали новую партию; нечаянно порвали пару (затопило канализацией пару ящиков); храним на складе; отправили куда полагается — подозреваю, там нужен индивидуальный учёт и отчётность.
Естественно, сделали суррогатный ключ — двусоставной, серию и номер.
А как выдали человеку — всё: наш суррогатный ключ волшебным образом превратился в естественный атрибут человека. Он вписывается в (ну, почти) все документы и хранится в (почти) всех БД наряду с фамилией и прочим.
И это всё, что нужно знать об отличиях суррогатного ключа от натурального.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 02:31 
iifat в сообщении #1325073 писал(а):
Естественно, сделали суррогатный ключ — двусоставной, серию и номер.
Не согласен, это естественный.

-- 08.07.2018, 03:35 --

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

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

Да не вопрос, конечно, можно. :-) Абстрактному ключу программист не назначает тип данных, не назначает автоинкремент или генератор значений ключа (зависит от СУБД). Всё равно эти параметры стандартны и не зависят от задачи.
А, теперь понятно. Отрасль, действительно, пока не готова к тому, чтобы выкинуть хорошее и работающее решение и заменить его непойми чем.
beroal в сообщении #1324552 писал(а):
Вообще-то, понятия «естественный ключ» и «суррогатный ключ» нужно убрать из учебного курса.
Будете писать свой курс - уберете. А в моем курсе эти понятия нужно оставить.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 03:09 
rockclimber в сообщении #1325075 писал(а):
Не согласен, это естественный
Что в нём естественного? Чем отличается (пока не заполнены данные) одна книжечка от другой? Серия — типичный счётчик.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 11:44 
iifat в сообщении #1325073 писал(а):
Таки главное неудобство естественных ключей — в их отсутствии. Ключ должен быть уникален и неизменен. Какой естественный ключ идентифицирует человека? Упоминались ФИО и день рождения — во-первых, на большой базе неизбежны дубли; во-вторых, все (все!) эти параметры можно изменить. Ну вот разве генетический код подошёл бы, но это дорого во всех смыслах.
Любая БД со своими внутренними логическими связями между объектами, используемыми в процессе нормализации - это некоторая абстракция, лишь отражающая естественные объекты и связи между ними, нужные для некоторой задачи. Понятно, что в мире нет ничего неизменного. Но для некоторой конкретной задачи, например, в рамках одного дня, те же ФИО могут считаться уникальными идентификаторами.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 13:04 
rockclimber в сообщении #1324516 писал(а):
Главное неудобство естественных ключей в том, что вы должны ссылаться из другой таблицы на полный ключ (потому что часть ключа ключом не является). Допустим, у вас в таблице PERSON первичный ключ определен как (FIRST_NAME, LAST_NAME, BIRTHDATE). Тогда, делая ссылку на человека из таблицы PHONE_NUMBER, вы должны и в ней создать поля FIRST_NAME, LAST_NAME, BIRTHDATE. Потом вы создадите таблицу для, например, инвентаризации оборудования и будете заполнять, кому какое оборудование выдали. И туда эти три поля добавите.
Одна из главных причин, по которой я пытаюсь вообще не использовать ключи, а работать с данными как с множествами векторов с одинаковыми компонентами, хранящихся как попало в мешках (таблицах). Может быть это неверный подход? Где может оказаться засада?

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 13:26 
realeugene в сообщении #1325103 писал(а):
БД ... - это некоторая абстракция
Забыли добавить, что Волга впадает в Каспийское море.
realeugene в сообщении #1325103 писал(а):
например, в рамках одного дня, те же ФИО могут считаться уникальными идентификаторами
Пока к вам не прибежит такой радостный полярный лис: «Ой, а я три дня назад женился/замуж вышла, вот, вчера паспорт новый получил(а)!»
upgrade в сообщении #1325109 писал(а):
пытаюсь вообще не использовать ключи
Эээ... Не понял. Ключи, как они определены вот тут, это вообще свойство предметной области. Люди — предмет индивидуального учёта. А, к примеру, сахар на сахарном заводе — нет.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 16:12 
iifat в сообщении #1325114 писал(а):
Ключи, как они определены вот тут, это вообще свойство предметной области. Люди — предмет индивидуального учёта. А, к примеру, сахар на сахарном заводе — нет.
Ключ - это не данные, вернее он не используется как данные, он используется как указатель на данные. Я не использую указатели, а работаю только с данными везде где это возможно. Т.о. существуют только операции объединения множеств, пересечения, исключения ... важно лишь верно определить как строить требуемое множество. В таком подходе в ключах нет необходимости. Но без ключей не обеспечить целостность данных, насколько я понимаю. Конкретная строка - это элемент множества, куча строк (таблица) - это всё множество. Набор множеств - это база данных. Если каждой строке назначить идентификатор (ключ) то будет пронумерованное (упорядоченное?) множество. Задать поле данных, данные в котором не могут повторяться и не могут быть пустыми, можно и без использования ключей.
Работа с БД в данном случае сводится к различным вариантам перебора подмножеств.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 16:43 
upgrade в сообщении #1325147 писал(а):
Я не использую указатели, а работаю только с данными везде где это возможно
Это как? Вместо чтоб использовать ключ сущности, вставлять всю сущность? Это, простите, вообще бред. Сущность может в себя включать при нормальном подходе пару десятков таблиц по нескольку строк в каждой.
upgrade в сообщении #1325147 писал(а):
В таком подходе в ключах нет необходимости
Этот подход вообще перпендикулярен использованию ключей.
upgrade в сообщении #1325147 писал(а):
Работа с БД в данном случае сводится к различным вариантам перебора подмножеств
Работа с БД вообще в любом случае «сводится к различным вариантам перебора подмножеств» и никак иначе.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 17:53 
iifat в сообщении #1325156 писал(а):
Это как? Вместо чтоб использовать ключ сущности, вставлять всю сущность?
Чтобы узнать какой ключ использовать все равно придется это делать.

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 18:05 
iifat в сообщении #1325114 писал(а):
Пока к вам не прибежит такой радостный полярный лис: «Ой, а я три дня назад женился/замуж вышла, вот, вчера паспорт новый получил(а)!»

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

 
 
 
 Re: Курс по SQL
Сообщение08.07.2018, 18:13 
Аватара пользователя
upgrade в сообщении #1325147 писал(а):
куча строк (таблица) - это всё множество

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

 
 
 
 Re: Курс по SQL
Сообщение09.07.2018, 09:37 
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. Потом вы создадите таблицу для, например, инвентаризации оборудования и будете заполнять, кому какое оборудование выдали. И туда эти три поля добавите.
Одна из главных причин, по которой я пытаюсь вообще не использовать ключи, а работать с данными как с множествами векторов с одинаковыми компонентами, хранящихся как попало в мешках (таблицах). Может быть это неверный подход? Где может оказаться засада?
Первичный ключ гарантирует уникальность (отсутствие дубликатов), внешний ключ - ссылочную целостность (отсутствие записей, ссылающихся "вникуда", корректность существующих ссылок). Соответственно, если вы не пользуетесь ключами, вы можете столкнуться с этими проблемами. А если вы как-то решили эти проблемы - значит, вы фактически написали свои "ключи", с блекджеком багами и тормозами.

 
 
 
 Re: Курс по SQL
Сообщение09.07.2018, 12:55 
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>
 

 
 
 
 Re: Курс по SQL
Сообщение09.07.2018, 13:28 
rockclimber в сообщении #1325332 писал(а):
Первичный ключ гарантирует уникальность (отсутствие дубликатов)

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

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

 
 
 
 Re: Курс по SQL
Сообщение09.07.2018, 14:26 
upgrade в сообщении #1325403 писал(а):
rockclimber в сообщении #1325332 писал(а):
внешний ключ - ссылочную целостность (отсутствие записей, ссылающихся "вникуда", корректность существующих ссылок)
Вот только это (целостность данных), но я уже целых пару лет обхожусь проверкой на "Null" таких ссылок...в таблицах количеством где-то штук 10 и общим объемом уникальных данных 2 Гб...
Может это и неправильно, у нас же как - фундаментальная ошибка вылезает когда уже ничего поправить нельзя. Вот и не хочется ошибиться.
Видите ли в чём дело, различные ограничения БД (constraints) нужны в основном для того, чтобы уменьшить число ошибок в приложении. Эти ограничения позволяют выявить некорректность данных на ранних этапах, и быстро создать качественное приложение.
А так конечно все эти Foreign Key, Not Null, Check, и т.п. создают нагрузку на БД, и для безошибочно работающего приложения не нужны :-)
(Кстати поле Foreign Key может быть и Null. Null не нарушает это ограничение)

 
 
 [ Сообщений: 79 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group