powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Смысловая нагрузка идентификатора строчки
25 сообщений из 88, страница 1 из 4
Смысловая нагрузка идентификатора строчки
    #40013877
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Было несколько задач, которые потребовали создания новых вспомогательных таблиц. Посмотрел как сделаны другие похожие, сделал однотипно: натуральное число для id строки, автоинкремент из сиквенс объекта, и т.д.

Все работает, дизайн совпадает, все довольны.
А вот интересно, какие ещё бывают методы назначения id?

Оракл позволяет длинные числа, вполне можно было бы структуризовать id. Ну например: последние три-четыре цифры содержат тип строки (или номер таблицы). Вполне могло бы помочь при отладке, если id строк передаются векторами для обработки.

Спросил у знакомого, который с sql работает давно, со всеми кроме оракла. Он поделился, что у него везде GUID для идентификатора строки. Он так привык, и вероятность ошибочного повторного использования id,или дёрнуть строку не из той таблицы сведена к нулю.

Вариантов масса, вот ещё один: сквозная нумерация всех строк в схеме на основе одного сиквенса, и дробная часть говорит о типе объекта (.1 - строка из таблицы товаров, .13 - из таблицы выпечки, .136 - таблицы тортов)

Кто-то видел или пользовался подобными приемами, чтобы id строки нес смысловую нагрузку, полезную для кодера?
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40013879
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL,


для кодера [i]не может быть [/i] смысловой нагрузки.
Кодер, крутящий свою гайку со смыслом - либо саботажник, либо прямой вредитель.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40013884
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
booby,

Слово кодер считается оскорбительным? Не знал.

Хорошо, пусть будет архитект системы.

СтОит ли архитектору внедрять id со смыслом, чтоб потом отладчикам было легче баги ловить, а также уменьшить последствия некоторых типов ошибок кодеров?
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40013885
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На архитектора ты не тянешь
Да и на кодера так себе
Скорее, как на ребенка, которому дали новую большую игрушку
Но и не рассказали что для битья орехов существует более простой инструмент

Использование ID для предоставления дополнительной информации о конкретном объекте далеко не нова
Тут есть как плюсы, так и минусы. Из минусов сразу:
-- одна (или мало) последовательность на все, может возникнуть конкуренция, особенно это выстрелит при массовых закачках и RAC. Тут можно поспорить, установить большой кеш, при массовых загрузках генерировать ID на основании ROWNUM и начального значения последовательности, а ее сдвинуть сразу на верхнюю оценку количества вставляемых строк
-- как правило, ID становится фиксированной и не маленькой длины. Т.е. он сразу занимает, например, 10 байт, в то время как при обычной нумерации он шел бы до такого размера десяток лет

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

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

Но такие решения принимались именно под конкретное место системы в общем зоопарке систем для более прозрачной синхронизации друг с другом

Использование GUID ставит в этом случае больше проблем, чем решает. Во первых это накладней по производительности, да и по размеру (опять же фиксированный объем) и он не дает никакой выгоды в части дополнительной информации -- ни упорядоченности по дате ни еще по другому признаку.
Ну и как-то я сомневаюсь, что никогда не будет коллизий
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40013918
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQLОн поделился, что у него везде GUID для идентификатора строки. Он так привык, и
вероятность ошибочного повторного использования id,или дёрнуть строку не из той таблицы
сведена к нулю.

Не к нулю. С GUID надо всегда обрабатывать нарушения ключа при вставке и повторять
операцию с новым GUID. Есть у него и другие неприятные свойства в виде тормозов при работе
с индексами. Но в распределённых системах он работает надёжнее всех остальных методов.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40013950
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
НеофитSQL
Оракл позволяет длинные числа, вполне можно было бы структуризовать id. Ну например: последние три-четыре цифры содержат тип строки (или номер таблицы). Вполне могло бы помочь при отладке, если id строк передаются векторами для обработки.

Начните наконец изучать теорию.

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

НеофитSQL
Спросил у знакомого, который с sql работает давно, со всеми кроме оракла. Он поделился, что у него везде GUID для идентификатора строки. Он так привык, и вероятность ошибочного повторного использования id,или дёрнуть строку не из той таблицы сведена к нулю.

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

НеофитSQL
Вариантов масса, вот ещё один: сквозная нумерация всех строк в схеме на основе одного сиквенса

