powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Составные поля, альтернатива
21 сообщений из 21, страница 1 из 1
Составные поля, альтернатива
    #32805525
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В базе активно используются составные первичные ключи (база распределенная).
В итоге, имеем следующее неудобство:
- например, заявка (практически тов.накладная):
1. Кто оформил - ссылка на штатное расписание - 3 поля
2. Кто принял - 3 поля
3. Грузоотправитель - 2 поля
4. Грузополучатель - 2 поля
5. Пункт отгрузки - 2 поля
6. Пункт разгрузки - 2 поля
7. Поставщик - 2 поля
8. Покупатель - 2 поля

Итого, на для ссылок на 8 сущностей надо 18 полей.

Как поступать: заводить все поля раздельно или использовать нечто обобщающее (типа GUID)?
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32805702
olk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я сторонник суррогатных ключей :)
или GUID (что я не очень люблю) или
SITE_ID + UID (площадка + ид документа)
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32805748
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А какие неудобства, можно поинтересоваться?

> Как поступать: заводить все поля раздельно или использовать нечто обобщающее
> (типа GUID)?

Imho раздельные поля информативнее и функциональнее.
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32805827
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ого ! А почему так много полей ?
Достаточно по одной ссылке, ИМХО.
А вот для подробностей типа: какой отдел заказал, какой регион отгрузки
следует использовать деревья. Справочники сотрудников - дерево, справочник пунктов отгрузки - дерево (страна-регион-область-город-район-улица-дом). Только в этом случае можно получить любой срез данных. Детальность дерева всегда можно наращивать или даже сокращать. Вся отчетность будет сделана однообразно.
Никакие гуиды Вас всё равно не спасут, т.к. они не упрощают отчётность.
Может у Вас вопрос сквозной нумерации в расп.системе ? Проще назначить непересекающиеся интервалы номеров документов. Обычного INT должно хватить надолго :)
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32805850
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Olk,
так это не связано с естественными/сурогатными ключами.
Вопрос в том, как организовывать сурогатный ключ: одним полем UUID или составныt (SITE_ID+TYPE_ID+UID)
---
Неудобство - например, для ссылки на единицу в штатном расписании вынуждены иметь три поля, вместо одного.
Что потом приводит, как минимум, к "нечитаемости" запросов.
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32805886
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LSV
Может у Вас вопрос сквозной нумерации в расп.системе ? Проще назначить непересекающиеся интервалы номеров документов. Обычного INT должно хватить надолго :)

Так в этом и вопрос :)
Сейчас сквозная нумерация достигается использованием составного PK: т.е. где_завели + код_организации + код_сотрудника.
В итоге, если надо сослаться всего на 2х людей надо шесть полей в таблице.
Вот меня и колбасит от мысли, что можно вместо шести обойтись двумя :)
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32806047
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Неудобство - например, для ссылки на единицу в штатном расписании вынуждены
> иметь три поля, вместо одного.

Ну и?

> Что потом приводит, как минимум, к "нечитаемости" запросов.

Imho все ровно наоборот: абсолютно логично и удобно. Плюс бесплатные бонусы в виде, например, безгеморройного разделения доступа в репозитории (если он есть или будет).
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32806108
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> где_завели + код_организации + код_сотрудника.
Что-то слишком усложнено ! Почему не код_организации+нумератор_организации. ?
Зачем нужен код сотрудника ?
деление по интервалам номеров - проще некуда ! Но до 4 млрд.документов для простого INT. BigINT использовать иногда неудобно на клиенте.
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32806317
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
авторПочему не код_организации+нумератор_организации
Потому что с каждой заявкой работает определенный манагер.
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32806340
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А деление по интервалам даже мной не рассматривается в качестве варианта.
Не говоря уж о высшей инстанции
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32806591
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
av1975А деление по интервалам даже мной не рассматривается в качестве варианта.

А зря. Послушай людей - дельную мысль говорят.
По сути какая тебе разница, как оформлен составной ключ? Допустим два значения: M и N.
Можно хранить 2 поля, что неудобно из-за громоздкости.
А можно слить в одно, например так:
M*1000000+N (при условии что это все уложится при возможных N,M)
Это будет в одном целочисленном поле и никакие маразмы в виде GUID'ов
не нужны. Кроме того из такого значения исходные M и N получаются
элементарной арифметической операцией. И еще этот ключ получается
"человекочитаемым": вижу запись с кодом 2000345 и сразу опознаю,
где она сделана.


