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

Книга знаний: Быстрое создание и настройка правил обмена для зависимых объектов в Конвертации Данных v8

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

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

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

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

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

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

(7) да, в этом. И ещё в тормозном интерпретаторе

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

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

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

ps.. как хранится в файловой версии - одному б.н известно..

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

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

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

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

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

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

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

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

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

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

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

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

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

(20) France в (10) говорит что гуид=16 бит

GUID 128 бит 16 байт.

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

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

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

(24) точняк
http://www.ibase.ru/devinfo/test2.htm

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

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

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

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

(30) бред

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

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

(29) Завидуй!

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

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

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

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

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

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

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

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

Производительность GUID
Шон МакКоун (Sean McCown)

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

Приведем основные причины, по которым НЕ следует пользоваться GUID.



· Они слишком большие, чтобы стать эффективным индексом. Чем меньше индекс, тем лучше, — это позволяет быстро найти значение ключа. Ни при каких условиях 16­байтный индекс не сравнится с 4­байтным.

· Их слишком трудно запоминать администраторам баз данных, и потому сложно вникать в вопросы с данными.

· Они не гарантируют уникальность. Вероятность того, что значение GUID будет уникальным, весьма велика, но это не 100%.

· Они слишком быстро приводят к фрагментации таблицы. Поскольку они совершенно случайны, нельзя знать заранее, где произойдет следующая вставка, поэтому кластеризация по этому ключу НЕПРЕМЕННО вызовет фрагментацию.

Поэтому не позволяйте своим разработчикам использовать GUID, особенно в системах, которые вам самим придется сопровождать. Проблема состоит в том, что ничего нельзя менять без твердых цифр и никто не проводил тестирования такого рода вещей. А вот я протестировал! Разница в производительности потрясает. Конечно, найдутся разработчики, которые все же будут настаивать на применении этих идентификаторов, но пусть стараются. Однако одно несомненно — ничего нельзя менять без обоснования в виде реальных цифр. Но теперь вы можете пойти к ним и показать, почему в базах данных лучше обойтись без GUID.

Заключение
У идентификаторов GUID есть своя ниша, но она, разумеется, не расположена рядом с кластеризованными индексами. Если вам все же приходится хранить GUID, создайте для него столбец где­нибудь в конце таблицы, а кластеризованный индекс стройте по ID, а не по нему. Тогда вы сможете обращаться с запросом к нужному GUID, а затем взять соответствующий ему ID и выполнять все, кроме первоначального поиска, по этому маленькому полю ID. По­моему, очень забавно, что разработчики получают требование уникальности, — их мозг попадает в заложники к GUID. Им в голову не приходит ничего иного. Один раз меня даже назвал идиотом один программист, который считал, что логические требования — это самый важный аспект приложения и что учитывать в приложении соображения производительности — кратчайший путь к провалу. Попробуйте­ка воспользоваться этой логикой и запустите 500 или 1000 одновременно работающих пользователей. А когда ваше приложение встанет, позвоните своему заказчику и скажите ему, что производительность приложения не такая уж важная штука.

http://newsletter.narod.ru/sql_pages/sql_may_2006.htm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты же сам говорил что гуидам есть альтернатива - лонгинт+код объекта+код базы

http://www.rsdn.ru/article/mag/200301/GUIDEcology.xml
:)

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

Просмотрел еще раз ветку, не увидел ответа на вопрос:
Почему LONG INT  в запросах быстрее GUID?

Также не убедительны решения в (22) вопроса присвоения нового идентификатора LONG INT без выборки данных из таблицы.

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

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

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

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

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

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

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

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

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

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

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

(64) Ты (22) просто не просек....

(74) нет-нет. Не десятки раз, я этого не утвержал. У меня основной прирост по другой причине произошёл.
Ну визуально процентов на 20-30 может побыстрее стало.
ну кстати это соотносится с мнением здесь
http://www.aspnetmania.com/Forums/ForumMessage/72164.html

(64)+
(66)огласите номера постов...

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

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

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

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

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

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

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

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

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

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

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

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

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

(88)(90) Дятлы!
Когда я пишу SELECT PRIMARY KEY FROM Bashmaky, сервер подсовывает мне примари кей для справочника башмаки именно по этой схеме.

Если СКЛ Сервер это не умеет, это может делать сервер 1С предприятия....
НУ и ДЯТЛЫ!

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

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

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

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

(94) Специально для дятлов повторяю - ПРИ ЗАПУСКЕ СЕРВАКА СЧИТЫВАЕТСЯ МАКСИМАЛЬНОЕ ЗНАЧЕНИЕ КЛЮЧА.

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

Я блин на блокировках собаку съел, а этот молодой и зеленый меня поучать собрался!

(95) ты путаешь моменты... когда сервак выдает новый ключ, он берет новое значение из памяти, а уже записывается с этим ключом объект. где здесь вилы.
Сознайся что ты ступил, ну или отмажься - скажи, что не понял.
Если не въехал до сих пор, приведу пример на спичках, блин, ибо достал...
(96) Я не знаю, как работает поле идентити, может и так.

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

