Цитата:
Сообщение от
Vadik
А если компаний более одной?
А сколько времени (...)? А триггер проверялся для случая (...)? (...) Не проще вправить мозг стандартному "дефрагментатору" и успокоиться еще на пару лет?
Я тут за автора попробую ответить.
Для начала, код очевидно "сырой". В том смысле, что писался под конкретную задачу и как решение "в общем случае" не годится. В этом решении важен не конкретный код, а сама идея хранения "дыр" и своевременное переключение нумератора на очередную "дыру". Ну, а "допилить" код под свои нужды - уже дело техники. Важна сама идея.
Теперь по вопросам:
1. Насчет компаний, сам же и ответил. Не вижу особых проблем добавить фильтр по компаниям
2. Время выполнения определения "дыр"
Очевидно, по крайней мере, будет не больше, чем время дефрагментации. Кроме того, очевидно, есть предмет для оптимизации алгоритма. Чего не скажешь про алгоритм дефрагментации.
Ведь поиск дыр - это чистые запросы, а дефрагментация - это запросы+модификация. Если запросы еще можно оптимизировать (да и сам алгоритм изменить), то с модификацией особых вариантов нет. Надо модифицировать ВСЕ записи. Быстро это выполнено быть не может
Кроме того, как справедливо заметил
Gustav, можно разбить процесс поиска дыр на этапы, чего в принципе невозможно сделать для дефрагментации.
3. Преимущества, по сравнению с дефрагментацией (явно не прозвучало, но вопрос очевиден)
Дефрагментация, как бы ей мозги ни вправляли, всегда оставляет вероятность того, что где-то чего-то не учли и ссылки будут нарушены. При использовании "дыр" такого быть не может, поскольку ссылки не меняются.
Цитата:
Сообщение от
Vadik
P.S. Особенно если в простых случаях (нет виртуальных компаний и правильное наследование типов для ссылок по RecId) все и так само собой работает
Как мне кажется, это из области фантастики. Большинство российских внедрений кастомизировано по самое "не балуйся". Причем не один раз и самыми разным людьми с очень разным опытом. Поэтому простых случаев не может быть "по определению"