Длина кода справочника и производительность. Неужели так критично? #240722

Разрабатываю конфу. В силу предметной области встала необходимость сделать длину кода справочника 36 символов. Знаю, что больше 11 не рекомендуется. Сложных запросов к этому справочнику не будет, но вот НайтиПоКоду будет очень часто использоваться. Повел тестирование на 100 тыс. элементах (больше маловероятно, что будет в реальных условиях). Получение объекта справочника через Найти По коду проходит очень быстро за 0,009002. Меня устраивает. Так почему же пишут, что большая длина кода плохо? Где может таиться опасность?

а почему не завечти реквизит СоставнойКодИз36Символов. и искать по нему

А какая разница? Искать по коду или по реквизиту??? Только дополнительный лишний индекс будет, так как придется этот реквизит индексировать. Принципиальной разницы  не вижу. Плюс для кода есть автоматический контроль уникальности....

Ты объясни для чего такой год?

В коде хранится уникальный идентификатор. Понятно, почему именно 36 :) В этот справочник будет сливаться информация из разных других баз, при этом этих баз потенциально может быть очень много и невозможно проконтролировать какие коды будут вводить пользователи, да и вообще заранее неизвестно про них ничего, так что трюк с префиксом как для распределенной БД не пройдет.

Да это понятно, что уникальный идентификатор. Он может быть и из 5 символов уникальным. С какого перепугу такой длины код фигачить то? Ты его состав можешь описать?

Я его получаю через GUID = Новый УникальныйИдентификатор; А как иначе гарантировать с большой долей вероятности уникальность записей в распределенных базах про которые ничего не знаешь.

1. префиксы. 2. гуид не даёт гарантий уникальности.. бывает совпадают

О_о ГУИД - это Гарантированый Уникальный ИДентификатор. ГАРАНТИРОВАНЫЙ. И, по заверениям разработчиков, будет таковым до 3100 примерно года.

правда? потому что на текстовых полях индексы большие сильно. и ищется медленнее чем на бинарных. guid у нормальных людей имеет тип varbinary..

Цитатата из справки:

Ну получишь ты этот самый GUID. И что тебе с ним дальше делать? Ты хоть подумал об этом? Для чего он тебе, поясни публике.

а вот что разработчики говорят :Using uniqueidentifier Data The uniqueidentifier data type stores 16-byte binary values that operate as globally unique identifiers (GUIDs). A GUID is a unique binary number; no other computer in the world will generate a duplicate of that GUID value

И как сделать по нормальному в 8-ке GUID???

BOL - Using uniqueidentifier Data A GUID value for a uniqueidentifier column is usually obtained: In a Transact-SQL statement, batch, or script by calling the NEWID function. In application code by calling an application API function or method that returns a GUID.

Все же не думаю, что поиск будет быстрее.

А нужен это GUID, чтобы можно было делать ссылки по нему из разных мест, например в HTML странице, в произвольных XML и т.д., там где ссылочная целостность естественно не поддерживается.

Только для того, "чтобы можно было делать ссылки по нему из разных мест"? Для чего?

может проще завести регистр сведений, по типу штрихдода в котором будет храниться нужная вам информация

Для того, чтобы делать ссылки.... Для чего делают ссылки? Чтобы получить объект из базы по его коду.... Но эти объекты создаются в разных местах, а не в одной базе или заранее известном наборе баз.

быстрее чем вгде?

Налицо спор по двум позициям 1. Уникальность GUID 2. Скорость поиска по индексам По первому: шанс повторения GUID на разных компьютерах очень мал. На столько мал, что можно сказать "Совпадение GUID невозможно". Мы имеем 4,9732323640978664215538224814682e+86 возможных значений. 2. Копайте в сторону реализации поиска по индексам на уровне dll-ок 1с-ки. Если не знаете как, то разговор беспредметный.

Чем использовать NEWID function, она так же генерирует размер года в 16 bit.