Запуск сервера
Максимальный ключ = 10, заносим в оперативку сервера 10
Запрос на выдачу ключа, выдаем 11, в оперативку заносим 11
Запрос на выдачу ключа, выдаем 12, в оперативку заносим 12
Записался объект с ключом 11
Запрос на выдачу ключа, выдаем 13, в оперативку заносим 13
Записался объект с ключом 13
Запрос на выдачу ключа, выдаем 14, в оперативку заносим 14
Обана, шухер - перезагрузка. Клиенты отрубились, сервер перестартовал.
Запуск сервера
Максимальный ключ = 13, заносим в оперативку сервера 13
Запрос на выдачу ключа, выдаем 14, в оперативку заносим 14
Запрос на выдачу ключа, выдаем 15, в оперативку заносим 15
Запрос на выдачу ключа, выдаем 16, в оперативку заносим 16

Ну и нахрена тут ГУИД???

В результате этой последовательности будут такие записи:
10, 11, 13

Алгоритм повторного использования "дырок" приводить не буду, элементарно...

ДЯТЛЫ!

GUID в кластерном индексе - это зло.
Я просто уверен, что при вставке новых строк в такую таблицу будут жуткие тормоза (из-за перестройки би-дерева индексов).

(103) голос разума!

(100) в 1С-ке он так и раздает значения _IDRRef, а не каждый генерит по алгоритму получения ГУИДа. А почему бинари 16 а не интегер - наверна чтоб тупые адынэснеги не запутались в 2-х ключах (коротком и для репликации). Не всем же быть гениями :-)

(103) и не только индексов, надо же ещё и страницы данных физически перемещать, индекс-то кластерный

(105) нюню... ищи оправдания, ищи... Оказывается все тормоза в 1С-ке идут из благого желания облегчить жизнь тупых 1снегов.
Если бы БГ думал об 1снегах, он бы дал функцию для получения списка открытых форм, гыгыгы...

Ну где ты ММФ, съел, гыгыгы, приятно просрамить выскочку!

(104)так никто и не думал спорить с этим (в этой ветке), вроде, народу понравилась твоя идея генерации своего ключа :)
Кто понимает различия в индексах (кластерные/некластерные) и помнит про би-дерево из курса универа, тот втыкает в тему.

Гений блин, чего ты докопался до точек с запятыми? Уж менять длину ключа с 16-ти байтного на 8-ми байтный - это последнее чем надо заняться для повышения быстродействия. Лучше бы управление блокировками сделали более гибким - вот здесь есть где разгуляться. Ну в 8.1 вроде говорят сделали. Это хорошо.

(106)в кластерном индексе хранятся сами данные. В некластерном - адреса на физическое расположение данных.

(110) не гони, с 16 байт на 4 байта.

(112) 4 байта маловато.

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

(114) он именно так сейчас и работает и вроде пока не загнулся, по крайней мере у меня на 200 юзерах.

(115) как связан PK _IDRREF  с GUID  (на тему (0))?

(116) только тем, что размер у них одинаковый.

(0)Мои 5 копеек:
В плане производительности - GUID отстой (да и как бы мы не возмущались 1С никогда не прислушается к нашим мнениям), но зато в плане УРБД - это замечательная идея. Созданный объект становится уникальным во всей вселенной. Мне очень нравится сей факт.

(114) читать еще раз... сервер выдает ключи по запросу, другими словами - при создании новой записи ей проставляется новый ключ, ничего не ждется... ты о чем, товарищ, ты читать умеешь?

(118) На переэкзаменовку: читай топик, там сказано, как обеспечить уникальность объекта, не мучая индексы

(119) как ты думаешь, 4 байта для ключа достаточно или маловато? все таки 1С заявила о выходе на большие масштабы, нежели автоматизация ларьков и автостоянок.

(all) мне кажется товарища Осипова (автора сабжа) не любят из-за ника и поэтому чтобы он ни говорил все воспринимают в штыки :) Просто в данном случае он прав. А все остальное это "тупость одноэсников", которые ну просто никакие.
(121)Не могу удержаться от смеха. Офигенный аргумент :) 22 см отдыхает

(121) у регистров ключей нет, регистры есть у документов и справочников
Скажи, где нужно 4 294 967 295 элементов или документов? Для анализа ДНК?

хотя если вести персонифицированный учет всего земного шара, то не хватит - 6 млрд,  а тут всего 4 млрд. ;-)
Ну возьмите 6 байт, не жалко. ;-)

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

(123) А как быть с обменами между ИБ? Как я понял Ваш алгоритм будет задваивать LONG INT в разных ИБ. Может я просто не понял ни чего, из Вашего сабжа....

+(126) сейчас с обменом в 8.0 проблем нет, благодаря использования GUID.

(126) вы не поняли, курите топик... Здесь описаны 2 способа получения GUID для любого элемента, что ж вы так зациклены на 1С???

Я чего-то недопонимаю. 1С использует GUID в качестве внешних ключей в соединениях?

И УРБД будет хорошо работать на LONGINT и задвоений не будет...

Не путайте первичный (LONGINT) и уникальный (GUID) ключи

(129) яя

(128) понятно. значит все таки не понял. ну и ладно :))

(0) а еще 1С могла бы нормльно работать с транзакциями... а то когда говорят что в 7.7 болкировалось все, а теперь можно выбирать какие таблицы блокировать становится грустно...
(100+n) специально для этого случая придумали identity , даже думать ни о чем не надо

(123)Using the bigint Data Type
The bigint data type is an integer containing values from -2^63 (-9,223,372,036,854,775,807) through 2^63-1 (9,223,372,036,854,775,807). The storage size is 8 bytes.

это если инта не хватит

