Re: медленно работает код или это нормально... | |
---|---|
akvvohinc Сообщений: 4212 Откуда: Москва Дата регистрации: 11.11.2008 |
Автор предложенным решением полностью удовлетворен, так как дальнейшее уменьшение времени выполнения операции все равно никто не заметит/не оценит. Придумывать несколько вариантов выполнения задачи стоит в том случае, если нельзя обойтись одним. Иначе все эти варианты - лишь усложнение как разработки, так и последующего сопровождения. |
Re: медленно работает код или это нормально... | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Это как посмотреть. Если первый вариант будет отрабатывать практически мгновенно (нахождение среднего арифметического), а второй будет выполняться не чаще, чем раз в год, то стоит подумать и о таком "комбинированном" способе. Само же по себе постоянное перенумеровывание без достаточных к тому оснований интуитивно выглядит сомнительным. Исправлено 2 раз(а). Последнее : Simple777, 02.03.18 19:45 |
Re: медленно работает код или это нормально... | |
---|---|
akvvohinc Сообщений: 4212 Откуда: Москва Дата регистрации: 11.11.2008 |
Экстраполирую сказанное - пишем: 1) мгновенный вариант, работающий каждый день; 2) вариант, работающий медленней, но необходимый раз в неделю; 3) вариант, работающий еще медленней, но необходимый раз в месяц; 4) то же, но раз в квартал; 5) то же, но раз в год; 6) и т.д. Итого пишем 5+ вариантов, хотя за глаза хватает и одного, самого медленного из них, так как разницу в скорости никто не заметит. А мне интуитивно кажется, что тебе просто жаль изводить ресурсы компьютера. Думаю, что все с точностью до наоборот - обычные номера по-порядку и их перенумерация выглядят естественно для данной задачи (думаю, для большинства это первое, что приходит в голову). А вот вариант с интервалами в номерах и средним выглядит искусственным, специально придуманным для решения той же задачи, если скорость критична. Но границу между скоростью исполнения и удобством сопровождения все равно каждый где-то проводит. Ну, получишь ты, пусть десятикратное, увеличение скорости там, где это совершенно не важно, усложнив заодно разработку/сопровождение. Считаешь, что оно того стоит? - Делай! Я же не против. Я лишь сказал, что в этом конкретном случае я бы не стал делать и среднее, и перенумерацию, если перенумерация меня полностью устраивает. (На самом деле, судя по задаче, этот номер по-порядку не такая уж невидимая вещь, и вопрос "А что там у нас идет пятым пунктом?" ИМХО вполне возможен.) |
Re: медленно работает код или это нормально... | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
В моем случае ситуация была такова. Эти самые внутренние номера хранились еще в нескольких таблицах, и делать постоянно UPDATE в нескольких таблицах - это точно перебор. Ситуации же, когда между двумя записями вставляли более 10 позиций, были нечастыми. Поэтому я и остановился на таком комбинированном способе. Если же таблица с внутренними номерами одна, то это упрощает ситуацию.
|
Re: медленно работает код или это нормально... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Для фоксовых dbf, даже внутри dbc контейнера (т.е. с использованием транзакций), такое решение будет ненадёжным при многопользовательской работе. Для серверных СУБД - ну могут быть варианты... В любом случае если есть 2 варианта - один меняет 1 запись а другой 200 - то первый предпочтительнее. Даже если придётся один раз из десяти делать update уже целых 500 записей. Из личного опыта - не очень грамотные разрабы пытались через оракловский триггер сделать такого рода "перенумерацию" - т.е. чтобы для клиента вообще всё было "прозрачно" - он вставил запись с "номер по порядку 6", и все ранее существующие записи с номерами >=6 автоматом "подвинулись". Естественно что ничего у них не вышло. И естественно что сделать так на самом деле можно, НО выглядеть это решение будет, мягко говоря, монструозно. Хотя, справедливости ради, именно вариант с явным update+insert вполне сработал бы. Проблема в том что используемые средства разработки (ORM) хоть и позволяют каким-то образом это делать, но это ТОЖЕ будет весьма массивно, малоочевидно и потому "плохо". ------------------ WBR, Igor |
Re: медленно работает код или это нормально... | |
---|---|
akvvohinc Сообщений: 4212 Откуда: Москва Дата регистрации: 11.11.2008 |
Ну, не знаю даже что и сказать... Как-то не верится, что нельзя было без этого обойтись. Я бы не ставил знак равенства между этим номером по-порядку и внутренним номером (кодом) записи. Этот номер - вполне себе прикладной номер, раз он может меняться. Неужели задачи, где никогда не выполнялся бы подобный ненадежный UPDATE() или его аналоги, часто встречаются? Что-то мне такие пока не попадались. Понятно, что автор пока не озаботился проблемами многопользовательской работы (я так и не понял, предполагается ли она), но мы-то негласно понимаем, что доп.усилия по ее обеспечению должны быть приложены, причем, даже в варианте со средним. Но предположим, что этот "номер по-порядку" был бы необходим не только для упорядочивания, но и для вывода (экран/печать/файл), то есть был бы "реальным" реквизитом объекта (с условием обязательности натурального ряда). Вариант с интервалами и средним тогда не вариант. И что? Разве возможны только ненадежные решения? Исправлено 1 раз(а). Последнее : akvvohinc, 03.03.18 03:07 |
Re: медленно работает код или это нормально... | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Когда-то давно у меня были "теоретические представления" о том, что можно, а что нельзя делать. Однако общение с заказчиками быстро выбило эту "дурь". Если главбух говорит (и притом отнюдь не глупый главбух!), что "должны быть обеспечены следующие возможности", то возражения типа "так не принято делать" не принимаются. В таких случаях приходится принимать дополнительные меры, чтобы "невозможное стало возможным", и при этом информационная система таки работала устойчиво и надежно. Эти самые внутренние номера - из той же серии. Иногда бывает так, что единственный способ отличить одну запись от другой - только при помощи таких вот "внутренних" номеров. Иными словами, "полное дублирование" по ключевым реквизитам допускается, и только по внутренним номерам (в качестве последнего поля в индексном выражении) можно обращаться к конкретной записи. Никаких требований к натуральности внутренних номеров, вообще говоря, нет. Без разницы, какую размерность будет иметь такое поле: N(10) или N(10,5). Впрочем, шериф почему-то эту разницу видит. Но на то он и шериф. Исправлено 2 раз(а). Последнее : Simple777, 03.03.18 13:33 |
Re: медленно работает код или это нормально... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Он не годится для "вывода". Или ты ещё потребуешь перенумерацию и в случае удаления элементов? Или вывода подмножеств "перенумерованных" записей А собственно в отчётах "номер строки по порядку" делается силами самого отчёта, без надобности в физическом поле с таким номером - достаточно наличия того или иного поля (полей) обеспечивающих стабильную и понятную для пользователя сортировку записей. ------------------ WBR, Igor |
Re: медленно работает код или это нормально... | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Наверное, тут имелось в виду, что внутренний номер может использоваться (а почему нет?) и для упорядочения отчета. Вот только непонятно - если упорядочение есть и оно "работает", то зачем делать каждый раз принудительную перенумерацию?
|
Re: медленно работает код или это нормально... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Для упорядочения - без сомнения, для вывода в отчёте как поле "номер по порядку" - очень сомнительное решение. ------------------ WBR, Igor |
© 2000-2024 Fox Club  |