Бесплатная программа розничной торговли на SunFlurry. Презентация от разработчика. : Кассовые программы

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

Если Вы делаете такое предложение, мы можем подумать. У нас сейчас на рознице 4 специалиста на ~200 магазинов (из них ~150 под нашими ю.л.), не все магазины пока переведены под программу, остались под 1С и Атол. В крайнем случае, наверное, наши специалисты могут помочь.

Насчет падения базы:
СУБД не самописная. В виде СУБД используется Sqlite3 -- весьма надежная система, у нас она пока ни разу не ломалась, хотя были и отключения света, есть компьютеры, которые желали ее убить, и были SSD, которые умирали. Не могу гарантировать, что после какого-либо синего экрана, база данных не придет в негодность, для этого сервер создает резервные копии автоматически в папке backup. Частоту этих копий можно увеличить, у нас это 07:30,9:30,11:30,13:30,15:30,17:30,19:30. Т.е., около 2 часов. Это дает возможность не так опасаться за БД. Во время работы обычно создание копий не мешает, у нас задержек при пробитии чеков не было.

Переиндексация таблиц доступна из кода. SysRecalcTotals, SysRefillJournal, SysRebuildIndexes (некоторые функции пока не опубликованы в бесплатной версии, но я сделаю так, что в следующем релизе они появились). Но перед переиндексацией необходимо скопировать всю структуру БД потаблично в новый файл (с помощью резервного копирования), или выполнить на ней функцию SQlite3 .recover (см. [ www.sqlite.org/cli.html ]). См. также информацию по "recover SQLite3 database" в Интернете.

Надеюсь, никому не потребуется этим заниматься. За всю мою историю, я встречался со сломанной БД всего пару раз. Это было с MS SQL, и база продолжала работать, но некоторые таблицы отдавали ошибки после SELECT. Благо MS SQL весьма устойчива к таким вещам, я перенес все данные с начала года и остатки в новую базу. Но это было довольно давно, больше 10 лет (может быть, даже 15), база работала с 1Cv7.7.

В случае с Sqlite3 необходимо оценить последствия ее роста до очень значительных размеров, например, до терабайта.

SQLite в теории не имеет ограничения на размер базы данных. У него вопрос с многопользовательской работой, так как при записи блокируются и другие писатели, и читатели. Эта либа и спроектирована изначально для однопользовательской работы.
А вообще, лучше иметь штатную возможность безболезненного среза базы данных, т.е. удаления информации за старые периоды. Много вопросов снимает с обслуживанием огромных баз данных. Структура базы данных должна быть спроектирована с учетом обеспечения такой возможности.

В теории все просто, я говорю о практике и тех сюрпризах, которые приносит работа с большими файлами, в том числе под виндой.
Ключевые пределы - 2Гб и 32Гб. Это о которые я лично спотыкался. Уверен, что они есть и более высокие, потому предлагаю сразу крайности, просто набить базу, это же не только файлик, но и внутренности, и адресация...

SQLite это файловая база, не sql сервер. То есть некоторое файло на диске или в оперативной памяти плюс бибилиотека на сях (sqlite3.dll), которая интерпретирует свой диалект sql и через которую работают приложения. Если в качестве хранилища выбран sqlite, то можно предположить, что у каждого магазина свое файло. Поэтому большие объемы данных перпендикулярны. Как Тигину с dbf.

Даже в центральной базе нашего опта с несколькими филиалами на MS SQL, я не выращивал базу до таких размеров. 100Гб был максимальный размер, после чего я всегда ее обрезал (сворачивал). Тут дело не в замедлении работы с базой (оно было, но было минимальным), резервное копирование происходит гораздо медленнее, нужно удалить старые элементы, на которые есть ссылки и т.д. Для розницы такой базы не будет. Мы говорим о небольших и средних компаниях. Но вообще, я переводил базу MS SQL с одного из филиалов в 10Гб в SQLite3 только чтобы оценить ее работу на ней. База работала прекрасно, замедления я не почуствовал. И размер получился около 5Гб (более компактное хранение).

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

Такая возможность есть. Теоретически структура базы не имеет в этом случае значения.

Согласен со всем, но немного не согласен с этим. К чему разделение? MS SQL это тоже файловая база из двух (обычно) файлов, Postgres это тоже файловая база из множества файлов. Вся разница, MS SQL это отдельный процесс (или даже несколько), SQLite работает в том же процессе, где работает пользовательский код и использует его же память.

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

После исправления кода, я не удовлетворился скоростью загрузки. К сожалению, SQLite3 быстрее не умеет, когда происходит добавление большого количества элементов. Он работает гораздо быстрее, если сохраняются существующие записи или происходит выборка (чтение).

В текущем Кладре около 2 млн. записей (города + улицы). На моем HDD Toshiba (не SSD) 241000 записей городов загружается около 20 минут. В файле с улицами 1675000 записей, и находя пропорцию (хоть это и не совсем правильно в этом случае). получаем 2.5 часов (это с измененным кодом). Можно ли сделать быстрее на SQLite3? С такой структурой справочников, не думаю. Для проверки, я создал пустую базу на MS SQL, в розничном проекте, и запустил ту же самую обработку на том же самом HDD. 241000 записей MS SQL сохранил за 3.5 минуты, находя пропорцию, это примерно 25 минут на загрузку всей базы. Не уверен, как повел бы себя Postgres, проверять несколько лениво.

Заранее было известно, что MS SQL будет быстрее. В реальной обработке документов, однако, когда работа идет со многими таблицами внутри транзакции, пропорция по скорости записи SQLite3 меньше, так как читает он из базы несколько быстрее.

Можно ли эту задачу выполнить еще быстрее? Наверное, если бы я работал напрямую с SQL, я смог бы сделать быстрее, или если бы мы создали какие-то особые функции для загрузки и обновления большого числа элементов справочников одновременно. Нужно ли это сейчас? Сомневаюсь. ~3 часа на весь КLADR единоразово потратить можно. После этого заполненную таким образом базу можно копировать как новую, если в этом есть необходимость. Но я предлагаю все-таки загружать один регион, для одного магазина, смысла в другом подходе нет.

p.s. Чтобы обновить обработку, можно сказать текущий архив из github, распаковать его в папку Source с заменой файлов, после чего запустить Studio и обновить локальную копию базы с помощью меню развертывание. В следующий релиз это изменение будет включено.

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

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

Я с sqllite сталкивался всего лишь несколько раз, но все загрузки во всех базах упираются в то, что надо отключать синхронизацию записи.
Если гуглить по sqllite, то это приводит к команде PRAGMA synchronous = OFF, думаю, ее и надо использовать, когда речь идет о полной загрузке каких-то вторичных данных.