(134) да, тут уже подсказали, я просто не в курсе идентити использует такой же алгоритм или блокирует таблицу. ;-) хотя там наверное ID можно получить только после записи в БД, так?

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

по сабжу :
http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=280442&hl=%f1%f3%f0%f0%ee%e3%e0%f2%ed%fb%e9+%ea%eb%fe%f7
http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=70084&pg=-1&hl=%f1%f3%f0%f0%ee%e3%e0%f2%ed%fb%e9+%ea%eb%fe%f7

(135) короче 1с могла бы выпускать две версии, различающиеся длиной ключа - для обычных пацанов 4 байта, для трансгалактический корпораций - с длиной ключа 8 байт. ;-)

(138) да ладно, в общем все с этим понятно...

Прикиньте 4 млрд записей с ключом на GUID!!! ;-)

Ну что, MMF, лажанулся?

(142) уточни, твой генератор используется ТОЛЬКО в качестве первичного ключа и речь только о 1С v8? В таком случае нахрена он нужен? Не изобрел ли ты identity field, только на твоем сервере приложения? Уникальные генераторы или генераторы с контролем последовательности во всех промышленных sql-серверах используют обновление и хранение значения генераторов в базе, даже при откате транзакции клиента инкремент происходит.

(143) так фигли ты про блокировку трендел, раз это давно известно и называется идентити???

(143) гыгыгы, ММФ, ты в пролете...

Гм.. сам же на партнерском форуме называл использование GUID "изящное решение".

(143) не ты ли сладко пел, что LONG INT вызывает блокировки для заведения нового элемента???

(146) все может быть, но я с пеной у рта как ММФ не доказывал бредовыя вещи

(143) ну так что ММФ, ты за базар ответишь, покайся....

(147) это же ты, а не я предложил идиотскую идею перенести генерацию ид и хранение их только в памяти сервера приложений (92)? А я говорил про генераторы sql-серверов, и утверждал, что при  получении их значения происходят блокировки см. (94). Это ты сказал, что "съел собаку на блокировках" и тут вдруг оказывается, что изобрел велосипед с квадратными колесами. Дятел это ты, дружище.

(150) не отмазывайся, все ходы записаны...

(94) Нет, батенька, вы говорили именно про блокировки, которые якобы возникают в момент запроса ключа для нового элемента справочника...

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

Про какие блокировки в таком случае ты говорил, ну ка-ну ка!?

Короче, да, Ответь по существу: Про какие блокировки шла речь, если блокировок нет... Утрись, зеленый юнец!

Возможно что использование более оптимальных структур данных было-бы замечательно. Что этой веткой Г1С ты хочешь нам сказать? Что 1С лажает? Ну лажает, однако систему назначения уникальных индексов они не сменят. Что ты крут и все такое? И что тебе медальку за это.

что то никак не могу найти инфу о том, во сколько раз в среднем повышается время поиска по индексу при увеличении его размера в 2 раза. Ни у кого нет ответа на этот вопрос?

(155) да, я хочу сказать что я крут и не нужно со мной спорить в духе "Я умный, ты дурак", потому что обычно, как показывает вскрытие и случай с ММФ, все совсем наоборот...

Да, они не сменят, потому что тупари... ;-)
Ладно, я понял через год юзания 80, что ГУИД - это зло, а они куда смотрили? БГ и компани?

(150) Ну че, ты ответишь, про какие блокировки вел базар или будем считать тебя лохом?

(158) Я действительно не знал про identity, поскольку занимаюсь fb, отсюда и ноги высказывания про блокировки. Но походу и ты не знал, "крутой":
(152) "С индетити я встречался", (96) "Я не знаю, как работает поле идентити". Думаю, что блокировки на уровне страницы данных все равно происходят, поскольку значение identity фактически соответствует физическому номеру записи, то генерируется следующее значение путем чтения предыдущей записи. Но никак не +1 в памяти, да еще и select max(id) при старте. Уточню этот вопрос, потом плюну, если что, на тебя еще раз.

(157) Какой-то юношеский максимализм проявляете...мистер... почему обязятельно или зло или благо. Есть плюсы есть минусы.
Кста binary PK пошли с 8-ки. В 7-ке int.  Наверно так и есть решили не заморачиваться. Только вот еще - индексы сиквлом не строятся. 1С сам похоже строит свои индексные таблицы. Возможно там есть какая-то оптимизация.
(159) жаль нельзя посмотреть значение dentity как и сделать ему инкремент ;)

(159) Блин, ММФ, я тебя прощу, если в твои мозги наконец то дойдет, как работает алгоритм, описанный в (100). Я не утверждаю, что алгоритм идентити работает именно так.

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

Поэтому утверждение что ГУИД помогает решать какие-то проблемы блокировки - чушь!

(160) что такое бинари РК?

(162) первичный ключ

(160) Вот именно соль подхода - "не заморачиваться".. гыгыгы....
тогда о какой ЕРП на 80 может идти речь, если главный подход в построении платформы 80 - "не заморачиваться"...
Подумаешь падение производительности на 20%, а - мы не заморачиваемся, гыгыгы...

хотя справедливости ради сказать, что оба БГ на вопросах производительности не заморачиваются - что Виндоус Командир, что Директор Фирмы. ;-)