Кстати, в Sybase ASA есть даже встроенный тип под это - global autoincrement

av1975Не говоря уж о высшей инстанции

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

--
http://talk.ru/forum/talk.ru.accounting.development
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32807111
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Высшая инстанция только если накладывает вето на мои предложения.
Что касается M и N, то их у нас ужо за третий десяток перевалило (и процесс продолжается), а записей м.б. много.
Когда-то мы такой вариант прорабатывали, но все пришли к выводу, что "Где"char(5) + "Номер"integer в нашем случае более правилен.
UUIDов тогда еще не было.
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32807116
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
М-ов за 3 десяток...
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32807163
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для распределённой базы действительно нужен составной ключ. Для бесконфликтного слияния. Но не нужно его усложнять. У документа всё равно есть реквизиты/атрибуты/авторы. Авторов кстати может быть несколько: составил/утвердил/передал/принял и пр. Если хотите можно в дополнение к числовому составному ключу сделать доп.текстовое поле с номером документа, например: ПН/ГД-000000/2А. Но все привязки внутри системы делать по сост.ключу. Текстовый номер может быть и неуникальный внутри общей сводной базы.
Если и это не подходит ... :( Ну тогда используйте 18,19,20 атрибутов
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32807890
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
av1975Высшая инстанция только если накладывает вето на мои предложения.
Что касается M и N, то их у нас ужо за третий десяток перевалило (и процесс продолжается), а записей м.б. много.


Много - это сколько? 4 миллиарда значений не хватит?
Допустим 1000 (Тысяча) распределенных баз (этого вам не хватит?).
Каждой диапазон 1000000(миллион) значений
(а много у вас таблиц-миллионников?)

Итого 1 млрд - прекрасно входит в integer и остается удобным
в использовании.

--
http://talk.ru/forum/talk.ru.accounting.development
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32809237
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для крупных корпораций 4млрд. - вполне достижимый предел. Я знаю случай достижения 1млн.док-тов всего за 1,5года для одной торговой точки. Так что лимит не должен быть меньше 10млн. док-тов. Всё равно INT вполне подходит для таких нужд. Надо просто иметь возможность переключится на незадействованный интервал.
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32809398
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVДля крупных корпораций 4млрд. - вполне достижимый предел. Я знаю случай достижения 1млн.док-тов всего за 1,5года для одной торговой точки.

Ну даже если это крупная корпорация, то BIGINT (2 в степени 64 значений)
всяко должно хватить.

LSV
Так что лимит не должен быть меньше 10млн. док-тов. Всё равно INT вполне подходит для таких нужд.


И я про то же

LSV
Надо просто иметь возможность переключится на незадействованный интервал.

Элементарно. В ASA даже есть системное событие для этого - по приближению интервала
к концу можно что-нибудь сделать. Например отправить e-mail сисадмину
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32811886
av1975
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я не буду спорить, такой подход возможен.
Но.
Лично я предпочитаю разделению по интервалу пользоваться составными ключами.
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32812339
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
av1975Я не буду спорить, такой подход возможен.
Но.
Лично я предпочитаю разделению по интервалу пользоваться составными ключами.
Ваше право. В итоге:
av1975
Итого, на для ссылок на 8 сущностей надо 18 полей.

А зачем было задавать вопрос?:
av1975
Как поступать: заводить все поля раздельно или использовать нечто обобщающее (типа GUID)?
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32812539
SinnerXP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: plaintext
где_завели + код_организации + код_сотрудника.
а по моему первые два поля зависят от третьего и их надо выносить в справочник сотрудников?
или я в чем-то не прав
...
Рейтинг: 0 / 0
Составные поля, альтернатива
    #32813302
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>Вопрос в том, как организовывать сурогатный ключ: одним полем UUID или составным (SITE_ID+TYPE_ID+UID)

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

PRIMARY_KEY_INFO(UID uinqiueidenitifier PRIMARY KEY, SITE_ID uniqueidentifier REFERENCES .... , TYPE_ID uniqueidenitifier REFERENCES ...... ,

А во всех остальных таблицах для первичного ключа использовать ссылки на UID из таблицы описаний первичных лючей.

А в дальнейшем таблицу информации о первичных ключах можно будет изменить, добавив, например дату модификации, код исполнителя, имя хоста, и вообще, всё, что дуже угодно....
EXECUTOR_ID uniqueidenitifier REFERENCES .....,
DATE_OF_CREATION datetime, ...)
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Составные поля, альтернатива
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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