vnkor
Т.е. умножить все pn на 10 или 100, сразу сделав "резерв". При добавлении, как уже тут предлагалось, вычислять среднее. Если не получилось со средним - перенумеровывать.

Автор предложенным решением полностью удовлетворен, так как дальнейшее уменьшение времени выполнения операции все равно никто не заметит/не оценит.

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

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

Это как посмотреть. Если первый вариант будет отрабатывать практически мгновенно (нахождение среднего арифметического), а второй будет выполняться не чаще, чем раз в год, то стоит подумать и о таком "комбинированном" способе. Само же по себе постоянное перенумеровывание без достаточных к тому оснований интуитивно выглядит сомнительным.



Исправлено 2 раз(а). Последнее : Simple777, 02.03.18 19:45

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

Экстраполирую сказанное - пишем:
1) мгновенный вариант, работающий каждый день;
2) вариант, работающий медленней, но необходимый раз в неделю;
3) вариант, работающий еще медленней, но необходимый раз в месяц;
4) то же, но раз в квартал;
5) то же, но раз в год;
6) и т.д.

Итого пишем 5+ вариантов, хотя за глаза хватает и одного, самого медленного из них, так как разницу в скорости никто не заметит.

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

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

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

Но границу между скоростью исполнения и удобством сопровождения все равно каждый где-то проводит. Ну, получишь ты, пусть десятикратное, увеличение скорости там, где это совершенно не важно, усложнив заодно разработку/сопровождение. Считаешь, что оно того стоит? - Делай! Я же не против.

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

(На самом деле, судя по задаче, этот номер по-порядку не такая уж невидимая вещь, и вопрос "А что там у нас идет пятым пунктом?" ИМХО вполне возможен.)

В моем случае ситуация была такова. Эти самые внутренние номера хранились еще в нескольких таблицах, и делать постоянно UPDATE в нескольких таблицах - это точно перебор. Ситуации же, когда между двумя записями вставляли более 10 позиций, были нечастыми. Поэтому я и остановился на таком комбинированном способе. Если же таблица с внутренними номерами одна, то это упрощает ситуацию.

akvvohinc
обычные номера по-порядку и их перенумерация выглядят естественно для данной задачи

Для фоксовых dbf, даже внутри dbc контейнера (т.е. с использованием транзакций), такое решение будет ненадёжным при многопользовательской работе.
Для серверных СУБД - ну могут быть варианты... В любом случае если есть 2 варианта - один меняет 1 запись а другой 200 - то первый предпочтительнее. Даже если придётся один раз из десяти делать update уже целых 500 записей.

Из личного опыта - не очень грамотные разрабы пытались через оракловский триггер сделать такого рода "перенумерацию" - т.е. чтобы для клиента вообще всё было "прозрачно" - он вставил запись с "номер по порядку 6", и все ранее существующие записи с номерами >=6 автоматом "подвинулись". Естественно что ничего у них не вышло. И естественно что сделать так на самом деле можно, НО выглядеть это решение будет, мягко говоря, монструозно.
Хотя, справедливости ради, именно вариант с явным update+insert вполне сработал бы. Проблема в том что используемые средства разработки (ORM) хоть и позволяют каким-то образом это делать, но это ТОЖЕ будет весьма массивно, малоочевидно и потому "плохо".

Simple777
В моем случае ситуация была такова. Эти самые внутренние номера хранились еще в нескольких таблицах

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

Simple777
Если же таблица с внутренними номерами одна, то это упрощает ситуацию.

Я бы не ставил знак равенства между этим номером по-порядку и внутренним номером (кодом) записи.
Этот номер - вполне себе прикладной номер, раз он может меняться.

Igor Korolyov
такое решение будет ненадёжным при многопользовательской работе.

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

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

Но предположим, что этот "номер по-порядку" был бы необходим не только для упорядочивания, но и для вывода (экран/печать/файл), то есть был бы "реальным" реквизитом объекта (с условием обязательности натурального ряда).
Вариант с интервалами и средним тогда не вариант.
И что? Разве возможны только ненадежные решения?



Исправлено 1 раз(а). Последнее : akvvohinc, 03.03.18 03:07

akvvohinc
Как-то не верится, что нельзя было без этого обойтись.

Когда-то давно у меня были "теоретические представления" о том, что можно, а что нельзя делать. Однако общение с заказчиками быстро выбило эту "дурь". Если главбух говорит (и притом отнюдь не глупый главбух!), что "должны быть обеспечены следующие возможности", то возражения типа "так не принято делать" не принимаются. В таких случаях приходится принимать дополнительные меры, чтобы "невозможное стало возможным", и при этом информационная система таки работала устойчиво и надежно.

Эти самые внутренние номера - из той же серии. Иногда бывает так, что единственный способ отличить одну запись от другой - только при помощи таких вот "внутренних" номеров. Иными словами, "полное дублирование" по ключевым реквизитам допускается, и только по внутренним номерам (в качестве последнего поля в индексном выражении) можно обращаться к конкретной записи. Никаких требований к натуральности внутренних номеров, вообще говоря, нет. Без разницы, какую размерность будет иметь такое поле: N(10) или N(10,5). Впрочем, шериф почему-то эту разницу видит. Но на то он и шериф.



Исправлено 2 раз(а). Последнее : Simple777, 03.03.18 13:33

akvvohinc
Но предположим, что этот "номер по-порядку" был бы необходим не только для упорядочивания, но и для вывода

Он не годится для "вывода". Или ты ещё потребуешь перенумерацию и в случае удаления элементов? Или вывода подмножеств "перенумерованных" записей
А собственно в отчётах "номер строки по порядку" делается силами самого отчёта, без надобности в физическом поле с таким номером - достаточно наличия того или иного поля (полей) обеспечивающих стабильную и понятную для пользователя сортировку записей.

Наверное, тут имелось в виду, что внутренний номер может использоваться (а почему нет?) и для упорядочения отчета. Вот только непонятно - если упорядочение есть и оно "работает", то зачем делать каждый раз принудительную перенумерацию?

Simple777
Наверное, тут имелось в виду, что внутренний номер может использоваться (а почему нет?) и для упорядочения отчета.

Для упорядочения - без сомнения, для вывода в отчёте как поле "номер по порядку" - очень сомнительное решение.