(161) Г1С, когда же ты поймешь, что такой механизм не может использоваться, поскольку он не надежен. На примере того идентити. Есть возможность его установить руками - достаточно разрешить установку setidentiny в On. Таким образом алгоритм увеличения путем чтения+инкремент предыдущей записи в БД будет работать точно так же. А если все операции со значением Ид происходят только в памяти сервака, то нужно решить массу геморроев с параллельностью потоков запросов, с ручной установкой текущего значения и т.д.

Слышь, Гений, а ты стало быть продолжаешь утверждать, что Primary Key справочников 1С 8.0 строится по алгоритму GUID?

Господа, а теперь - ВУАЛЯ.
Я открою вам страшную тайну, почему 1С использует ГУИД.
Только не говорите, что вы об этом знали.

Короче, как вы знаете некоторые столбцы могут хранить ссылки на разные таблицы.

Раньше в 77 в ссылке хранился номер таблицы и ID в этой таблице.

Теперь предполагается что каждый объект имеет уникальный ID.

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

В 1С же ГУИД используется именно для того, чтобы объединить всевозможные таблицы (помните ошибку 255 таблиц СКЛ) и затем по ГУИД найти нужную запись.

Вот и весь секрет, надеюсь внятно рассказал.

Можно было даже при таком подходе вместо ГУИД использовать 4 байта на код внутри таблицы и 2 байта (номер таблицы) + 4 байта = 6 байт на внешние ссылки.

Все равно меньше, чем 16 байт.
Но мозги видимо у 1сцев не шибко варят.

Теперь вы понимаете истинную причину, почему юзается ГУИД?

Теперь я окончательно понял систему связей между данными 1С!!!

(166) и почему же он ненадежен, ты хочешь сказать, что в памяти сервака нет разделяемых процессами данных. Не звезди!

(167) Читай (168), думаю пациент вскрыт полностью!

(166) Это не моя головная боль, а боль разработчиков МС СКЛ сервера. То бишь наверняка они уже продумали эти нюансы.

(168) ха-ха-ха. поздравляю тебя Гений: ты в этой ветке первый Дятел!
"Раньше в 77 в ссылке хранился номер таблицы и ID в этой таблице.

Теперь предполагается что каждый объект имеет уникальный ID. "

Загляни в структуру базы и увидишь, что каждый реквизит составного типа состоит минимум из 2-х полей: _IDRTRef и _IDRRef, а если составной тип не только ссылочный - так там и строковый и дата и так далее есть. Ну и когда до тебя тупого дойдет то наконец: _IDRRef НЕ СОЗДАЕТСЯ ПО АЛГОРИТМУ GUID!!! Хочешь поспорить???

(172) Лондон, похоже Дятлы в этой ветке плодятся со страшной силой.
Для связей таблиц, согласно (168) юзается именно ГУИД. А следовательно, проистекают все недостатки. _IDRRef используется для хранимых процедур (служебных), то бишь все основные индексы строятся по ГУИД, так что все в силе, ГОСПОДИН ДЯТЕЛ!

Как он создается я недопонял, но храниться явно похоже на GUID ... хм...
транзакция создания нового элемента справочника:

SELECT
MAX(_Reference21._Code) f_1
FROM
_Reference21 WITH(NOLOCK)
SELECT @@TRANCOUNT

exec sp_executesql N'INSERT INTO _Reference21 WITH(REPEATABLEREAD) (_IDRRef,_Marked,_IsMetadata,_  блаблаб (16)', 0x9C1550505450303011DB6B4888828265, 0x00, 0x00, блабла

SELECT _IDRRef,_Version
FROM _Reference21
WHERE _IDRRef IN (
0x9c1550505450303011db6b4888828265
)
SELECT @@TRANCOUNT

(173) ну ты охренел! Предлагаю ВР по завершении спора забанить проигравшего на веки вечные. Гений, ты согласен?

вот тут похоже
SELECT
_Node4022._IDRRef f_1
FROM
_Node4022 WITH(REPEATABLEREAD)
WHERE
_Node4022._IDRRef <> @P1

Короче (168) можно кратко изложить так - любой элемент в 80 имеет уникальный номер ГУИД в пределах базы и он используется для ссылок между объектами базы.

Можно было бы юзать 4 байта на номер таблицы + 4 байта на код внутри таблиц (почти как в 77), но в 1цэ решили не заморачиваться и юзают ГУИД, при этом теряют возможность из ссылки напрямую вычленить номер таблицы... Уроды!

(175) я не азартный человек, хотя было бы прикольно обломать тебя, увы!

(177) эээ батенька, вот только песдеть теперь не надо. GIUD - это GLOBAL Uniqie identifier, а не какая то там уникальная йухня в пределах базы. цитирую (170) "Для связей таблиц, согласно (168) юзается именно ГУИД". Цитирую (177): "любой элемент в 80 имеет уникальный номер ГУИД в пределах базы"

(172)
в приведенном примере _IDRRef присвоился 0x9c1550505450303011db6b4888828265
А теперь GUID нового элемента
88828265-6b48-11db-9c15-505054503030
Найдите 10 отличий.... в общем вопрос закрыт..?

(180) Закроется, если ты расшифруешь 0x9c1550505450303011db6b4888828265

это по твоему не гуид??? гыгыгы

ты до конца дочитай да

(182) ой. пардон, да именно ГУИД, мегалондон отдыхает

(183) тетрадки забыл переставить. гыгыгы

(179) да обломай, чего ты? вон на уважаемого MMF наежжал так шопесдетс, а на меня, йух знает кого, тебе жалко типа? Сцыкун йопта, так и скажи что обоссалсо.

