ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Суррогатные ключи
14 сообщений из 14, страница 1 из 1
Суррогатные ключи
    #33264619
иррационализатор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
иррационализатор
Гость
Типичным практическим широчайше распространенным приемом является определение суррогатных ключей для таблиц как целых чисел - значений автоматически увеличивающихся последовательностей (AUTOINCREMENT, SEQUENCE, GENERATOR...). В результате, значения суррогатов для различных таблиц совместимы и есть возможность JOIN, хотя foreign key указывают на абсолютно различные таблицы.

Это ИМХО, яркий пример того, что разработчики СУБД поленились .

Как я представил бы более корректное решение?
Основная идея - значения суррогатов для различных таблиц должны быть несовместимы.
Дополнительные идеи:
1. Поддержка в СУБД счетчиков для генерации суррогатных ключей весьма практична и полезна.
2. Хранимое в БД значение суррогатного ключа должно также содержать информацию о типе ключа, значение счетчика, контрольную сумму.
Например:
Код: plaintext
1.
2.
3.
4.
5.
struct surrogate_value {
        int16   surrogate_class_id,
        int32   surrogate_counter_value,
        int16   check_sum
}
3. Для пользователей СУБД строковое представление значения ключа должно быть "бессмысленным",
и скрывать внутреннюю структуру, причем таким, чтобы ввод допустимого значения (не полученного из БД) был весьма маловероятным.
4. В DDL добавить явные конструкции для создания суррогатных ключей.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
CREATE TABLE Customer (
        id      SURROGATE KEY,
        ...
);
-- здесь СУБД должна создать суррогатный тип CUSTOMER_KEY_SURROGATE
-- и установить что id - первичный ключ таблицы

CREATE TABLE Order (
        id      SURROGATE,
        cust_id CUSTOMER_KEY_SURROGATE REFERENCES Customer
        ...
);
...
Рейтинг: 0 / 0
12.09.2005, 16:38
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264644
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
афтар3. Для пользователей СУБД строковое представление значения ключа должно быть "бессмысленным",
и скрывать внутреннюю структуру, причем таким, чтобы ввод допустимого значения (не полученного из БД) был весьма маловероятным.

таблички они иногда портятся и нужно вручную что-то править.
в вашем случае все накроется, "а чем накроется вам всем хорошо известно" (с)
...
Рейтинг: 0 / 0
12.09.2005, 16:44
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264657
иррационализатор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
иррационализатор
Гость
Рыжий Кот
таблички они иногда портятся и нужно вручную что-то править.
в вашем случае все накроется, "а чем накроется вам всем хорошо известно" (с)
блин, ну для продвинутых DBA можно и утилиту соорудить для генерации допустимых значений суррогатов.
...
Рейтинг: 0 / 0
12.09.2005, 16:49
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264672
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, иррационализатор!
Ты пишешь:

иррационализатор[Sorry, skipped]
и> Это ИМХО, яркий пример того, что разработчики СУБД поленились.
и> Как я представил бы более корректное решение?
и> Основная идея - значения суррогатов для различных таблиц должны быть несовместимы.
Дилема стара как мир и мало кому интересна.
Естественные ключи против искуственных ключей

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
12.09.2005, 16:53
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264707
иррационализатор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
иррационализатор
Гость
Мимопроходящий
Дилема стара как мир и мало кому интересна.
Естественные ключи против искуственных ключей

Мимопроходящий, речь не о выборе "СК vs ЕК", а об использовании для СК типов, несовместимых по значениям.
...
Рейтинг: 0 / 0
12.09.2005, 17:03
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264727
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, иррационализатор!
Ты пишешь:

иррационализатори> Мимопроходящий, речь не о выборе "СК vs ЕК",
и> а об использовании для СК типов, несовместимых по значениям.
Надумано.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
12.09.2005, 17:07
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264770
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Это ИМХО, яркий пример того, что разработчики СУБД поленились .

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

> Как я представил бы более корректное решение?

64 байта коту под хвост - это не более корректное решение.
...
Рейтинг: 0 / 0
12.09.2005, 17:27
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264783
иррационализатор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
иррационализатор
Гость
guest_20040621> Как я представил бы более корректное решение?

64 байта коту под хвост - это не более корректное решение.
не байта, a бита :)
...
Рейтинг: 0 / 0
12.09.2005, 17:33
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33264868
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> не байта, a бита

Тем более кривые грабли.
...
Рейтинг: 0 / 0
12.09.2005, 18:09
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33265857
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
иррационализаторВ результате, значения суррогатов для различных таблиц совместимы и есть возможность JOIN, хотя foreign key указывают на абсолютно различные таблицы.
Есть предложение развить этот подход. На сегодня существует даже такая возмутительная возможность, как JOIN по значению, не являющемуся внешним ключом, например

Код: plaintext
1.
from
  a join b on (a.id = b.total_sum)

Как минимум, надо сделать эти значения несовместимыми, например с помощью описанной Вами методики. Но лучше - не значения, а типы данных, чтобы такое sql-предложение давало ошибку компиляции. Еще лучше - запретить join не по внешним ключам; тем самым заставим разработчиков отказаться от привычки не описывать некоторые внешние ключи. А еще лучше - вообще запретить join, поскольку всегда существует опасность того, что он не нужен.
...
Рейтинг: 0 / 0
13.09.2005, 11:35
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33265891
иррационализатор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
иррационализатор
Гость
2 softwarer
СарказмЪ?
...
Рейтинг: 0 / 0
13.09.2005, 11:43
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33265919
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
гладко было на бумаге да забыли про овраги.

В реальной жизни практически нельзя встретить БД отвечающую каким-то
требованиям (нормализация или защищённость или ещё что-то) на 100%.
Высосаные из пальца ограничения будут только мешать. В институте для
обучения - да. И шаг влево/шаг вправо ставить студентам двойки.


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
13.09.2005, 11:51
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33265929
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, 1024!
Ты пишешь:

1024> Высосаные из пальца ограничения будут только мешать.
> В институте для обучения - да.
> И шаг влево/шаг вправо ставить студентам двойки. Полумеры.
Голосую. Убить. (С)

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
13.09.2005, 11:54
| Ответить | Цитировать | Написать  
Суррогатные ключи
    #33287011
??
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
??
Гость
Зря смеетесь. Существуют системы, в которых высказанные идеи частично реализованы. Несовместимость типов и запрет джойнов между разными типами - это идея доменной организации типов, которая была высказана отцами реляционных баз данных. В некоторых бизнес-приложениях (Аксапта, например) доменная система есть: объявляется тип данных, затем делаются поля этого типа. Затем между таблицами протягиваются связи. А приджойнить таблицу, не связанную с данной нельзя посредством встроенного диалекта SQL. так же, как частично нельзя при фильтрации использовать в условиях не те типы данных...
По собственному опыту: такая организация действительно устраняет многие глупые ошибки. Но когда требуется навернуть (а это иногда требуется), начинаются слезы и выписывания циклов ручками...
Для ключей официальной политикой системы является использование строк, которые генерируются или вводятся снаружи. Ключами могут быть и числа, но строки обычно имеют префикс и суффикс, являясь кодом, понятным не только машине, но и (частично) человеку. При правильной настройке механизмов генерации последовательностей ключи разных таблиц не будут совместимы логически.
...
Рейтинг: 0 / 0
24.09.2005, 01:55
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Суррогатные ключи
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]