|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
Было несколько задач, которые потребовали создания новых вспомогательных таблиц. Посмотрел как сделаны другие похожие, сделал однотипно: натуральное число для id строки, автоинкремент из сиквенс объекта, и т.д. Все работает, дизайн совпадает, все довольны. А вот интересно, какие ещё бывают методы назначения id? Оракл позволяет длинные числа, вполне можно было бы структуризовать id. Ну например: последние три-четыре цифры содержат тип строки (или номер таблицы). Вполне могло бы помочь при отладке, если id строк передаются векторами для обработки. Спросил у знакомого, который с sql работает давно, со всеми кроме оракла. Он поделился, что у него везде GUID для идентификатора строки. Он так привык, и вероятность ошибочного повторного использования id,или дёрнуть строку не из той таблицы сведена к нулю. Вариантов масса, вот ещё один: сквозная нумерация всех строк в схеме на основе одного сиквенса, и дробная часть говорит о типе объекта (.1 - строка из таблицы товаров, .13 - из таблицы выпечки, .136 - таблицы тортов) Кто-то видел или пользовался подобными приемами, чтобы id строки нес смысловую нагрузку, полезную для кодера? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 07:28 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQL, для кодера [i]не может быть [/i] смысловой нагрузки. Кодер, крутящий свою гайку со смыслом - либо саботажник, либо прямой вредитель. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 07:43 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
booby, Слово кодер считается оскорбительным? Не знал. Хорошо, пусть будет архитект системы. СтОит ли архитектору внедрять id со смыслом, чтоб потом отладчикам было легче баги ловить, а также уменьшить последствия некоторых типов ошибок кодеров? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 08:57 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
На архитектора ты не тянешь Да и на кодера так себе Скорее, как на ребенка, которому дали новую большую игрушку Но и не рассказали что для битья орехов существует более простой инструмент Использование ID для предоставления дополнительной информации о конкретном объекте далеко не нова Тут есть как плюсы, так и минусы. Из минусов сразу: -- одна (или мало) последовательность на все, может возникнуть конкуренция, особенно это выстрелит при массовых закачках и RAC. Тут можно поспорить, установить большой кеш, при массовых загрузках генерировать ID на основании ROWNUM и начального значения последовательности, а ее сдвинуть сразу на верхнюю оценку количества вставляемых строк -- как правило, ID становится фиксированной и не маленькой длины. Т.е. он сразу занимает, например, 10 байт, в то время как при обычной нумерации он шел бы до такого размера десяток лет У нас используется в одной системе подобный подход -- там включается дата и место (филиал) создания строки -- вещь не очень точная, но достаточная, например, для выбора критерия секционирования, если нет других Или для приблизительной аналитики "кто, где и когда" Есть ее небольшое расширение, когда включается ID столбца (по которому можно определить и табличку) -- это в случае привязанных подчиненных строк Но такие решения принимались именно под конкретное место системы в общем зоопарке систем для более прозрачной синхронизации друг с другом Использование GUID ставит в этом случае больше проблем, чем решает. Во первых это накладней по производительности, да и по размеру (опять же фиксированный объем) и он не дает никакой выгоды в части дополнительной информации -- ни упорядоченности по дате ни еще по другому признаку. Ну и как-то я сомневаюсь, что никогда не будет коллизий ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 09:27 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQLОн поделился, что у него везде GUID для идентификатора строки. Он так привык, и вероятность ошибочного повторного использования id,или дёрнуть строку не из той таблицы сведена к нулю. Не к нулю. С GUID надо всегда обрабатывать нарушения ключа при вставке и повторять операцию с новым GUID. Есть у него и другие неприятные свойства в виде тормозов при работе с индексами. Но в распределённых системах он работает надёжнее всех остальных методов. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 13:21 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQL Оракл позволяет длинные числа, вполне можно было бы структуризовать id. Ну например: последние три-четыре цифры содержат тип строки (или номер таблицы). Вполне могло бы помочь при отладке, если id строк передаются векторами для обработки. Начните наконец изучать теорию. Числовой идентификатор это суррогатный ключ, внести в него значения атрибутов можно, в случае когда это принесет хороший профит, вам об этом думать в ближайший год (учитывая ваши уникальные способности возможно два года) не стоит. НеофитSQL Спросил у знакомого, который с sql работает давно, со всеми кроме оракла. Он поделился, что у него везде GUID для идентификатора строки. Он так привык, и вероятность ошибочного повторного использования id,или дёрнуть строку не из той таблицы сведена к нулю. GUID имеет достаточно большой размер, он съедает больше ресурсов, и помимо уже перечисленных выше в теме недостатков он также неудобен для человека, например, у вас есть небольшие справочники, техподдержка помнит простые коды наизусть, гуиды придется копипастить. У гуидов есть одно достоинство, их можно получить в приложении или другой подсистеме не обращаясь к СУБД, но и серьезный недостаток в виде возможных коллизий, которые нужно обрабатывать. НеофитSQL Вариантов масса, вот ещё один: сквозная нумерация всех строк в схеме на основе одного сиквенса В общем случае приведет к большему количеству блокировок на получении значения сиквенса и быстрому росту длины ключа, для всей схемы делать бессмысленно и вредно, в частных случаях применяется для однотипных объектов. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 15:07 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQL, 3) любой sequence - ресурс. Работая с единственным вы создаете общесистемную точку конкуренции за ресурс. Так изредка делают, но почти всегда не для формирования ключей, а для предотвращения потери обновлений, например, в ситуации медленно меняющихся данных ( в целом, для ораклистов - обычно чуждая технология, в большинстве своем, они отказываются даже начинать понимать, о чём идет речь). 2) sys_guid в oracle возвращает тип raw(16). Конкретно с таким типом в качестве PK, могут быть проблемы вокруг административных задач, сорта export-import при наличии секционирования по такому полю - google в помощь. Иначе вам придется держать поле varchar(32). Это значит, что в стандартном индексном блоке на 8К, вы не сможете содержать более 170 ключей. Зато, наоборот, такой ключ сможет пристойно себя вести в среде с высокой конкуренцией. И, без сомнения, это часто выгодно глядящийся вариант при необходимости организации репликации. 1) В разумных пределах, делайте что-угодно. Понимайте только, что внедрение в суррогатный ключ бизнес-элементов, по Гамбургскому счёту, эквивалентно созданию собственной "механики последовательностей", с учётом того, что это - общесистемный ресурс. В средненагруженных случаях это может приносить пользу на поиске, и даже, до каких-то пределов, снимать борьбу сеансов за индексные страницы. В высоконагруженных - требует отваги и детального понимания производимых действий при создании общего для всех ресурса. Его нельзя будет обойти. Система будет работать со скоростью не выше производительности такого ресурса. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 15:38 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
Прочитал ваши ответы. На роль архитектора в новой для меня области я не претендую, вопрос был "делают ли так", или это квадратура круга. Вижу что иногда делают. Во всех ответах услышал предостережение против единого сиквенса в смысле производительности. Об этом аспекте даже не думал, т.к. у меня в БД хорошо если раз в секунду новая строчка где-то появляется. А вот у других наверное сотни-тысячи в секунду. Что они с ними делают? Хранят? Это же десятки миллионов строчек в сутки. Про размер PK/ID тоже раньше не задумывался. Лишний десяток байт на строку казался пустяком для такого матерого продукта, но если у индексов свои ограничения, и надо байты экономить, то тогда нужно все таблицы с единицы начинать что ли? Неожиданно. Почитаю про лучшие практики, или как они там могут называться, "обычаи, традиции и церемонии". Два человека выразили опасения про коллизии GUIDов. Вспомнилась как я однажды пошутил на первое апреля, разослав всему отделу официальное письмо по инициативе переработке GUIDов. Типа, кто сгенерил и не пользуется - верните в систему согласно инструкции. Три человека из сотни купились, один с PhD. Кто-то наблюдал столкновение ГУИДов (исключая ошибки кода)? Какова вероятность столкновения ГУИДов для триллионных таблиц? Если она меньше чем вероятность случайного флипа одного бита памяти от гамма-всплеска в далекой галактике, я от таких вещей не защищаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 19:55 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
Я, честно говоря, надеялся что ответы будут скорее типа "нет, ты что - эти 1,2,3,4 только в учебниках для читабельности. Еще со времен Оракла 8 народ начал использовать ID в формате ....., это удобно и эффективно" graycode > GUID имеет достаточно большой размер, он съедает больше ресурсов, и помимо уже перечисленных выше в теме недостатков он также неудобен для человека, например, у вас есть небольшие справочники, техподдержка помнит простые коды наизусть, гуиды придется копипастить. У гуидов есть одно достоинство, их можно получить в приложении или другой подсистеме не обращаясь к СУБД, но и серьезный недостаток в виде возможных коллизий, которые нужно обрабатывать. У меня... нет слов. Я даже не предполагал что кто-то в интерфейсе эти числа показывает. Как можно такое делать? Это же внутреннее поле для идентификации. Это как номер кластера на диске делать читабельным, чтоб пользователи его помнили легко :) Вон винда мне присвоила внутренний идентификатор {S-1-5-21-2857837166-2321590770-2796004104-1005}, глобально уникальный и неповторимый. И спрятала так, чтоб в UI такие страсти не показались там, где neophyte@domain вполне достаточно. Я спрашивал про размещение структурной инфы в ID, но это для тех, кто код пишет. Они не только глазами смотрят, а могут assert() кинуть в местах, чтобы шальные ID не забрели туда, где их не ждут. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 20:09 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQLКто-то наблюдал столкновение ГУИДов (исключая ошибки кода)? Где-то на этом форуме упоминались два программных продукта, неспособные установиться на одну винду потому что гуиды их СОМ-серверов совпали. Вероятность получить коллизию на триллионных таблицах зависит от способа генерации. Для полностью случайных гуидов (так они обычно генерятся на линухе) ты получишь минимум 3-4 коллизии на миллиард. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 20:29 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQL У меня... нет слов. Я даже не предполагал что кто-то в интерфейсе эти числа показывает. Как можно такое делать? Это же внутреннее поле для идентификации. Это как номер кластера на диске делать читабельным, чтоб пользователи его помнили легко :) Мда, ты вообще не понимаешь о чем речь... Не в интерфейсе, а например в бэкенде, каким образом у сущности появится идентификатор из базы, не задумывался? Сотрудники техподдержки это не конечные пользователи. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 20:31 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov [ Вероятность получить коллизию на триллионных таблицах зависит от способа генерации. Для полностью случайных гуидов (так они обычно генерятся на линухе) ты получишь минимум 3-4 коллизии на миллиард. > минимум 3-4 коллизии на миллиард. [youtube= ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 04:50 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQL со всеми кроме оракла. Прям вот со всеми, "который с sql"? DB2, Informix, Teradata, PostgreSQL, MySQL, SQLite, MS SQL, Firebird, Vertica, SAP Hana, Impala, Hive, Greenplum, Clickhouse ... И это только часть списка. И во всех знакомый использует guid? Не верю, пруфы в студию "со всеми". ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 09:30 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
env НеофитSQL со всеми кроме оракла. Прям вот со всеми, "который с sql"? DB2, Informix, Teradata, PostgreSQL, MySQL, SQLite, MS SQL, Firebird, Vertica, SAP Hana, Impala, Hive, Greenplum, Clickhouse ... И это только часть списка. И во всех знакомый использует guid? Не верю, пруфы в студию "со всеми". Слышал в разговоре подчёркнутые, а также МариаДБ и какое-то чудо nosql. "Пруфы в студию", сейчас ) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 17:23 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
Ключей со смысловой нагрузкой - полно. Это коды стран. Валюты. Языки. Биржевые тикеры. URL/URN тоже вобщем ключи с смыслом. ISBN книг. Доменная структура крупной сети. Главное чтоб бизнес был ОК с таким подходом. И чтоб была внятная процедура разрешения коллизий. Например страна перестала существовать. Или переименовалась. Я-бы поверх таких маленьких справочников вводил битемпоральность (PERIOD FOR). Чтоб можно было спросить справочник - какой код валюты был у такой-то страны в 2005 году к примеру. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 21:03 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
mayton Ключей со смысловой нагрузкой - полно. Это коды стран. Валюты. Языки. Биржевые тикеры. URL/URN тоже вобщем ключи с смыслом. ISBN книг. Доменная структура крупной сети. Я согласен с вашим утверждением, но этот случай (когда в данных присутствует уникальный параметр годный для ключа) не рассматривал - он как бы саморешающийся. Мой вопрос был про данные, где кандидатов на PK нет, и нужно ввести свою колонку. Я понял, что в таких случаях большинство используют number тип, и нумеруют 1,2,3, чтобы сэкономить три килобайта памяти на первой тысяче строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 21:22 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
НеофитSQL mayton Ключей со смысловой нагрузкой - полно. Это коды стран. Валюты. Языки. Биржевые тикеры. URL/URN тоже вобщем ключи с смыслом. ISBN книг. Доменная структура крупной сети. Я согласен с вашим утверждением, но этот случай (когда в данных присутствует уникальный параметр годный для ключа) не рассматривал - он как бы саморешающийся. Мой вопрос был про данные, где кандидатов на PK нет, и нужно ввести свою колонку. Я понял, что в таких случаях большинство используют number тип, и нумеруют 1,2,3, чтобы сэкономить три килобайта памяти на первой тысяче строк. Смотри. Если у тебя таблицы во 2 нормальной форме и выше - то у тебя есть потенциальный ключ. Высасывать из пальца это понятие для 1НФ (внешних данных или для сырых данных) - не стоит. Это потеря времени. Мне кажется ты уже поднимал этот вопрос в других форумах и это ничем не закончилось. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 21:31 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
mayton Я-бы поверх таких маленьких справочников вводил битемпоральность (PERIOD FOR) Tемпоральность. Битемпоральность это два измерения темпоральности (e.g. valid dates and effective dates). SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 21:31 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
SY mayton Я-бы поверх таких маленьких справочников вводил битемпоральность (PERIOD FOR) Tемпоральность. Битемпоральность это два измерения темпоральности (e.g. valid dates and effective dates). SY. Не согласен. Думаю что у этого термина есть широкие (пока) определения. Я думаю что в статьях можно найти оба варианта как би-темпоральность. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 21:39 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
mayton, Bitemporal validity tracks entity along two time axes simultaneously. Temporal validity tracks entity along single time axis. И вообще "bi" это два: бином ньютона, биметаллическая пластина, биссектриса, бисексуал... SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 22:15 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
mayton ... Если у тебя таблицы во 2 нормальной форме и выше - то у тебя есть потенциальный ключ. Высасывать из пальца это понятие для 1НФ (внешних данных или для сырых данных) - не стоит.... mayton, попробуй прочитать внимательно. Помнишь три закона Ньютона в классической механике? Первый из них может рассматриваться (и, формально говоря, должен ), как определение контекста, котором работают оставшиеся два. Тогда формулировки всех трех законов окажутся такими: 1) существуют такие системы отсчёта, называемые инерциальными, в которых выполняются второй и третий законы. 2) траектория движения материальной точки в поле сил определяется дифференциальным уравнением второго порядка, вида a = F/m, где a - вторая производная траектории движения, F - поле сил, а m - собственная характеристика материальной точки, называемая массой. 3) при взаимодействии материальных точек 1 и 2 возникают парные силы взаимно обратного направления: F(1->2) = -F(2->1) Чтобы выполнился третий закон, первый (и больше никто, потому что больше некому) должен предоставить такую систему отсчёта, в которой пространство однородно, изотропно и зеркально симметрично. А чтобы выполнился второй закон, первый (и больше никто, потому что больше некому) должен предоставить такое пространство, в котором отсутствует поле сил в отсутствии тел. Этого, классического, мира просто не существует, если "не надо высасывать понятия первого закона из пальца". Аналогично , 1НФ, по сути, определяет то, что такое отношение. Ничего не надо "высасывать из пальца". Смысл формулировки такой - мы имеем дело и называем отношением только то, что имеет хотя бы один потенциальный ключ. Это очевидно значит, что ширина ключа не может превышать количество атрибутов в отношений. В противном случае то, что предъявляется, отношением не является . Все рассуждения о последующих нормальных формах производятся только в контексте, определяемом 1НФ. И именно она, по сути вводит определение ключа. Реляционная теория, это такая теория, полный контекст которой задаётся 1НФ. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 23:28 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
mayton НеофитSQL пропущено... Я согласен с вашим утверждением, но этот случай (когда в данных присутствует уникальный параметр годный для ключа) не рассматривал - он как бы саморешающийся. Мой вопрос был про данные, где кандидатов на PK нет, и нужно ввести свою колонку. Я понял, что в таких случаях большинство используют number тип, и нумеруют 1,2,3, чтобы сэкономить три килобайта памяти на первой тысяче строк. Смотри. Если у тебя таблицы во 2 нормальной форме и выше - то у тебя есть потенциальный ключ. Если у меня уже есть ключ, я стал бы искать еще один ключ. Пример из недавнего опыта: внешние данные (поток событий) надо сохранить и присвоить PK, т.к. в данных уникального столбца нет. mayton Высасывать из пальца это понятие для 1НФ (внешних данных или для сырых данных) - не стоит. Это потеря времени. Мне кажется ты уже поднимал этот вопрос в других форумах и это ничем не закончилось. Это вполне нормальный ответ, его бы еще дополнить "вместо этого, используйте..." П.С. Про другие форумы не знаю, это единственный который мне порекомендовал мой русскоязычный старший коллега. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 00:51 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
booby 2) траектория движения материальной точки в поле сил определяется дифференциальным уравнением второго порядка, вида a = F/m, где a - вторая производная траектории движения, F - поле сил , а m - собственная характеристика материальной точки, называемая массой. Неужели в колледжах сейчас так учат? Докатились... Давайте не будем тут физику мучать, ньютона жалко. F - вектор силы. У силового поля размерность иная. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 00:58 |
|
Смысловая нагрузка идентификатора строчки
|
|||
---|---|---|---|
#18+
В ERP Галактика id типа char(16) в hex формате первые байты озночают номер филиала предприятия. Используется для синхронизации баз. Можно завести документ в 1 месте, выгрузить изменения и отправить хоть по почте в остальные филиалы. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 05:59 |
|
|
start [/forum/topic.php?fid=52&fpage=33&tid=1880746]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
others: | 337ms |
total: | 490ms |
0 / 0 |