Лондон, кури!

(186) Ну ММФ ваще лаханулся по полной программе, явно видно, что лох идет, а тут хрен знает, я в SQL 1c 80 не часто заглядывал!

(181) ну ты согласен на условия в (175)? если нет - закрой варешку и не песди, пустозвон!

(186) ММФ я не могу уважать, он лоханулся и не признался в этом, значит паршивый человечишко. Я лично свои ошибки признаю. ;-)

(189) так ты уже продул. гыггыы Кури (180)

Может кто знает - где 8-ка хранит индексы? в сиквеле не нашел ...
Надеюсь - может там есть супер оптимизация бинарного бреда....

(192) интересно, как можно оптимизировать ГУИДЫ??? ;-)

(168) Над изречением про ошибку о 255 таблиц - ржунимагу, тупее вывода не слышал

(191) я просто еще доказательства не приводил. лень понимаешь ли без интереса играть. но тебе у тебя теперь всего 2 выхода: бесчестие или достойная смерть. так ты принамаешь условия, сформулированные в (175)?

(193) заменить на что нидь ))

(190) нет приятель, теперь у тебя шанса просто признать свои ошибки не будет. базар зашел слишком далеко. придется ответить.

(195) конечно же я посылаю тебя нафиг... ведь Волшебник никогда не забанит Гения 1С... гыгыгы

(197) слышь, малолетка, давай по существу вопроса...

(194) да ну.... и что ж тебя так развеселило...

(194) для дятлов еще раз - 1С ка при составлении запроса делает соединение со всеми таблицами, которые могут содержать записи, на которые возможна ссылка из колонки.

Поэтому если в базе более 255 объектов, использование типа ЛюбаяСсылка для запросов невозможно... Вот вам и супер-пупер ЕРП, гыгыгы....

Короче платформу 80 куда то не в ту сторону накренило по сравнению с 77...

(199) Не бери меня на слабо, мне понятия пофик

(200) Эх, упустил шанс забить сотку, впервые в жизни. гыгыгы

(204) Я так и знал, что ты обоссышьсо. Сейчас тут все время поди пытался профилером что то поймать, да так, как ты в этом нийуха не понимаешь, забросил это дело. Гыгы, ламер мля! во распесделся то, как павлин, я ваще в ахуе. Хоть ты и предпочел позор достойной сметри я надеюсь что ВР лишит тебя звания инженера знаний и ты перестанешь постить всякую йухню в книгу знаний.

(205) да ладно, тут таких пустобрехов как ты, дофига.
Я высказал свою точку зрения и пока никто не доказал обратное, истина за мной...
А ты вот и бесишься от бессилия вставить свои пять копеет.

Я открыл ИСТИНУ, наслаждайтеся!

(205) Запомни, пионер, я могу признать свои ошибки, но то что я - Гений 1С, это факт и такие Моськи типа тебя для меня как мухи...

(205) и я профайлером не искал, у меня достаточно знаний в голове, чтобы вывести все и в теории, исходя из схемы базы, что я  и проделал. Ассемблером увлекаются хакеры-неудачнеги-вирусописатели типо тебя!

(206) я на 5 копеек не играю, ламер. А то, что ты не хочешь подтвердить свои слова реальными ставками говорит только об одном - пустозвон ты обычный и есть. И все твои базары - йухня, да и сам ты в общем то тоже ХУЙНЯ. Вот так вот. Или тебе есть что возразить, гыгы?

.. жаль затрут топик.. )))

(210) Ладно, клянусь больше не буянить, буду только по существу, давайте дойдем до истины, всем на кого наехал - пардон. реально ветка интересная!

ты меня дятлом назвал ламер пока не извинишься персонально конструктива не дождешься.

varbinary(16) vs int
Плюс - уникальный (поиск дырок, контроль уникаьности)
Минус - индекс (поиск, соединение)

(213) от дырок можно избавиться с помощью моего алгоритма, уже писал, уникальность и так гарантирована для LONGINT, тогда где же плюсы GUID,
кстати откеда цитата

ну понятно... как же можно собственные ошибки признавать, а? Вот жаль у меня нет статуса инженера знаний, я бы эту ветку под названием "Гений1С - дятел" в бзню запихнул. Эй, Гений1С, помоги чтоль мне в этом праведном деле, а?!

ни асилил..
вот

кстати, Гений 1С, не имея душевных сил что либо доказать мне в рамках этой ветки, шлет мне письма следуещего содержания:

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


Ответ: Дятлом тебя, ламер, я назвал, и за это отвечу перед всеми, а ты, пустозвон, лучше бы вообще заткнулся - сошел бы хоть не за умного, но понятливого.

В общем, вероятно, здесь он разъяснит мне, как сие понимать. А также почему посетители форума недостойны увидеть его объяснений.

в общем топик в книгу знаний по наездам )
и обрезать по (0) с одним ответом
(0) Вопрос риторический.

(218) жаль что в БЗ нет категорий, я бы кинул в "Лажания 1С". ;-)

(168) хм.. если правильно понял, ошибка на 255 таблиц возлагается на 1С?.. таки, 1С тут не причем. Это ограничение MSSQL на количество таблиц, одновоременно используемых в запросе.
(192) +1 за "где хранятся индексы"))

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

