Август 2023. Окончательно сформировались идеи по
обновлению свободной учетной программы.Обновить ее сможет любой пользователь, сам, безо всяких сложных телодвижений, без участия так называемого "программиста" (а фактически мартышки, которая тупо нажимает кнопки и выполняет тупую малоинтересную работу, которую уже лет как 20 следовало автоматизировать. Или как минимум вывести в открытый свободный паблик-аутсорс.)
Для обновления (как и для установки новой программы) пользователь скачивает
"установочно-обновляющий комплект" (выражение уродливое, но пока лучшего нет), который
одновременно делает и установку новой программы, и обновление имеющейся. Никаких технических препятствий для создания такого комплекта нет, пример его можно скачать по адресу --
https://github.com/KursakovSA/AccBase/b ... /Debug.zip Причина, по которой так называемые "лидеры" (или "флагманы" - в кавычках) рынка, не делают так, прежде всего лежит в их жадности, и в желании сохранить орду так называемых "программистов" (а на самом деле тупых мартышек) которые только и занимаются тем, что тупо обновляют учетные программы. Почему такую элементарную работу не доверить автоматическим системам, в эпоху 5G, AI, ML, и т.д. - мне лично глубоко непонятно.
Для такого легкого, понятного и простого обновления нужно так организовать структуру свободной учетной программы, чтобы и работа по обновлению была легкой, простой и понятной, которую способен был бы выполнить пользователь сам, и не строить ненужные проблемы и трудности. Чтобы облегчить, ускорить и упростить обновление учетной программы, по мнению автора "Универсал-бухгалтерии", нужно --
---отделить саму учетную базу данных от логики программы, что, вообще-то, настоятельно и рекомендуют специалисты мирового уровня (см. классический учебник Дейта по базам данных). Но, для "флагманов" рынка мировой опыт не указ.
--сделать
легко копируемую и легко обновляемую пустую новую чистую учетную базу данных (см. например, базу
DatabaseTemplate.sqlite3)
--
отделить от самой программы и самой учетной базы данных метаданные, которые завести отдельной единой и одной базой, чтобы легко и просто обновлять метаданные, когда они будут представлены единой отдельной базой данных, а не мучительно ждать результатов сраных реструктуризаций на каждой учетной базе отдельно. В проекте WorkbookBasic метаданные и общие учетные данные для всех баз (например, МРП, МинЗП и т.д.) выделены в отдельную базу
DatabaseGlobal.sqlite3, которую можно легко обновлять простым копированием.
--
отделить от самой программы опять же самые часто обновляемые шаблоны, например, шаблоны документов, и сделат ьих единым одним блоком, одной папкой, или одной служебной БД, которую опять же будет легко и просто обновлять простым копированием поверху. А не снова как сейчас принято у "флагманов", мучительно ждать реструктуризации каждой учетной БД с раскопированными в ней шаблонами документов.
В результате этих действий, которые сильно упростят и облегчат обновление учетных БД, можно добиться эффекта, когда
трудоемкость обновления учетных баз не будет зависеть от количества самих учетных баз. Тогда соответственно и цена обслуживания не будет зависеть от кол-ва учетных баз у клиента. Ведь обновление будет выполняться простым копированием файлов в файловой системе поверху, независимо от того, сколько учетных баз ведет клиент - 2 или 200.
Отдельно для любителей облаков - если Ваши БД обновляются по устаревшей трудоемкой технологии, но Вы этого не видите, потому что Вы разместили учетные базы в облаках - ничего в рассуждениях автора не меняется. Все равно в облаках сидят такие же мартышки и точно так же трудоемко мудохаются с обновлениями. Или с ненужными реструктуризациями мудохаются скрипты - какая разница? Грузят процессоры, занимают время. Могли бы выделить часто обновляемую часть отдельно и сделать ее общей для всех баз. Но зачем? Нужно создать проблему, решить ее и выставить клиенту счета за это. Это - полезно? Это - работа, которая имеет смысл?
Тогда и орда так называемых специалистов, порожденная "флагманами" рынка, которые проводят жизнь за созерцанием процесса сраной реструктуризации, не нужна будет. Этим спецам лично я предлагаю заняться программированием (как это ни странно), проект WorkbookBasic открыт в том числе и для них. А уж коли программировать они разучились, пускай переквалифицируются в развозчики пиццы.
А мартышки в будущем не будут нужны.
P.S. И главное -
никаких сраных позорищ в виде поиска "таблеток", "лекарств", "обходов" и прочего идиотизма. Все нужное пользователям - открыто, законно, и доступно.