В общем случае приведет к большему количеству блокировок на получении значения сиквенса и быстрому росту длины ключа, для всей схемы делать бессмысленно и вредно, в частных случаях применяется для однотипных объектов.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40013960
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL,

3) любой sequence - ресурс. Работая с единственным вы создаете общесистемную точку конкуренции за ресурс.
Так изредка делают, но почти всегда не для формирования ключей, а для предотвращения потери обновлений,
например, в ситуации медленно меняющихся данных ( в целом, для ораклистов - обычно чуждая технология,
в большинстве своем, они отказываются даже начинать понимать, о чём идет речь).

2) sys_guid в oracle возвращает тип raw(16).
Конкретно с таким типом в качестве PK, могут быть проблемы вокруг административных задач,
сорта export-import при наличии секционирования по такому полю - google в помощь.
Иначе вам придется держать поле varchar(32).
Это значит, что в стандартном индексном блоке на 8К, вы не сможете содержать более 170 ключей.
Зато, наоборот, такой ключ сможет пристойно себя вести в среде с высокой конкуренцией.
И, без сомнения, это часто выгодно глядящийся вариант при необходимости организации репликации.

1) В разумных пределах, делайте что-угодно. Понимайте только, что внедрение в суррогатный ключ бизнес-элементов,
по Гамбургскому счёту, эквивалентно созданию собственной "механики последовательностей", с учётом того, что это - общесистемный ресурс.
В средненагруженных случаях это может приносить пользу на поиске, и даже, до каких-то пределов, снимать борьбу сеансов за индексные страницы.
В высоконагруженных - требует отваги и детального понимания производимых действий при создании общего для всех ресурса.
Его нельзя будет обойти. Система будет работать со скоростью не выше производительности такого ресурса.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014029
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прочитал ваши ответы. На роль архитектора в новой для меня области я не претендую, вопрос был "делают ли так", или это квадратура круга.

Вижу что иногда делают. Во всех ответах услышал предостережение против единого сиквенса в смысле производительности.
Об этом аспекте даже не думал, т.к. у меня в БД хорошо если раз в секунду новая строчка где-то появляется. А вот у других наверное сотни-тысячи в секунду. Что они с ними делают? Хранят? Это же десятки миллионов строчек в сутки.

Про размер PK/ID тоже раньше не задумывался. Лишний десяток байт на строку казался пустяком для такого матерого продукта, но если у индексов свои ограничения, и надо байты экономить, то тогда нужно все таблицы с единицы начинать что ли? Неожиданно.
Почитаю про лучшие практики, или как они там могут называться, "обычаи, традиции и церемонии".

Два человека выразили опасения про коллизии GUIDов. Вспомнилась как я однажды пошутил на первое апреля, разослав всему отделу официальное письмо по инициативе переработке GUIDов. Типа, кто сгенерил и не пользуется - верните в систему согласно инструкции. Три человека из сотни купились, один с PhD.

Кто-то наблюдал столкновение ГУИДов (исключая ошибки кода)? Какова вероятность столкновения ГУИДов для триллионных таблиц? Если она меньше чем вероятность случайного флипа одного бита памяти от гамма-всплеска в далекой галактике, я от таких вещей не защищаюсь.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014030
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я, честно говоря, надеялся что ответы будут скорее типа

"нет, ты что - эти 1,2,3,4 только в учебниках для читабельности. Еще со времен Оракла 8 народ начал использовать ID в формате ....., это удобно и эффективно"

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

У меня... нет слов. Я даже не предполагал что кто-то в интерфейсе эти числа показывает. Как можно такое делать? Это же внутреннее поле для идентификации. Это как номер кластера на диске делать читабельным, чтоб пользователи его помнили легко :)
Вон винда мне присвоила внутренний идентификатор {S-1-5-21-2857837166-2321590770-2796004104-1005}, глобально уникальный и неповторимый. И спрятала так, чтоб в UI такие страсти не показались там, где neophyte@domain вполне достаточно.

Я спрашивал про размещение структурной инфы в ID, но это для тех, кто код пишет. Они не только глазами смотрят, а могут assert() кинуть в местах, чтобы шальные ID не забрели туда, где их не ждут.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014032
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQLКто-то наблюдал столкновение ГУИДов (исключая ошибки кода)?

