Видел уже такую тему N лет назад. Константа-счетчик для МОД "УникальныйИДД" стала "сбоить" из-за восросшей нагрузки. Надо вынести ее отдельно. Вариант создания отдельной SQL таблички мне не глянулся - слишком велики возможные последствия при выгрузке-загрузке базы с потерей этой таблички.
А если завести справочник с единственным элементом и писать-читать прямым запросом - это допустимо? И какие нюансы (опыта маловато - на запись вообще не работал).

Кстати, МОД + блокировки от ТойСКЛ - это вообще бомба замедленного действия.
Нам пришлось разруливать вообще вот так (благо у Тойа есть возможность использования не-родного соединения):

Функция ПолучитьНовыйИДД()
	ЗапросСКЛ.Выполнить("BEGIN TRAN");
	КонстантаКемТоЗаблокирована=1;
	Пока КонстантаКемТоЗаблокирована=1 Цикл
		Блок	= блНачало();
		Рез		= Блок.БлокировкаОбъекта("объект.ИДД",, "EXCLUSIVE");
		Если Рез = 0 Тогда
			Система = СоздатьОбъект("Система");
			Система.Sleep(1000);
		Иначе
			КонстантаКемТоЗаблокирована=0;
		КонецЕсли;
	КонецЦикла;

	Если КонстантаКемТоЗаблокирована = 0 Тогда
		//Увеличиваем счетчик в константе на единицу
		тзп_УвеличениеИДД = "Set NoCount ON
		|UPDATE _1SConst
		|	SET VALUE = convert(varchar(255), convert(int, VALUE) + 1)
		|WHERE
		|	ID = '" + РадугаСервис.ИДКонстанты("УникальныйIDD") + "'
		|";

		Запрос = СоздатьОбъект("ToyQuery");
		Запрос.Соединиться(1);
		Если Запрос.ВыполнитьЗапрос(тзп_УвеличениеИДД) <> 1 Тогда
			Рез = 1/0;	// это большая ##па и лучше вызвать исключение
		КонецЕсли;

		никальныйIDD),10);
	КонецЕсли;

	ЗапросСКЛ.Выполнить("exec sp_releaseapplock 'ИДД'");
	ЗапросСКЛ.Выполнить("IF @@TRANCOUNT > 0 COMMIT TRANSACTION");

	Возврат Рез;
КонецФункции
 

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

можно. разницы никакой не будет

Штатно, тоже можно улучшить, достаточно везде в конфе закомментить это:

//Стр=ТекущееВремя();
//Пока Стр=ТекущееВремя() Цикл
//КонецЦикла;
 

Да, на константе. А те строки уже 100 лет заремлены с Вашей же подачи. Спасибо!

а ИД обязательно должен быть числовым и возрастающим?
может быть возможно на GUID перейти?

trad писал(а) 11. Декабря 2012 :: 05:46:


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

Да.
ИДД состоит из кода базы (5 символов) и остальное под номер.
в принципе, хватает и этого

IDD получается уникальней некуда.
причем в приделах всего пространства обмена.

Eprst писал(а) 11. Декабря 2012 :: 10:46:

Ну дык я ж тригеров навесил везде.
Справочники и Журнал документов.
After Insert,Update
а в них проверяю наличие IDD если нема то стряпаю.

ну, тригеры не спортивно..
а на апдейт то зачем вешать ?

Eprst писал(а) 11. Декабря 2012 :: 11:06:

а на счет неспортивно то что?
у тебе есть другие решения?

varelchik писал(а) 11. Декабря 2012 :: 11:07:


Ну, у меня и при 1сконст нет затыков пока..
А так, переделаю мот на свою табличку.

ЗЫ: и не у всех есть скуль, чтоб триггеры понавесить, а в своей табличке - запросто, хоть в скульлайт запросе к дбф лепи. Ну, т.е слегка модернизированный модовский алгоритм присвоения идд пользовать, без привязок к ид объекта

Ну еще бы!
Мы ж в стране советов живём (ну, по крайней мере родились в ней)
)