УникальныйИдентификатор vs. Строка
Доброго времени суток! В регистре сведений имеется измерение типа УникальныйИдентификатор (не важно почему так, т.к. вопрос не в этом), но проблема в том, что выполнять частичный поиск по такому измерению крайне проблематично, к примеру я хочу найти все записи которые содержат последовательность каких-то 5 символов. Думаю изменить тип на строковый 32 символа. Вопрос: есть ли разница в объеме хранения и способе индексации измерения типа УникальныйИдентификатор и Строка 32. Я так понимаю что внутренне устройство типа Уникальный идентификатор в 1С - это обычная строка длинной 32 символа и занимает столько же места как и обычная строка 32 символа и индексация и размер индекса в регистре по данному измерению будет аналогичным, или я не прав и тип УникальныйИдентификатор какой то особый тип который хранится к примеру как число, или же индекс по нему строится как то особенно? Заранее спасибо.
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Отталкивайтесь от задачи и от планируемого объема данных в таблице. Если данных будет не много, то строка сойдет. В противном случае создавайте дополнительный строковый реквизит, включайте у него признак использования полнотекстового поиска, пишите в него значения, по которым будете искать, и используйте системную глобальную функцию ПолучитьДанныеВыбора().
Если сделать размер строки фиксированным то храниться в БД такой реквизит будет в формате NCHAR(n) а не NVARCHAR(n) и разницы в размерах не будет. Да и поиск будет происходить существенно быстрее по такой строке.
(9) Не совсем так, сейчас перечитал MSDN
nchar [ ( n ) ]
Строковые данные постоянной длины в Юникоде. n определяет длину строки и должно иметь значение от 1 до 4000. Размер хранилища — дважды n байт. Если кодовая страница параметров сортировки использует двухбайтовые символы, размер хранения остается равным n байт. В зависимости от строки для хранения n символов может понадобиться менее n байт. Синонимами типа nchar по стандарту ISO являются типы national char и national character.
nvarchar [ ( n | max ) ]
Строковые данные переменной длины в Юникоде. n определяет длину строки и может иметь значение от 1 до 4000. Значение max указывает, что максимальный размер при хранении составляет 2^30-1 символов. Максимальный размер при хранении в байтах равен 2 ГБ. Фактический размер хранилища в байтах вдвое больше числа введенных символов + 2 байта. Синонимами типа nvarchar по стандарту ISO являются типы national char varying и national character varying.
То есть, как я понимаю, объем хранимых данных у nchar всё же меньше чем у nvarchar но не в два раза.
nchar [ ( n ) ]
Строковые данные постоянной длины в Юникоде. n определяет длину строки и должно иметь значение от 1 до 4000. Размер хранилища — дважды n байт. Если кодовая страница параметров сортировки использует двухбайтовые символы, размер хранения остается равным n байт. В зависимости от строки для хранения n символов может понадобиться менее n байт. Синонимами типа nchar по стандарту ISO являются типы national char и national character.
nvarchar [ ( n | max ) ]
Строковые данные переменной длины в Юникоде. n определяет длину строки и может иметь значение от 1 до 4000. Значение max указывает, что максимальный размер при хранении составляет 2^30-1 символов. Максимальный размер при хранении в байтах равен 2 ГБ. Фактический размер хранилища в байтах вдвое больше числа введенных символов + 2 байта. Синонимами типа nvarchar по стандарту ISO являются типы national char varying и national character varying.
То есть, как я понимаю, объем хранимых данных у nchar всё же меньше чем у nvarchar но не в два раза.
(15) А если реквиз объявить длиной 32 вместо 36 - это как, "всего навсего";)
Я как-то раз тоже решил, что строковая длина УИДа = 32. В продуктиве через 2-3 дня начались странные вещи. Благо быстро нашли недочет.
А что касается (1), то на свежих версиях платформы можно смело УИДы использовать.
Раньше с этим были определенные проблемы. УИДы не имели отражения в управляемых формах. Нельзя было список УИДов в запрос закинуть.
Примерно с полгода назад наконец-то это в платформах доработали.
Я как-то раз тоже решил, что строковая длина УИДа = 32. В продуктиве через 2-3 дня начались странные вещи. Благо быстро нашли недочет.
А что касается (1), то на свежих версиях платформы можно смело УИДы использовать.
Раньше с этим были определенные проблемы. УИДы не имели отражения в управляемых формах. Нельзя было список УИДов в запрос закинуть.
Примерно с полгода назад наконец-то это в платформах доработали.
(17)
Вот именно что строковое представление, для удобства восприятия разделены на группы отделенные дефисами. Вот этих дефисов как раз 4. Итого 32+4=36.
ec9b1edd-9c20-4285-94b9-8c69c4a34f6e
А если реквиз объявить длиной 32 вместо 36 - это как, "всего навсего";)
Вот именно что строковое представление, для удобства восприятия разделены на группы отделенные дефисами. Вот этих дефисов как раз 4. Итого 32+4=36.
ec9b1edd-9c20-4285-94b9-8c69c4a34f6e
(18)
И все же УИ это 36 символов тип данных в SQL uniqueidentifier (Transact-SQL)
Вот именно что строковое представление, для удобства восприятия разделены на группы отделенные дефисами. Вот этих дефисов как раз 4. Итого 32+4=36.
ec9b1edd-9c20-4285-94b9-8c69c4a34f6e
ec9b1edd-9c20-4285-94b9-8c69c4a34f6e
И все же УИ это 36 символов тип данных в SQL uniqueidentifier (Transact-SQL)
Насколько мне известно, GUID - это массив (на низком уровне) чисел array [0..5] of WORD, индексируйте уникальный идентификатор и все, полнотекстовый поиск работает и по представлениям объектов (как агрегатным так и простым)
Вы не сможете создать через конфигуратор строку, которая будет хранится в char/varchar, только с nchar и nvarchar.
Тут указаны все типы, с которыми 1с работает.
Соответственно каждый символ будет занимать 2 байта/16 бит из-за кодировки UTF-16
Тут указаны все типы, с которыми 1с работает.
Строка фиксированной длины: длина n. NCHAR(n)
Соответственно каждый символ будет занимать 2 байта/16 бит из-за кодировки UTF-16
(36) Время генерации GUID таки содержит. Если он генерился. И 1С пакует его в binary(16) таким образом, чтобы время генерации было впереди. Чтобы в общем случае кластерный индекс по ссылке был таки в порядке создания, что зело облегчает работу СУБД по добавлению записей.
А ничего нигде не сломается, если тип смените? Ведь при загрузке проверка УИД = ЗаписьРегистра.УИД в случае смены типа на строку будет выдавать Ложь, не смотря на то, что внешне выглядят одинаково?
Или регистр ваш и проверки ваши? Тогда даже при огромном количестве записей разница в объеме будет не такой уж критичной даже при миллионах записей в регистре.
Если регистр не ваш, то корректнее будет добавить реквизит и заполнять его в менеджере регистра просто при записи.
Или регистр ваш и проверки ваши? Тогда даже при огромном количестве записей разница в объеме будет не такой уж критичной даже при миллионах записей в регистре.
Если регистр не ваш, то корректнее будет добавить реквизит и заполнять его в менеджере регистра просто при записи.
УИД вручную платформа не генерит, УИД это массив сгенерированный системой (windows API CoCreateGUID()), и уникален он в пределах компьютера (там где происходит генерация), время возможно внутри есть, но проверка на уникальность (в винде) происходит по реестру...
(39) GUID уникален не только в пределах компьютера, в этом его смысл :)
В двух словах: любой GUID состоит из трех основных частей, комбинация которых и обеспечивает его уникальность. Части стандартизированы. Есть несколько версий и несколько алгоритмов генерации, но в целом они про одно и то же
1) 6 байт определяют место генерации
2) около 8 байт определяют время генерации с точностью до долей миллисекунд (точность несколько отличается в разных версиях)
3) около 2 байт - условно случайная последовательность
Просто там еще несколько бит на версии формата и алгоритмов, поэтому и "около".
Получается, для совпадения GUID'ов с разных компов должны совпасть "идентификаторы" компов, время генерации и сгенерированная условно случайная последовательность. Справедливо предполагается, что этой вероятностью можно пренебречь.
В двух словах: любой GUID состоит из трех основных частей, комбинация которых и обеспечивает его уникальность. Части стандартизированы. Есть несколько версий и несколько алгоритмов генерации, но в целом они про одно и то же
1) 6 байт определяют место генерации
2) около 8 байт определяют время генерации с точностью до долей миллисекунд (точность несколько отличается в разных версиях)
3) около 2 байт - условно случайная последовательность
Просто там еще несколько бит на версии формата и алгоритмов, поэтому и "около".
Получается, для совпадения GUID'ов с разных компов должны совпасть "идентификаторы" компов, время генерации и сгенерированная условно случайная последовательность. Справедливо предполагается, что этой вероятностью можно пренебречь.
(40) учитывая, что в 1С для разных объектов метаданных уникальность не отслеживается, то можно предположить, что УИД не формируется ОС, а генерируется самой платформой. Тем более, что расположение частей не стандартное. Да и формат хранения в базе совсем другой.
(42) Да все там стандартное (во всяком случае мне неизвестно ни одного факта, говорящего в пользу обратного). В чем особенность хранения в базе я здесь уже говорил. В любом случае, у меня нет задачи кого-то в чем-то убеждать. Что знал - тем поделился.
А что касается уникальности в пределах компа - для того, чтобы сгенерить два одинаковых гуида на одном компе необходимо их сгенерировать подряд в течение сотни/сотен наносекунд, чтобы при этом совпали их условно случайные последовательности. Учитывая, что условно случайные последовательности тоже генерятся на основании тиков таймера, подозреваю что алгоритм их генерации подобран таким образом чтобы исключить и эту вероятность.
А что касается уникальности в пределах компа - для того, чтобы сгенерить два одинаковых гуида на одном компе необходимо их сгенерировать подряд в течение сотни/сотен наносекунд, чтобы при этом совпали их условно случайные последовательности. Учитывая, что условно случайные последовательности тоже генерятся на основании тиков таймера, подозреваю что алгоритм их генерации подобран таким образом чтобы исключить и эту вероятность.
(39) Что-за чушь вы нафантазировали. GUID не зависит от операционной системы или отчего либо. Это тупо случайно генерированная последовательность. Никакой гарантии уникальности нет.
Общее количество уникальных ключей настолько велико (2^128 или 3,4028×10^38), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала.
Общее количество уникальных ключей настолько велико (2^128 или 3,4028×10^38), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала.
(47)Поздравляю! (с наличием кулинарных способностей, я тоже умею готовить, а еще у меня 3 дан по карате), но я не об этом, я о том, что конкретно винда (когда например создаешь GUID в Delphi или С) проверяет уникальность по реестру, если вам об этом не известно, то ....
Да и глупо было бы например создавать COM объекты системой с уникальным GUID-ом, надеясь на тот факт условной уникальности!
Да и глупо было бы например создавать COM объекты системой с уникальным GUID-ом, надеясь на тот факт условной уникальности!
(49)
Вы же не хотите сказать, что винда пишет в реестр все генерируемые для любых целей гуиды? Или что в виндовом реестре можно найти айдишники всех объектов 1С? :)
конкретно винда (когда например создаешь GUID в Delphi или С) проверяет уникальность по реестру, если вам об этом не известно
Вы же не хотите сказать, что винда пишет в реестр все генерируемые для любых целей гуиды? Или что в виндовом реестре можно найти айдишники всех объектов 1С? :)
(51)
Хм... Возможно просто проверяет на всякий случай, чтобы полученный GUID не совпал с идентификатором COM-объекта, уже зарегистрированного в реестре.
Насколько я понял, винда генерит гуиды COM-объектов в реестре не с помощью time-based алгоритма, а на основании имени COM-объекта (есть такой специальный вариант генерации GUID-а, когда это по сути просто хэш от указанного имени).
Хотя нет. Разные категории алгоритмов генерации UUID кодируются специальными битами. Т.е. UUID сгенеренные по разным принципам совпадать не могут. Непонятно...
но то что CoCreateGUID() лезет в реестр, однозначно
Насколько я понял, винда генерит гуиды COM-объектов в реестре не с помощью time-based алгоритма, а на основании имени COM-объекта (есть такой специальный вариант генерации GUID-а, когда это по сути просто хэш от указанного имени).
Хотя нет. Разные категории алгоритмов генерации UUID кодируются специальными битами. Т.е. UUID сгенеренные по разным принципам совпадать не могут. Непонятно...
(51) она может просто проверять зарегистрированные программы/библиотеки, не более того. Но даже это сомнительно.
Но может быть даже проще: считывать параметры, такие как МАК. Он примеряется для генерации GUID.
Или еще вариант: Система генерирует пул guid. Просто тупо считывает очередной.
Но может быть даже проще: считывать параметры, такие как МАК. Он примеряется для генерации GUID.
Или еще вариант: Система генерирует пул guid. Просто тупо считывает очередной.
(45) Не "тупо". А очень даже "умно". Читайте внимательнее выше.
Самое смешное, что если подходить к формулировкам строго, то GUID - это Майкрософт :)
Это название имплементации UUID от мелкомягких.
GUID не зависит от операционной системы или отчего либо
Самое смешное, что если подходить к формулировкам строго, то GUID - это Майкрософт :)
Это название имплементации UUID от мелкомягких.
1C для УИД гарантирует только уникальность, и все.
Не стоит использовать его как-то иначе.
Если нужен какой то ключ с поиском - то лучше обратить внимание (и реализовать самому) на естественные ключи.
Были уже статьи и исследования по этому поводу.
Там даже время нельзя определить однозначно - уиды формируются платформой пакетно.
Не стоит использовать его как-то иначе.
Если нужен какой то ключ с поиском - то лучше обратить внимание (и реализовать самому) на естественные ключи.
Были уже статьи и исследования по этому поводу.
Там даже время нельзя определить однозначно - уиды формируются платформой пакетно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот