andr2510

Глубоких технических докладов становится все меньше и меньше. Некоторые доклады совсем на тему очевидных вещей.

Скачивал, думая, что 5 стартмани это 5 СТРТМАНИ! и это не хухры мухры. Но запрос в 60+ строчек как бы.... но не суть.. У вас грубейшая ошибка:

Код

ПОМЕСТИТЬ ВТ_ПредыдущаяЦенаЧерновик ИЗ    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены = &ВидЦены) КАК ЦеныНоменклатурыСрезПоследних       ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры       ПО ЦеныНоменклатурыСрезПоследних.Номенклатура = ЦеныНоменклатуры.Номенклатура          И ЦеныНоменклатурыСрезПоследних.Период <> ЦеныНоменклатуры.Период          И (ЦеныНоменклатуры.ВидЦены = &ВидЦены)

Этот join создает временную таблицу по всей!!!!! истории цен всей номенклатуры по которой есть цена!! результатом мы имеем умирание отчета на базе с большой номенклатурой... Потому, если запрос для УТ, то где характеристики номенклатуры?

(2) Да, все верно. Я нашел в сети svg файл и нашел программу для редактирования шрифтов и соединил эти две находки:)

(1) Есть куча программ для создания/редактирования шрифтов. Я не учился этому. Просто решил задачу.

Символ EAC в обычном шрифте TTF.

В этот раз было гораздо лучше чем в прошлые разы.

(36)

Цитата
Фактически доводкой можно считать обернутое в try-exception создание файла серий с "мусором"

перед этим нужно понять причину прежде чем оборачивать:)

Цитата
А по поводу хеш-таблиц (фактически тип map) - памяти тупо не хватит

Ну естесьно не все, а в рамках серии. Самый большой текстовик 5 мегов занимал по серии. Так, что хватит.

А вообще если мы будем говорить про оптимизацию, то можно первоначально создать файл где 1 бит это наличие паспорта. Серия + номер это 10 в 10й, это 1.2 гига. Это меньше чем текстовое хранение текущих паспортов. Если на сервере есть лишняя оперативка то вообще в нее можно загнать. Тогда проверка на наличие будет заключаться в чтении бита по заданному адресу. С этим можно играться и добиться хороших результатов. И это при том, что этот файл будет всегда фиксированного объема и точно не увеличится. К примеру, если на вход подавать отсортированный массив, то можно читать страницами в рамках серии, учитывая, что заведомо будет известен адрес начала и окончания информации по серии.

Цитата
Зато теперь ты знаешь, что "архитектура" - это не просто стены и крыша.

А кто спорил и где?:)

Цитата
Вот, например, развернуть у клиентов отдельную таблицу SQL - тот еще гемор, что просьба выделить на диске 10 гигов кажется шуточной.

Я про это и написал в конце, что я против велосипедов, но иногда без них никуда.

(34) Прогнал я тест. Код проверки я изменил. В выборке сортировал по серии и просто открывал по очереди тем самым не кушал память и исключил рандомное чтение, а поиск по сути свелся на поиск в памяти по строке. ПО скорости получилось 90 секнуд против 5ти (это если не актуализировать таблицу клиентов в скульной базе, иначе 15 секунд выходит) на массиве в 30к клиентов.
Обработка тоже уложилась гдето в 40 минут. В общем результат достаточно живой. Однако всеравно на доводку ушло время. И если скуль есть, то всеравно считаю изобретение велосипедов лишним. Проигрыш в скорости выполнения не считаю критичным, ибо это не те запросы которые выполняются часто. А вот время создания и тетсирования с использованием уже готовых механизмов скуля и того-же wget для скачки, существенно меньше. И все работает из коробки:) К примеру, как выяснилось спустя 20 минут, что вылезают левые ошибки доступа к файлу. Пока потестил и понял, что в исходном файле местами в серии лежит мусор и файлы со служебными символами в имени не создаются (что логично, но изначально грешил на код создания файла).

Так, что мое мнение - нету скуля, то решить можно с помощью и C++ (я бы на C# .NET писал-бы так как 10 лет разработки на нем, там вообще есть таблицы с поиском по хэшу котрые вообще все мега шустро все сделают. С++ под .NET тоже есть. Я знаю:)) и с помощью 1С (результат вполне рабочий). Есть скуль - задача решается гораздо проще. Собственно мой пост и был про решение с помощью типовых механизмов которые тоже нужно знать и изучать, ибо скуль это не только хранилище плюс выборки. Там куча приблуд есть.

ЗЫ: Есть куча причин когда это плохой вариант. К примеру я использовал запуск exe файла для скачки, планировщик винды для регламента, и скуль как хранилище опять же с пакетами интеграции. Но! Все это может быть закрыто злобными админами и через файл + регламентное задание со скачиванием с помощью 1С может быть единственным решением.

(32) Да, перепутал O(n) и O(1) :)
Вот стало интересно. Что то мне кажется, что данный алгоритм на файле размером 1.4 гига, умрет.
Отпишусь:)) Интрига!)

(29) Согласен что можно. Но я не верю, что написанный алгоритм с тестами итп был написан быстрее чем за 2-3 часа. Там скорее всего минимум день суммарно ушел. А я про то, что можно сделать быстро и результативно.

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

Мой спич про простоту реализации. Изучить Си для реализации, если его не знаешь или еще что то, мне кажется сложным. Если ты только 1С-ник.