1)The uniqueidentifier data type stores 16-byte binary values that operate as globally unique identifiers (GUIDs). A GUID is a unique binary number; no other computer in the world will generate a duplicate of that GUID value. [пропущено] The Transact-SQL NEWID function and the application API functions and methods generate new uniqueidentifier values from the identification number of their network card plus a unique number from the CPU clock. Each network card has a unique identification number. 2) причем здесь индексы и dll'и клиента?

The uniqueidentifier data type stores 16-byte binary values

Совершенно верно, но при тестировании на 100 тыс. записей скорость устраивает. Но от чего еще зависит скорость? Тестовая база в файловом варинте была  3,5 GB и состояла из 100 тыс. записей в тестируемом справочнике и 35 тыс записей в  одном регистре сведений, он имеет связь с этим справочником. Тестировал поиск по справочнику и регистру. Скорость устраивает. Но будут ли проблемы при реальном использовании? Какие могут быть подводные камни? От чего еще зависит скорость?

Вот. Приходим к тому, от чего ушли - "Для чего делают ссылки? Чтобы получить объект из базы по его коду". А как ты будешь указывать из какой базы эту ссылку брать?

Данные будут сливаться в одну базу.

еще индексы по тестовым полям больше чем по бинарным. все.

Сорри думал речь идёт о v7. Но суть примерно та же.

в последний раз спрашиваю  что общего между индесками и dll?

бредовая ветка

Так кто-нибудь расставит все точки над И...???

поищи тут недавно была большая ветка на тему использования GUID в качестве индексов

есть другая идея. не хранить идентификатор объектов других баз в коде, а формировать элемент справочника как ссылку, имеющую тот же идентификатор, что и объект другой базы. Т.е. если есть строка идентификатора СтрокаGUID, то создавать элемент с помощью метода ПолучитьСсылку(Новый УникальныйИдентификатор(СтрокаGUID)). Этим же методом можно и искать элемент. Смысл в том, что внутренние ссылки у элементов в интергационной базе будут такими же как и ссылки элементов других баз.

Черт с этими гуидами. Это ерунда. Я не могу понять, где и как афтар сбирается искать эти объекты?

в базе большой куда он их из маленьких баз сольет, по GUID, как я понял

Отличная идея! Но все же как быстро искать нужный элемент? Не понятно.

Ну допустим простой пример. Внешнее приложение обращается к базе 1С и говорит: найди мне объект имеющий этот GUID и верни мне его свойства. Есть еще варианты....

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

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

Блин у меня уже есть прототип. Для чего мне это нужно вопрос не ставится, не буду же я все на форуме рассказывать что за конфа для какой компании и т.д. Меня интересует как сделать лучше, чем есть сейчас.

ИМХО ГУИД тебе не нужен,с префиксами будет все просто замечательно

Конструктивная идея, надо попробовать, сравнить. Первая разумная идея, спасибо AntonioS.

ок. Как хош. Тогда присоединяюсь к . И, вообще, правильнее было бы держать не справочник, а регистр сведений. В который заносить код объекта метаданных, код самого объекта и код базы, в которойискать этот объект. Например Документ.Выписка,"000131","База1" Справочник.Номенклатура,"00657","База4" ..... Документ.Счет,"43267","База1" и т.д.

В код запихать ГУИД - бред... (ничего личного)

не на чем. если бы у меня была такая конкретная задача, я бы наконец собрался посмотреть 1С:Интеграция. Наверное, там много полезных идей. А так все руки не доходят. :)

Я тоже думаю, что это бред сивой кобылы. Просто афтар ссылается на уже готовый функционал. Который, мне кажется, тоже такой же бредовый, как и идея с гуидом.

Повторюсь, мы не знаем эти базы заранее, сложно представить, но это так.   Вариант  AntonioS посмотрел работает отлично, мне нравится. В принципе скорость чуть-чуть быстрее, но решение зато красивое.

Никто в код запихивать GUID не собирается....

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

По ссылке быстрее: Замеры такие: По коду: 5000 элементов - время 0,008349         100000 элементов - время в пределах от 0,009002 до 0,02, для разных элементов справочника, видимо на скорость влияют разные факторы. По ссылке: 100000 эл. - время стабильно в районе 0,008, и при этом экономим на размере индекса, не храним коды в базе.