Почему 1С 80 использует GUID а не LONG INT для ссылок. #226776

Ведь LONG INT работал бы гораздо быстрее в запросах и т.п. Если тут начнут темы про репликацию, вот рецепт: 1С могла бы для ссылок внутри базы использовать LONG INT, в то же время для каждого объекта хранить GUID, который бы использовался бы при выгрузках и при репликациях. Так что вот сижу и думаю - почему GUID?

Ведь LONG INT работал бы гораздо быстрее в запросах и т.п. Если тут начнут темы про репликацию, вот рецепт: 1С могла бы для ссылок внутри базы использовать LONG INT, в то же время для каждого объекта хранить GUID, который бы использовался бы при выгрузках и при репликациях. Так что вот сижу и думаю - почему GUID?

Ведь LONG INT работал бы гораздо быстрее в запросах и т.п. Если тут начнут темы про репликацию, вот рецепт: 1С могла бы для ссылок внутри базы использовать LONG INT, в то же время для каждого объекта хранить GUID, который бы использовался бы при выгрузках и при репликациях. Так что вот сижу и думаю - почему GUID?

ну держать и гуид и лонг инт - значит базы будут пухнуть ещё сильнее. И так уже неприлично...

Ты имеешь ввиду, что обработка чисел (Long INT) идет гораздо быстрее обработки символов (GUID).

Вообще я у себя на ответственных регистрах с особо крупными измерениями делаю как раз тип - число. Ну не удобно конечно в запросах, зато совесть по поводу скорости - чиста.

я имею ввиду, что база данных быстрее работает с LONG INT, чем с GUID...

Базы пухнуть не будут, индексы будут занимать меньше места, секете? А в индексах многократно дублируются ключевые поля.

Может быть в этом секрет "тормозов" 8-ки?

да, в этом. И ещё в тормозном интерпретаторе ты прав только цена решения слишком высока.... Тотальное введение собственных идентификаторов превратит удобнейшую платформу в обычный аксесс

+1 и ещё в промежуточных итогах. Это ж фактически процессинг куба при каждом движении... Чистые OLTP системы конечно быстрее... в записи, но не в выборке

ну, можно было бы привести пример "пухнущих баз" на сравнении 16 битной гуид с 8 битной бигинт (лонгинт нету у мсскл)... ps.. как хранится в файловой версии - одному б.н известно..

Ты про что, какое введение собственных идентификаторов???

Это просто. Для создания нового идентификатора типа long int надо обратится к базе, залочить таблицу, считать последний текущий, обновить последний текущий, разлочить таблицу. При использовании guid'а новый идшник легко создает клиент без всяких обращений к БД. А для современного железа 8 или 16 байт длина ключа - не велика разница.

Франс. тебе уже говорили, что база будет меньше весить, т.к. индексы будут весить меньше, чем ГУИДЫ каждой ссылки, дополнительно хранимые в ней для репликации..

т.е. что, получается guid уменьшает блокировки базы ?? т.е. это благо, что ли ?

Все что уменьшает блокировки базы, благо :) К тому же Гений лукавит, говоря, что индексы станут меньше, если использовать для репликации guid дополнительным полем, тк по нему все-равно придется строить индекс.

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

Можно узнать, как проводилась практика?

к сожалению точных замеров не проводил, но дело было так. 300000 позиций номенклатуры, 300 документов по 15 строк в день. Списание по средней. В лоб на типовой проводит секунд 10 Делал свой регистр, измерения Товар, Склад  (ссылочные) было уже гораздо быстрее. К сожалению не замерил, сколько потом ссылочное измерение Товар заменил на ID_товар тип Число, 10 ну и вместо справочника товаров стал использовать регистр сведений. Потом правда снова вернулся к справочнику, но связь делал по своему полю ID_товар. Визуально стало быстрее. На сколько - затрудняюсь сказать, сейчас док около секунды проводится

гм... неужели СУБД МС СКЛ не умеет без блокировок раздавать уникальные ключи?

Кстати, а что ГУИД реально всего 8 байт? Я думал больше.

Ну в общем то сами понимаете добавление Поля ГУИД не изменит существенно объем базы. Обычно объем занимают реквизиты, строки, регистры сведений и т.п. Их гораздо больше (на порядки) чем объектов.

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

France в говорит что гуид=16 бит

GUID 128 бит 16 байт.

где то читал что запросы на выборку с условием по GUID по определению работают быстрее чем с целыми так как происходит по байтовое сравнение. Не говоря уже о запросах на вставку так как нагрузка не собирается в конце кластерного индекса. Возможно выйгрышь в 18 достигнут из за низкой производительности дисковой подситемы. А если её поднять то на целых возможно запрос ляжет на процессоре и эфекта не будет. ИМХО.

