Программа "Амадей Моцарт" для работы в ЕГАИС : ЕГАИС в опте и рознице

Вячеслав! Как-то неудобно, т.к. здесь обсуждают Моцарта, а не Жукова... Так, что по замечаниям по моему инструменту велкам в https://olegon.ru/showthread.php?t=17546&page=6, а по возможностям моих систем: https://olegon.ru/forumdisplay.php?f=72... В частности читал и смеялся над Вашими попытками отделить обороты, доходы, возвраты по поставщикам и etc, когда меня изначально это не "гондурасило", т.к. учет ведется исключительно по партиям

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

Я в увеличение быстродействия не особо верю. Когда-то меня в универе учили проектировать микропроцессоры. То, что все переменные начинают в памяти занимать 16 байт, даже самые простые счетчики и булевы переменные, конечно раздувает до неразумного размер расходуемой памяти, однако в зависимости от операции скорости скорее падают чем растут. Они вырастут на переменных где действительно нужно сочетание высокой разрядности и точности чисел, но, как правило, нам нужны переменные, в которых нужно записать 1-2 цифры.... Количества это как правило до 100, пусть до 1000 , цены это как правило от 10 до 1000 рублей, и еси всегда для всех цифр использовать 64 разрядные 8 байтовые переменные, процессор хоть и кажется что за один тик выполняет какую-нибудь операцию умножения, однако внутри процессора микропрограмма все равно начинает двигать биты в переменной, а когда их много, то на это расходуется лишнее процессорное время - двигать в основном нули в этих 64 разрядах. На высокоточных и высокоразрядных данных скорость растет при переходе от 32 к 64 разрядности, а на низкоточных и низкоразрядных данных скорость только падает. помню как разработка калькулятора у меня был курсовой проект на простой логике к155ЛА3 2и-не. И писал микропрограмму умножения для управляющего автомата операционным автоматом. Чем больше разрядов тем тормознее эта микропрограмма работает.

Изучая тему сборки проги под конкретную ОС до кучи проверял быстродействие... Согласен, что на математических операциях скорее всего получим деградацию скорости 64 разряда по отношению к 32/16 разрядам на дополнительных потерях по адресации, но меня "математика" мало интересовала, а волновала скорость работы с БД.

Сейчас актуальны 32 разрядная система умеет работать с 4Гб памяти (реально ОС оставляет 2.5Гб) + 1 Гб резерв под индексы и фактически требует (общий_размер_всех_таблиц * 3)... Была БД с общим объемом таблиц 2 Гб, т.е. в 32 разрядной ОС излишек БД свопировался на жесткий диск... и вот на этом примере и увидел преимущества 64 ОС и программы собранной под неё... Сейчас, по факту нет пользователей с такими БД.... Замечу - измерялось: примерно равное число операций, размер БД, УС Лэнд: 320Мб, 1С платформы 2.0: 5.8Гб, 1С платформы 3.0 14 Гб

Вообще, Моцарт прав. 64 битные программы позволяют адресоваться к большему объему памяти, а скорость выполнения операций при этом снижается. Дальше уже зависит от приложения и характеристик железа. Кстати, чтобы снять ограничение с размера базы, не достаточно просто перекомпилить программу в 64 бита. Должен драйвер (библиотека, через которую работает прога с базой) поддерживать длинные указатели. Насколько я знаю, это не такой простой вопрос, требующий существенной модификации кода драйвера.

Сейчас посмотрел размер моей базы данных главного склада, которая отработала с 1993 года по сей день, обслуживала 4 собственных магазина и кучу сторонних, в которой 2000 наименований товаров.... Общий объем базы данных 33 мегабайта. Я по экономичности обскакал всех. Но это моя собственная разработка базы данных, я делал ее максимально экономичной.
Думаю что в других системах такие раздутые базы от полного отсутствия гениальности их изобретателей. Думаю что там просто мусор на 99% хранится. И по быстродействию я думаю что я вне конкуренции. Одно дело перелопачивать 33 мегабайта другое дело 15 гигабайт.

А причина этого - в бездумном использовании индексов везде где не попадя. Какой смысл в индексах на документе из 10 товаров?
У меня быстрейшую из не индексных сортировку и поиск я сделал по рекурсивному алгоритму. Мгновенная работа на документах наиболее вероятного небольшого размера, очень быстрая работа на документах до 10 000 записей... А уж на критичных справочниках свыше этого размера я скрипя зубами добавил один самый критичный индекс - по идентификатору товара. И придумал что в группах справочника товаров они всегда по алфавиту вставляются - что дало возможность сделать не индексный мгновенный бинарный поиск. Работать с товарами по алфавиту всегда удобно, быстродействие самое максимальное, и никаких раздуваний базы индексами. Никто не сравнится со мной в гениальности технологий, в экономичности, в быстродействии. Можно поливать грязью, а гениальность мою не превзойти. И это не какая не теория бреда. Это реальная программа, установленная в 1500 предприятий с 1993 года по сей день. Это проверено практикой.

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

Действительно, а зачем человеку язык? Что-бы молоть чушь?

Извините, но за всю жизнь и до этого Вашего утверждения, не слышал о профессиональном тестировании Вашей СУБД Да и в списке миллиардеров не встречал разработчиков УС на уникальной СУБД собственной разработки... а Вы не предлагали её лохам в MS или Oracle?

Однако, если серьёзнее, в срезе сельмага... Как можно проверить Ваше утверждение о выдающейся производительности СУБД? Да и ещё, что-бы это было доказуемо для all?

Одна мысль, но сколько в ней неоднозначных утверждений!!! Я в восторге! Попробую написать, но не буду доказывать, т.к. требует много времени... Однако эти исследования проводились в 2010-2011 годах.

1. Возможно скорость в рамках Ram, как писал выше у 32 разрядного приложения выше, но я писал о ситуации выхода из пределов памяти;
2. Приложения на [x]Harbour имеют единый исходный код, компилируются в один код для приложений любой разрядности, т.е. мне ничего не нужно "модифицировать":
3. На этапе сборки exe файла выбранным компилятором C++ происходит подключение библиотек от C++, адаптированных под соответствующую ОС и/или разрядность... В результате моё прикладное приложение сразу начинает удовлетворять технологиям, ограничениям среды компиляции C++... При обсуждениях, например убирается ограничение на размер файла 4Гб или точность расчетов.