Где-то на этом форуме упоминались два программных продукта, неспособные установиться на
одну винду потому что гуиды их СОМ-серверов совпали.

Вероятность получить коллизию на триллионных таблицах зависит от способа генерации. Для
полностью случайных гуидов (так они обычно генерятся на линухе) ты получишь минимум 3-4
коллизии на миллиард.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014033
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
НеофитSQL
У меня... нет слов. Я даже не предполагал что кто-то в интерфейсе эти числа показывает. Как можно такое делать? Это же внутреннее поле для идентификации. Это как номер кластера на диске делать читабельным, чтоб пользователи его помнили легко :)

Мда, ты вообще не понимаешь о чем речь...

Не в интерфейсе, а например в бэкенде, каким образом у сущности появится идентификатор из базы, не задумывался?

Сотрудники техподдержки это не конечные пользователи.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014096
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov

[
Вероятность получить коллизию на триллионных таблицах зависит от способа генерации. Для
полностью случайных гуидов (так они обычно генерятся на линухе) ты получишь минимум 3-4
коллизии на миллиард.


> минимум 3-4 коллизии на миллиард.

[youtube=
YouTube Video
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014116
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
со всеми кроме оракла.

Прям вот со всеми, "который с sql"? DB2, Informix, Teradata, PostgreSQL, MySQL, SQLite, MS SQL, Firebird, Vertica, SAP Hana, Impala, Hive, Greenplum, Clickhouse ... И это только часть списка.
И во всех знакомый использует guid? Не верю, пруфы в студию "со всеми".
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014464
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
env
НеофитSQL
со всеми кроме оракла.

Прям вот со всеми, "который с sql"? DB2, Informix, Teradata, PostgreSQL, MySQL, SQLite, MS SQL, Firebird, Vertica, SAP Hana, Impala, Hive, Greenplum, Clickhouse ... И это только часть списка.
И во всех знакомый использует guid? Не верю, пруфы в студию "со всеми".


Слышал в разговоре подчёркнутые, а также МариаДБ и какое-то чудо nosql.

"Пруфы в студию", сейчас )
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014582
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ключей со смысловой нагрузкой - полно. Это коды стран. Валюты. Языки. Биржевые тикеры.
URL/URN тоже вобщем ключи с смыслом. ISBN книг. Доменная структура крупной сети.

Главное чтоб бизнес был ОК с таким подходом. И чтоб была внятная процедура разрешения
коллизий. Например страна перестала существовать. Или переименовалась.

Я-бы поверх таких маленьких справочников вводил битемпоральность (PERIOD FOR). Чтоб можно было
спросить справочник - какой код валюты был у такой-то страны в 2005 году к примеру.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014588
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton
Ключей со смысловой нагрузкой - полно. Это коды стран. Валюты. Языки. Биржевые тикеры.
URL/URN тоже вобщем ключи с смыслом. ISBN книг. Доменная структура крупной сети.


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

Мой вопрос был про данные, где кандидатов на PK нет, и нужно ввести свою колонку. Я понял, что в таких случаях большинство используют number тип, и нумеруют 1,2,3, чтобы сэкономить три килобайта памяти на первой тысяче строк.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014591
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
mayton
Ключей со смысловой нагрузкой - полно. Это коды стран. Валюты. Языки. Биржевые тикеры.
URL/URN тоже вобщем ключи с смыслом. ISBN книг. Доменная структура крупной сети.


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

Мой вопрос был про данные, где кандидатов на PK нет, и нужно ввести свою колонку. Я понял, что в таких случаях большинство используют number тип, и нумеруют 1,2,3, чтобы сэкономить три килобайта памяти на первой тысяче строк.

Смотри. Если у тебя таблицы во 2 нормальной форме и выше - то у тебя есть потенциальный ключ.

Высасывать из пальца это понятие для 1НФ (внешних данных или для сырых данных) - не стоит. Это потеря
времени. Мне кажется ты уже поднимал этот вопрос в других форумах и это ничем не закончилось.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014592
Фотография SY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton

Я-бы поверх таких маленьких справочников вводил битемпоральность (PERIOD FOR)


Tемпоральность. Битемпоральность это два измерения темпоральности (e.g. valid dates and effective dates).

SY.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014596
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SY
mayton

Я-бы поверх таких маленьких справочников вводил битемпоральность (PERIOD FOR)


Tемпоральность. Битемпоральность это два измерения темпоральности (e.g. valid dates and effective dates).

SY.

Не согласен. Думаю что у этого термина есть широкие (пока) определения. Я думаю
что в статьях можно найти оба варианта как би-темпоральность.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014611
Фотография SY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

Bitemporal validity tracks entity along two time axes simultaneously. Temporal validity tracks entity along single time axis.

И вообще "bi" это два: бином ньютона, биметаллическая пластина, биссектриса, бисексуал...

SY.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014642
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
...
Если у тебя таблицы во 2 нормальной форме и выше - то у тебя есть потенциальный ключ.

Высасывать из пальца это понятие для 1НФ (внешних данных или для сырых данных) - не стоит....

mayton, попробуй прочитать внимательно.

Помнишь три закона Ньютона в классической механике?
Первый из них может рассматриваться (и, формально говоря, должен ),
как определение контекста, котором работают оставшиеся два.
Тогда формулировки всех трех законов окажутся такими:
1) существуют такие системы отсчёта, называемые инерциальными, в которых выполняются второй и третий законы.
2) траектория движения материальной точки в поле сил определяется дифференциальным уравнением второго порядка,
вида a = F/m, где a - вторая производная траектории движения, F - поле сил, а m - собственная характеристика материальной точки, называемая массой.
3) при взаимодействии материальных точек 1 и 2 возникают парные силы взаимно обратного направления:
F(1->2) = -F(2->1)