to 22 and to 15 блокировки базы при заведении новых товаров, контрагентов и прочей справочной информации (записью новых документов) ничто по сравнению с временем формирования отчетов и проведением документов. тоже ИМХО.

теоретик доморощенный

точняк ну не знаю как может получиться быстрее. Индекс занимает больше места, больше страниц надо пролистать при поиске...

+ 27 фонтан сырых идей.

Это SQL Server. А есть ещё файловый вариант, будет PostgreSQL... В 1С в очередной раз пожертвовали эффективностью в пользу унификации.

суть в том что ключи выдаются без блокировок!

бред

Поясню наоборот LONG INT есть во всех базах, а с GUID не все справляются. О какой унификации идет речь. Удобство только для репликации, но репликация делается другим способом, о нем я уже писал в ... И где здесь выгода? 1с очередной раз лажанулась.

Кстати, раз уж вы так зациклились на увеличении объема базы, то каждый объект и так может получить уникальный ГУИД, который образуется из ГУИД базы+ код таблицы + код ключа внутри нее.

Завидуй!

Возможно соображения 1С такие, что ГУИД более стандартный механизм обеспечения уникальности объектов, даже если и LONG INT дает некий выигрыш, то им можно пренебречь в пользу унификации.

А почему Лотус тоже использует ГУИды ? Уж наверно они не дурнее 1С ?

опередел)) А почему винда использует ГУИДы, а не лонгит. Вопрос риторический :)

Винда и Лотус - я фигею... А почему ты молчишь про Акцапту и Навижн. Ты бы еще Ворд приплел, гыгыгы. Сравнил записную книжку и СУБД, где данных на порядки больше.

1С расшаркалась и пропустила вперед Акцапту в очередной раз...

А в акцапте нет ГУИДов?

в акцапте для ключей не гуиды используются... ;-)

Хотя фиг их знает, по-моему они для связки используют "естественные ключи", а это та еще задница. ;-) Даже длиннее GUID, так что может я еще и погорячилси.

Производительность GUID Шон МакКоун (Sean McCown) Все чаще и чаще я сталкиваюсь с тем, что разработчики по каким­то причинам хотят использовать идентификаторы GUID в качестве первичных ключей, и, что еще хуже, в кластеризованных индексах. Никак не возьму в толк, зачем надо применять GUID. Во­первых, они огромного размера — раза в четыре больше, чем целое, используемое в качестве первичного ключа. Приведем основные причины, по которым НЕ следует пользоваться GUID. · Они слишком большие, чтобы стать эффективным индексом. Чем меньше индекс, тем лучше, — это позволяет быстро найти значение ключа. Ни при каких условиях 16­байтный индекс не сравнится с 4­байтным. · Их слишком трудно запоминать администраторам баз данных, и потому сложно вникать в вопросы с данными. · Они не гарантируют уникальность. Вероятность того, что значение GUID будет уникальным, весьма велика, но это не 100%. · Они слишком быстро приводят к фрагментации таблицы. Поскольку они совершенно случайны, нельзя знать заранее, где произойдет следующая вставка, поэтому кластеризация по этому ключу НЕПРЕМЕННО вызовет фрагментацию. Поэтому не позволяйте своим разработчикам использовать GUID, особенно в системах, которые вам самим придется сопровождать. Проблема состоит в том, что ничего нельзя менять без твердых цифр и никто не проводил тестирования такого рода вещей. А вот я протестировал! Разница в производительности потрясает. Конечно, найдутся разработчики, которые все же будут настаивать на применении этих идентификаторов, но пусть стараются. Однако одно несомненно — ничего нельзя менять без обоснования в виде реальных цифр. Но теперь вы можете пойти к ним и показать, почему в базах данных лучше обойтись без GUID. Заключение У идентификаторов GUID есть своя ниша, но она, разумеется, не расположена рядом с кластеризованными индексами. Если вам все же приходится хранить GUID, создайте для него столбец где­нибудь в конце таблицы, а кластеризованный индекс стройте по ID, а не по нему. Тогда вы сможете обращаться с запросом к нужному GUID, а затем взять соответствующий ему ID и выполнять все, кроме первоначального поиска, по этому маленькому полю ID. По­моему, очень забавно, что разработчики получают требование уникальности, — их мозг попадает в заложники к GUID. Им в голову не приходит ничего иного. Один раз меня даже назвал идиотом один программист, который считал, что логические требования — это самый важный аспект приложения и что учитывать в приложении соображения производительности — кратчайший путь к провалу. Попробуйте­ка воспользоваться этой логикой и запустите 500 или 1000 одновременно работающих пользователей. А когда ваше приложение встанет, позвоните своему заказчику и скажите ему, что производительность приложения не такая уж важная штука.

