Филосовский вопрос. Если я правильно понимаю, все таблички в 1С на техническом уровне имеют клчом гуид. Вопрос: а почему это гуид а не число? ведь для процессора куда проще сравнивать числа а не строки. представьте себе прирост производительсноти, если бы уникальность осуществлялась числами

так вопрос же в уникальности, а не сравнении

гуид - это число (внезапно)

ну да, так-то число

(2) слишком длинное...

(5) тебя сильно [...]?

(0) скорее всего был задел на обмен данными

(1) ну почему же. Допустим я хочу найти все продажи по этому поставщику. У поставщика есть гуид. Я иду по таблице и для каждой строки сравниваю гуид в поле поставщик с моим гуидом. А теперь представьте что сравниваются не гуиды а Int

гуид 128 бит, инт 32 или 64
большая разница?

(5) зато уникальное

не, ну так-то автор прав. вернее, я поощряю его изыскания
а почём там выигрыш будет?

(11) в случае 1с выигрыша не будет

[smile=:D]

(5) а насколько она нужна - уникальность эта? вот зачем кодам поставщиков быть отличными от кодов номенклатуры? пусть код материалов будет уникальным для материалов
(11) (12) не знаю. Но саповцы рассказывают, что одним из важнейших преимуществ их column based database является то, что она хранит в строках только ключи типа число и к каждой колонке есть свой словарь который мапит эти числа к реальным значениям. За счет этого, де, обеспечивается высокая производительность - поскольку сравнивать числа де куда быстрее...

европейская плешь проедает моцк 1сников

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

(14) Как процесс маппинга протекает? Ничего не тормозит?

(19) да вроде бы нет... В принципе то, уникальных значений одного типа редко бывает очень много. Те же номера документов. А так то я думаю они хэши юзают - для тех же строк...
(20) ну, если вся база в памяти, то это не настолько проблема
(21) ну да, может вы и правы... надо бы мне еще на тему column based database почитать...

Это как работает? Например мне нужно найти слово "хрен", я сначала ищу его в таблице маппинга, нахожу, беру из другой колонки числовой идентификатор, потом ищу по этому идентификатору в другой таблице? Так?

угу.

Инт будет уникален в пределах таблицы. Гуид будет уникален в пределах видимой вселенной (почти). Поиск по гуиду - это не та операция, которая тормозит 1с, как верно было отмечено.

(23) Хороший поиск по хэш-функции, а не маппинг

А гуиды сделаны для того, чтобы создавать отношения межу колонкам

К интам префиксы делать сложнее

Объясните новичку.
"мне нужно найти слово "хрен", я сначала ищу его в таблице маппинга" - т.е. мы ищем именно строку "хрен", а не число?
Т.е. это обычный индекс?
Если сделать обычный некластерный индекс по GUID, то будет то же самое?

(28) Строку конечно, число ведь мы не знаем. Нет, это не обычный индекс. Это как два обычных индекса. Наверняка ведь в таблице маппинга эта колонка тоже проиндексирована.

Это как если бы наименование контрагента в справочнике контрагенты хранилось не как строка, а как ссылка на справочник наименованияКонтрагентов в котором оно бы хранилось как ссылка на справочник наименованияНаименованийКонтрагентов строка.

гуид выбран из-за рбд. мы все помним какая х.ня была в 7

(0) - так везде делают

(30) до сих пор плотно работаю с 7. Не могу спомнить. Напомни

(32) 8-ричная система

(30) какая? что-то не припомню...

(33) т.е. Я не смогу создать более 10'000'000 объектов одного типа/вида в одной базе?

(35) да, точно. запамятовал, давно не копался уже