(220) 1С выбирала модель и должна была подумать об ограничениях движка и как их обойти, конечно это лажа 1С... Какая это ЕРП, если не более 255 объектов может быть в базе данных...

(222) я в ахуе... Гений.. убей себя об стену... такой инженер знаний только во вред, бля буду. И кстати ты еще не забыл, что ты облажался и не ответил на мой вызов?

(223) Ммм... а если без мата, всетаки культурная беседа по теме

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

Забавно, откуда увереность что у 1Совцев не было такой идеи и информации, и обсуждения (0)

Как я понял Гений1С думал думал, и решил что они просто тупари и ничего не знали, и не думали ни о чем.

Оно конечно правильно, не стоит клякнуть перед авторитетами, да только недооценивать дурака - такая же дурость, а никак даже не талант.

1. идентити хранится в свойствах таблицы, где-то в нутрях. Для получения следующего значения не делаются ни какие запросы по таблице - оно хранится.
2. Закрывать дырки совсем не обязательно, яб даже сказал, что вообще не нужно.
(225)Ты только результаты опубликуй и параметры тестирования, вплоть до скриптов на создание таблицы и индексов.

1) GUID создаются на рабочей станции...(если на 10 машинах вызвать rnd (а гуид по сути он)то каждый гуид будет создаваться независимо) при этом проблема уникальности ложится только на нее и вопрос о блокировках вообще не стоит!
2) Нам не нужена сортировка по ключевому полю, а только поиск. точный поиск (когда мы абсолютно точно знаем элемент, а не по шаблону) легче реализовать с помощью хеш функций, а GUID подходит для этого многократно лучше и доступ по хеш не зависит от размера базы 3-4 просмотра не более даже при милиардах записей

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

(229) что бы сформировать новый longint надо найти наибольший в базе... это запрос... что дополнительная загрузка sql  и потеря времени, хранить в базе максимальный элемент увеличивая его на 1 тоже самое... плюс могут 2 машины сделать запросы а потом по полученному максимуму увеличить на 1 что повалет запись или приведет к ошибке если индекс уникальный... а это еще потеря производительности

при чтении вопрос в том что кластерный индекс по guid не нужен

Даже если и сеть блокировки на получение нового identity то они ничто по сравнению  со всеми остальными блокировками

+(231) Не знаю ни одного сервера, который бы не умел получать новый уникальный id

(232) это дополнительный запрос к SQL

(201) Задача: В офисе есть 6 томов документации +  том оглавление. Необходимо дома найти главу N. Условие: Посмотреть оглавление можно только дома...
Варианта решения такой тупой задачи 2: Припереть домой все шесть томов + оглавление или сначала принести и прочитать оглавление а потом еще сходить за нужным томом.....
Офис - база, Дом - результат запроса.
вот тебе и 256 таблиц......
и с выражениями поаккуратнее.....

Пока Истина Цикл
     
     НачатьТранзакцию();
     
     Для А = 1 По 1000 Цикл
         Док = СоздатьНовыйДокумент();
         Док.Записать();
     КонецЦикла;
     
     ОтменитьТранзакцию();
     
 КонецЦикла;

Такой простой фигнёй счетчик identity из 4-байт накрутиться за неделю.
Ну и нахера это нужно?
Только ради понтов Балабола_1С ?

(201) это возникает из за ограничений доступа... таблица доступна по чтению если... и получается дурдом...

(233) если мы получаем новый ИД автоматом во время INSERT то доп запроса нет

(237) но его надо использовать в других привязанных данных... (редко записывается элемент без привязки) теперь задача как получить идентификатор этого элемента? select?

(238) Для MSSQL будет что то типа такого
INSERT (ID, f1) Values (,f1)
Select @@identity

Select @@identity???
что то не помню такого....
может storyproc имеешь ввиду?

Из BOL

@@IDENTITY
Returns the last-inserted identity value.

Syntax
@@IDENTITY

Return Types
numeric

Remarks
After an INSERT, SELECT INTO, or bulk copy statement completes, @@IDENTITY contains the last identity value generated by the statement. If the statement did not affect any tables with identity columns, @@IDENTITY returns NULL. If multiple rows are inserted, generating multiple identity values, @@IDENTITY returns the last identity value generated. If the statement fires one or more triggers that perform inserts that generate identity values, calling @@IDENTITY immediately after the statement returns the last identity value generated by the triggers. The @@IDENTITY value does not revert to a previous setting if the INSERT or SELECT INTO statement or bulk copy fails, or if the transaction is rolled back.

@@IDENTITY, SCOPE_IDENTITY, and IDENT_CURRENT are similar functions in that they return the last value inserted into the IDENTITY column of a table.

@@IDENTITY and SCOPE_IDENTITY will return the last identity value generated in any table in the current session. However, SCOPE_IDENTITY returns the value only within the current scope; @@IDENTITY is not limited to a specific scope.

IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the identity value generated for a specific table in any session and any scope. For more information, see IDENT_CURRENT.

Examples
This example inserts a row into a table with an identity column and uses @@IDENTITY to display the identity value used in the new row.

INSERT INTO jobs (job_desc,min_lvl,max_lvl)
VALUES ('Accountant',12,125)
SELECT @@IDENTITY AS 'Identity'


епта, и эти люди спорят про блокировки и уникальные ключи...
(241)хы, дай народу ссылку на BOL, потом можно будет с ними говорить на одном языке.

Подтягивается тяжелая артилерия :)

(243) тригер- это дополнительная нагрузка на сервер...

Давайте даавай те. Я в ентом не куя не понимаю но пива уже купил

здравых мыслей ооочень мало.. и думаю, не один новичок уйдет отсель с багажом ошибочных знаний...

(246) тогда давай здравые мысли...
мне действительно будет интересно твое мнение...

(245) опоздал, приятель :-) весело было вчера.

(229)Ну вот так можно (если у кого есть возражения по скриптам - обсуждаем):
Создание таблиц.
-- Создаем таблицу "IDTABLE" с колонками "ID" и "DESCR". И уникальный кластерный индекс по полю "ID"
IF EXISTS(SELECT name
     FROM     sysobjects
     WHERE  name = N'IDTABLE'
     AND     type = 'U')
   DROP TABLE IDTABLE
GO

CREATE TABLE IDTABLE (
   ID int IDENTITY(1,1) NOT NULL,
   DESCR char (100) NOT NULL
)
CREATE UNIQUE CLUSTERED INDEX [IX_ID] ON IDTABLE ([ID])
GO

-- Создаем таблицу "GUIDTABLE" с колонками "GUID" и "DESCR". И уникальный кластерный индекс по полю "GUID"
IF EXISTS(SELECT name
     FROM     sysobjects
     WHERE  name = N'GUIDTABLE'
     AND     type = 'U')
   DROP TABLE GUIDTABLE
GO

CREATE TABLE GUIDTABLE (
   GUID uniqueidentifier ROWGUIDCOL  NOT NULL DEFAULT (NEWID()),
   DESCR char (100) NOT NULL
)
CREATE UNIQUE CLUSTERED INDEX [IX_GUID] ON GUIDTABLE ([GUID])
GO

Вставка №1
--SELECT * FROM IDTABLE (NOLOCK)

SET NOCOUNT ON

DECLARE @CNT as int
DECLARE @RND as int
DECLARE @STRCNT as int
DECLARE @STR as varchar(100) -- строка из случайных символов диапазона 65-122 длиной 100 символов
DECLARE @ROWS as int

SET @CNT = 0
SET @ROWS = 5000 -- кол-во строк, вставляемых в цикле

WHILE @CNT < @ROWS BEGIN
   SET @STRCNT = 0
   SET @STR = ''
   WHILE @STRCNT < 100 BEGIN
       SET @RND = ROUND(122*RAND(), 0)
       IF @RND > 122 SET @RND = 122
       ELSE IF @RND < 65 SET @RND = 65

       SET @STR = @STR + CHAR(@RND)
       SET @STRCNT = @STRCNT + 1
   END

   INSERT INTO IDTABLE (DESCR) VALUES(@STR)
   SET @CNT = @CNT + 1
END
GO
-- в этот момент будет @ROWS строк

INSERT INTO IDTABLE (DESCR)
   SELECT DESCR
   FROM IDTABLE (NOLOCK)
GO
-- в этот момент будет 2*@ROWS строк

INSERT INTO IDTABLE (DESCR)
   SELECT DESCR
   FROM IDTABLE (NOLOCK)
GO
-- в этот момент будет 4*@ROWS строк

INSERT INTO IDTABLE (DESCR)
   SELECT DESCR
   FROM IDTABLE (NOLOCK)
GO
-- в этот момент будет 8*@ROWS строк

INSERT INTO IDTABLE (DESCR)
   SELECT DESCR
   FROM IDTABLE (NOLOCK)
GO
-- в этот момент будет 16*@ROWS строк

INSERT INTO IDTABLE (DESCR)
   SELECT DESCR
   FROM IDTABLE (NOLOCK)
GO
-- в этот момент будет 32*@ROWS строк

Вставка №2
--SELECT * FROM GUIDTABLE (NOLOCK)

SET NOCOUNT ON

DECLARE @CNT as int
DECLARE @RND as int
DECLARE @STRCNT as int
DECLARE @STR as varchar(100) -- строка из случайных символов диапазона 65-122 длиной 100 символов
DECLARE @ROWS as int

SET @CNT = 0
SET @ROWS = 5000 -- кол-во строк, вставляемых в цикле

WHILE @CNT < @ROWS BEGIN
   SET @STRCNT = 0
   SET @STR = ''
   WHILE @STRCNT < 100 BEGIN
       SET @RND = ROUND(122*RAND(), 0)
       IF @RND > 122 SET @RND = 122
       ELSE IF @RND < 65 SET @RND = 65

       SET @STR = @STR + CHAR(@RND)
       SET @STRCNT = @STRCNT + 1
   END

   INSERT INTO GUIDTABLE (DESCR) VALUES(@STR)
   SET @CNT = @CNT + 1
END
GO
-- в этот момент будет @ROWS строк

INSERT INTO GUIDTABLE (DESCR)
   SELECT DESCR
   FROM GUIDTABLE (NOLOCK)
GO
-- в этот момент будет 2*@ROWS строк

INSERT INTO GUIDTABLE (DESCR)
   SELECT DESCR
   FROM GUIDTABLE (NOLOCK)
GO
-- в этот момент будет 4*@ROWS строк

INSERT INTO GUIDTABLE (DESCR)
   SELECT DESCR
   FROM GUIDTABLE (NOLOCK)
GO
-- в этот момент будет 8*@ROWS строк

INSERT INTO GUIDTABLE (DESCR)
   SELECT DESCR
   FROM GUIDTABLE (NOLOCK)