чему завидовать? что ты занимаешь плагиатом? данный вопрос уже подымался летом на конференции разработчиков.

извини, мне не доложили, на мисте он не подымался, просвещаю...

вот видишь, вопрос подымался, а местныя во всю защищают ГУИДЫ, даже Орефков замечен был, гыгыгы

так что не завидуй!

Все же они GUID запихали в кластерный индекс?

инт в качестве идентификаторов - не очень хорошая идея. разный он на разных платформах. а разве лонг инт на x32 не те же 64 бита?

4 байта они и в африке 4 байта, что за гон? Гуид не 64 бита, а 16 байт.

да ! хотя если подумать - что они могли ещё использовать, например для справочников.. Код - не уникален...  Они юзают код+гуид, ну так он ещё длиннее чем просто гуид

в общем вывод такой: если в 8.1 вдруг откажутся от гуидов - мы порвём всякие аксапты с сапами - как тузик грелку !

Херрес вы с бодуна? А что они в 77 использовали? Внутренний идентификатор! Короткая сжатая строка, в которой был зашит Лонг Инт...

да, в аксапте индексы могут быть длинее - там естественный ключ по-моему используется для связки, т.е. именно поле КОД в понимании 1с-негов.

ну и по этой причине семёрочные базы поменьше и шевелятся побыстрее... С чем не согласен-то ?

Вот эта фраза непрофессиональна: "что они могли ещё использовать, например для справочников.. Код - не уникален.."

to 53 Это мы еще посмотрим кто кого порвет - сказала грелка, надутая до 10 атмосфер, Тузику.

слушай, ну хорош наезжать, да ? В 8ке код у справочников - не уникален. Записать его можно запроста с включенным флагом ЭтоЗагрузка. С чем ещё не согласен ???

Херес, у каждого элемента справочника есть уникальный код в пределах справочника этого вида. 1С использует ГУИД, хотя могла бы юзать Лонг Инт, уникальный идентификатор есть независимо от уникальности/не уникальности кода... Так что к чему тут твои фразы про уникальность кода, не догоняю... 1С могла бы юзать естественный ключ, как АХАПТА, но тогда бы пришлось делать одно поле или комбинацию полей уникальной, проще ввести уникальный системный ключ каждого элемента, что 1С и сделала.

ну смотри, мы же вроде говорили про кластерные индексы ? А они должны быть уникальными.... А код справочника, так же как и номер документа - по определению не уникален (на уровне БД), т.к. через план обмена всегда может приехать тот же код. Поэтому кластерный индекс по коду делать нельзя. Да и если посмотреть в ентерпрайз менеджере, вместо индекса по коду 1С использует составной =код+гуид Ты же сам говорил что гуидам есть альтернатива - лонгинт+код объекта+код базы

:)

блин, длина инт зависит от процессора! нельзя его использовать в качестве идентификаторов.

Просмотрел еще раз ветку, не увидел ответа на вопрос: Почему LONG INT  в запросах быстрее GUID? Также не убедительны решения в вопроса присвоения нового идентификатора LONG INT без выборки данных из таблицы.

Читать лень. ПАТАМУШТА ЕСТЬ УРБД дапустим...

зависит не от процессора а от СУБД в данном контексте ну потому что индексы получатся очень длинными. индексы хранятся так же как и данные, на страницах данных. Серверу надо пролистать в 4 раза больше страниц при поиске. ну если бы почитал сначала, увидел бы 2 альтернативных решения для УРБД

SQL Server, MS Access и т.д. GUID патаму что он GUID и шансов получить одиноковый номер меньше...

а ни кто не пробовал вставить в такую табличку, например, миллион записей? Или расчет на то, что у всех стоят суперсервера под v8 и можно спокойно гуид запихать в кластерный индекс? Кластерные индексы не обязаны быть уникальными. А вот праймари кейз - да.

если цена ГУИДа - проигрывание войны ERP систем - то насрать на этот шанс !

А патаму что у меня тоже хомяки спорят в клетке, а мне накакать чо им там не нравится.

Г1С - инженер знаний?? Нда... И после этого сюда еще грамотные люди заходят??

Не, грамотные не заходят. Только ты и другие. Вот и меня подтянули....

А вообще ветка классная. Только я ее не читал, названия хватило :)

шансов получить одинаковый GUID нет - в ближайший миллион лет. Не нужно искать свободный, выбирать пустые. Не нужно вообще ничего проверять. Как примари кей - идеал. А насчет индексации и выборок - очень сомневаюсь что настолько значительна разница - в десятки раз как грит Хоррес (не ставлю под сомнение слова - просто возможно причина в другом все-тки)