Чтобы выполнился третий закон, первый (и больше никто, потому что больше некому)
должен предоставить такую систему отсчёта, в которой пространство однородно, изотропно и зеркально симметрично.
А чтобы выполнился второй закон, первый (и больше никто, потому что больше некому) должен предоставить такое пространство, в котором отсутствует поле сил в отсутствии тел.
Этого, классического, мира просто не существует, если "не надо высасывать понятия первого закона из пальца".

Аналогично , 1НФ, по сути, определяет то, что такое отношение. Ничего не надо "высасывать из пальца".
Смысл формулировки такой - мы имеем дело и называем отношением только то, что имеет хотя бы один потенциальный ключ.
Это очевидно значит, что ширина ключа не может превышать количество атрибутов в отношений.
В противном случае то, что предъявляется, отношением не является .

Все рассуждения о последующих нормальных формах производятся только в контексте, определяемом 1НФ.
И именно она, по сути вводит определение ключа.
Реляционная теория, это такая теория, полный контекст которой задаётся 1НФ.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014664
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton
НеофитSQL
пропущено...


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

Мой вопрос был про данные, где кандидатов на PK нет, и нужно ввести свою колонку. Я понял, что в таких случаях большинство используют number тип, и нумеруют 1,2,3, чтобы сэкономить три килобайта памяти на первой тысяче строк.

Смотри. Если у тебя таблицы во 2 нормальной форме и выше - то у тебя есть потенциальный ключ.


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

mayton

Высасывать из пальца это понятие для 1НФ (внешних данных или для сырых данных) - не стоит. Это потеря
времени. Мне кажется ты уже поднимал этот вопрос в других форумах и это ничем не закончилось.


Это вполне нормальный ответ, его бы еще дополнить "вместо этого, используйте..."

П.С. Про другие форумы не знаю, это единственный который мне порекомендовал мой русскоязычный старший коллега.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014666
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
booby

2) траектория движения материальной точки в поле сил определяется дифференциальным уравнением второго порядка,
вида a = F/m, где a - вторая производная траектории движения, F - поле сил , а m - собственная характеристика материальной точки, называемая массой.


Неужели в колледжах сейчас так учат? Докатились...

Давайте не будем тут физику мучать, ньютона жалко.

F - вектор силы. У силового поля размерность иная.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014692
istrebitel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В ERP Галактика id типа char(16) в hex формате первые байты озночают номер филиала предприятия. Используется для синхронизации баз. Можно завести документ в 1 месте, выгрузить изменения и отправить хоть по почте в остальные филиалы.
...
Рейтинг: 0 / 0
Смысловая нагрузка идентификатора строчки
    #40014703
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
istrebitel,

Полезная инфа, спасибо.
...
Рейтинг: 0 / 0
25 сообщений из 88, страница 1 из 4
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Смысловая нагрузка идентификатора строчки
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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