GO
-- в этот момент будет 16*@ROWS строк

INSERT INTO GUIDTABLE (DESCR)
   SELECT DESCR
   FROM GUIDTABLE (NOLOCK)
GO
-- в этот момент будет 32*@ROWS строк

(249) не, ну некрасиво на... такие листинги на скл.ру нужно выкладывать, а не здесь..

дааа, очень красиво получилось :(

(249) Моща!

Попробовал на SQL 2005 Express. Проц AMD Turion64 1.6Mh, память 1Гб

Получилось, что создание 160000 строк по скриптам из (249):


Замер 1:
IDTABLE    16c
GUIDTABLE    17с

Замер 2:
IDTABLE    14c
GUIDTABLE    18с

Замер3:
IDTABLE    12c
GUIDTABLE    17с

Замер 4:
IDTABLE    15c
GUIDTABLE    18с

Замер 5:
IDTABLE    12c
GUIDTABLE    10с

// Итого в среднем:
IDTABLE    13,8c
GUIDTABLE    16с



После каждого замера таблицы создавал заново.

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

(252)думается мне, что тестирование получилось однобокое...

(253) Чего так?

(254)в результатах теста не учитываются дисковые операции.

(255) Возможно. Мой комп не идеальная тестовая платформа, хотя условия теста для одной и другой таблицы одинаковые, тем более выполнил несколько замеров.

На самом деле ID или GUID - это мелочи жизни. Весь тормоз не здесь

(0) Пиши свою базу :)

(230) ERWINS, а ты не рассматривал вариант с виртуальным VIEW, который хранит максимальный ID каждой таблицы??? Не знал про такое, на переэкзаменовку!!!!
А сама виртуальная вьюха в памяти сервера лежит, так что никаких запросов, по скорости равноценно ГУИД... двоешник

Я балдею. Люди с пеной у рта спорят о вещах, в которых не разбираются. Это ведь достаточно специфическая тема. Пойдите почитайте материалы хотя бы на том же sql.ru или на других ресурсах по SQL.
Об эту тему (использование GUID в качестве ключа) давно ломаются копья спецами классом повыше, чем здесь собрались. Там далеко не так все просто, и 1С в своем решении вовсе не новаторы.

(259) когда я обращаюсь к view я вызываю запрос или запрос вызывается когда я дополняю и изменяю таблицу?... приведи пример это view...
ты у нас гений... так давай пример...

(259) А что такое "виртуальный VIEW"?

(261) чего?
(262) :-).. тут как то дебаты была на тему "виртуальных" view и виртуальных таблиц 1С.. ща опять продолжатся...

(263) О нет только не этот бред

(263) ты про мои выступления?

(265) нет, не про выступления. Хотелось посмотреть другую формулировку поста в (261)...

(265) Да было тут:
v8: Что из себя представляет виртуальная таблица остатков регистра накопления?

(266) в базе создан view на таблицу... я я далаю select view и получаю результат...
как будет обнавлятся результат если мы меняем записть в таблице или добавляем новую (2 вариант обновление виртуальной таблице на SQL сервере аля тригер или полный повторный запрос в последнем случае принципиальной разницы есть view или нет не вижу)

(267) да уж.. "плодотворная" была ветка..
(268) обновление результата запроса - сугубо личное дело клиента, которое никоим образом не контролируется SQL не зависимо от того, что запрос был к view иди к реальной таблице

(269) не правильно объяснил... будет ли SQL кешировать (заранее подготавливать данные для view) или не будет заморачиваться?

(270) чЭстно - незнаю... надо будет на эту тему почитать..

(270) Сиквел оптимизирует запросы для вьювов. Кстати в ветки указанной в (267) упоминалось

Точнее стратегию выборки данных

(272) так, оптимизация - это одно...а подготовка и хранение в памятие все таки несколько другое..
(273) а это - план запроса кажись называется..

(272) про оптимизацию плана запроса понятно... это естественно... вопрос все таки в другом :) автоматически обновляет он данные для запроса? и причем это надо делать в каждой текущей транзакции

(275) Проде как вьюв никаких промежуточных данных не хранит
http://www.sql.ru/docs/sql/u_sql/ch20.shtml

(275) тогда толку от него в данном случае как от козла молока....

(260) еще один демагог, пришел, ляпнул ни о чем, типа я крутой. Отвали!
(261) выше по тексту есть пример, как назначать уникальный ключ-счетчик без блокировок. Кури текст. Какие нафиг блокировки!!!???
(262) таблица, которая хранится в памяти сервера, а не на диске. Содержит для каждой таблицы номер последнего выданного ключа типа счетчик.

(278) Я правильно понимаю, что это твое собственное изобретение?

(279) я думаю, все изобретения уже сделаны и так и должно работать выдача первичных ключей, если конечно имеет смысл это оптимизировать, правильно грят, блокировки по созданию новых объектов на порядок реже встречаются, чем блокировки регистров.

(280) "правильно грят, блокировки по созданию новых объектов на порядок реже встречаются, чем блокировки регистров."
а почему так получается не подскажите?

(281) из практики, батенька из практики.
Новые документы и элементы справочников вводятся реже, чем перепроведение документов, при котором меняются движения по регистрам. А у движений нет первичного ключа типа счетчик.

(282) Значит если есть первичный ключ - блокировок будет меньше? Почему тогда 1С-цы не поставили первичный ключ на регистры?

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