тебе не читать, тебе думать лень. Если GUID хранится в ссылке, то УРБД работает нормально... Думал плохо. Длина INT не при чем, для идентификатора используется строго 4 байта, просто индекс получается более короткий и поиск более быстрый, в конечном итоге почитай статью, в ветке была ссылка, почему не рекомендуется юзать ГУИД для ключа. Сравни 4 байта и 16 байт...

Ты просто не просек....

нет-нет. Не десятки раз, я этого не утвержал. У меня основной прирост по другой причине произошёл. Ну визуально процентов на 20-30 может побыстрее стало. ну кстати это соотносится с мнением здесь

+ огласите номера постов...

очень похоже...текст версус инт понятно проигрывает... Значит 1С на мега промышленный масштаб с индексами по ГУИД-ссылкам не выйдет. А Лотус понятно - он и так весь нереаляционный ...

ок, резюмирую варианты альтернатив. В прозвучала идея держать два ключа - гуид для УРБД и инт для всей прочей логики. в было предложено использовать суррогатный, но не глобально уникальный, а уникальный в пределах данного набора распределённых баз ключ - код базы+код вида объекта+код объекта

читай , примари кей тоже можно получать без обращения к базе. Сервак просто хранит последний выданный ключ. и все!

Аксапта тоже текстовые коды юзает и ничего... Просто обидно, что 1с в очередной раз лажанулась... как обычно... А хомяки в клетке 1с гадят и галдят... как метко подметил товарищ!

да но его туда надо записывать...а при массовом создании это узкое место, т.е. выдача все-равно производится серваком, а не клиентом как для GUID. Тип Code несколько не Unicode ) Может они просто не завершили прогрессивную идею .. оставь им шанс )

к примеру вытаскивать из GUID время в миллисекундах и из него делать индексы для таблиц

это есть шанс сделать в PostgreSQL, т.к. там есть механизм для встраивания в СУБД кастомных пользовательских алгоритмов индексации

не надо его вытаскивать. При подключении к БД вытаскиваем максимальный ключ. При запросе нового номера выдаем ключ плюс 1 и в памяти (не в базе) сохраняем новое значение. Где блокировки?? будут дырки в ключах, если по выбранному ключу не запишут объект (откажутся от записи). Но механизм повторного использования дырок я уже описал, какие проблемы?

про одновременную работу пользователей забыл??? гыгыгы... Лучше уж перенумеровывать гуид по глобальной таблице кэшей

читай , примари кей тоже можно получать без обращения к базе. Сервак просто хранит последний выданный ключ. и все! -- когда же ты перестанешь тупить? возьми буквари и почитай. И вообще, иди лучше  на мобилу девок заманивай. "шансов получить одинаковый GUID нет - в ближайший миллион лет." Фигня. Во-первых, если на компе стоит нормальная сетевая карта - только до 3400 года :-). А во-вторых, если стоит карточка с кривым МАС - уникальность только в пределах данного компа. Вполне реально получение нарушение уникальности Pk

И в чем я туплю, объясни, вумник...

в памяти клиента? а другие? получат тот же ключ? одноверменно - не значит одномоментно! =)  время по любому не совпадет.

не допонял... при чем тут мак-адрес..

Дятлы! Когда я пишу SELECT PRIMARY KEY FROM Bashmaky, сервер подсовывает мне примари кей для справочника башмаки именно по этой схеме. Если СКЛ Сервер это не умеет, это может делать сервер 1С предприятия.... НУ и ДЯТЛЫ!

ГУИД формируется в зависимости от мак-адреса в том числе

"Сервак просто хранит последний выданный ключ. и все!" -  и тут у сервака выключается питание, виснет сервак или еще что-нить происходит, после перезапуска начинаем выдавать ключ с какого значения? При каждой выдаче нового ключа (например, gen_id в генераторе IB/Fb) осуществляется увеличение значения на диске с блокировкой таблицы. "При запросе нового номера выдаем ключ плюс 1 и в памяти (не в базе) сохраняем новое значение. Где блокировки??" переименуйся в Идиет1С

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

может он пытается сказать про идентити-поле, но как собака не может :)

Специально для дятлов повторяю - ПРИ ЗАПУСКЕ СЕРВАКА СЧИТЫВАЕТСЯ МАКСИМАЛЬНОЕ ЗНАЧЕНИЕ КЛЮЧА. То бишь если сервак перезагрузился, при старте мы знаем максимальное значение ключа. Я блин на блокировках собаку съел, а этот молодой и зеленый меня поучать собрался!