Какой формат хранения сборника норм внутри приложения использовать?

Question

[Monitorz_Killah]

Разрабатываю десктопное приложение на Python для расчёта норм труда. Есть справочник с базовыми нормативами в Excel, на основе которого будут строиться расчёты в приложении. Разделы и подразделы справочника будут отображаться в дереве слева.

spoiler

Какой вариант для хранения справочника и быстрого подгрузки в приложение?
Excel не совсем удобно, т.к. таблицы разношерстные по формации, и к тому же, сборник планируется пополнять другими нормативами.
Перелить это все в несколько разных JSON-файлов по разделам. Но возникли сомнения в консистенции такого вида хранения: где-то что-то потрётся или потеряется. Хранить один большой JSON со всем добром тоже негоже, кмк.
Или базу на SQLite со всеми нормами, и уже ее разворачивать при запуске приложения.

Comments

[pfg21]

конечно же сформированный внутри питона ёксель-документ !!!111111
если ты работаешь с документами, а не таблицами, то может быть использовать соответственно документоориентированую базу данных ??
а не бить перфоратором по стамеске ??

Answer 1

[Everything_is_not_so_bad]

Первое, что в голову пришло - перелить это все в несколько разных JSON-файлов по разделам.

Работать с набором JSON файлов не практично. Стоит работать с СУБД.
Воообще, с начала стоит упорядочить все справочники, поработав над нормализацией данных. Нужно избавляться от неструктурированных данных, насколько это возможно.

Следом пришла мысль завести базу на SQLite со всеми нормами, и уже ее разворачивать при запуске приложения.

А это уже хороший выбор. Советую начать с неё.
Для поддержки JSON: https://sqlite.org/json1.html

Какой наилучший вариант для хранения справочника и быстрого парсинга оного для подгрузки в приложение?

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

MongoDB точно не нужно выбирать на начальном этапе. Если на каком-то этапе будут чувствоваться ограничения SQLite, то стоит обратить внимание на Postgres.

Comments

[Monitorz_Killah]

Благодарю.
Именно стремление к структурированию, нормализации и оптимизации поставило меня перед таким вопросом. Но, т.к опыт невелик, и я ввиду этого мог не увидеть или не знать более оптимальное решение.

Я SQLite выбрал ввиду ее мобильности, чтобы можно было деплоить на разные машины без лишней возни с дополнительным ПО для конфигурирования. Да и она полностью покрывает потребности.

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

Я думал сделать отдельную таблицу с заголовками, и отдельные с нормами, и перевязать их по id-шникам - ключам. Чтобы отдельно грузились заголовки разделов и подразделов в дерево, а при выборе пункта в дереве вызывалась табличка с нормами соответствующего подраздела во всплывающем окне или области экрана

[Артем Воронов]

Monitorz_Killah, стремление к нормализации и преждевременной оптимизации в большинстве случаев ведет к:
- трате ресурсов на то, что никому не нужно
- немасштабируемому и негибкому решению
Я бы порекомендовал для начала задаться вопросами о том, как приложение будет разваиваться, чтобы подумать на пару шагов вперед. А то может оказаться, что нормативы-то неплохо держать на сервере, в одном месте. Чтобы все пользователи работали с одинаковыми нормативами, а не каждый со своей версией. И внезапно окажется, что нужен полнотекстовый поиск, такой чтобы не надо было изобретать велосипед по правки орфографии для запросов. С учетом таких требований всплывает Elastic, а не реляционные БД.

[Monitorz_Killah]

Артем Воронов, у нас есть отдельная база разработанных норм на сервере с веб-мордой и шлю.. инструментарием по работе с нормами. Но нет в ней расчётной части от базовых элементных норм. Я хочу такой инструмент создать, и чтобы он не имел привязки к сети. Например, для работы на командировочных ноутах в условиях отсутствия сети. Перед выездом проверить комплектность и актуальность базы для всех, и в путь!
Суть инструмента в прозрачном расчёте, чтобы потом не вспоминать что где и откуда бралось, если вдруг кому-то приспичит проверять расчёты сотрудников. Чтобы не лепить лишних пометок, не громоздить сводных таблиц, а получать на выходе готовый продукт с возможностью быстрых отслеживаемых правок, отслеживанию связей с исходниками, возможностью составления линеек оборудования. Из масштабирования там только подгрузка базовых норм.

[Everything_is_not_so_bad]

Артем Воронов,
Слишком далеко забегать не нужно и необходимо для начала уметь работать на минимальных мощностях и, при этом, эффективно.
Нормализация помогает структурировать информацию и держать её эффективно и стандартно для реляционных СУБД (и это не минус). Затем, поняв где что можно и лучше улучшать - перейти к более сложным решениям, взвешенно, и исходя из собственных потребностей и наличия средств.
Полнотекстовый поиск есть и в SQLite/Postgres (и прочих) . И для этого небольших проектов не нужно содержать такого монстра, как ElasticSearch (которого ещё нужно уметь содержать!).

- трате ресурсов на то, что никому не нужно

нормализация данных не нужна в справочниках?

- немасштабируемому и негибкому решению

Конечно. Давайте сразу возьмём Oracle и команду админов и всё будет работать в Кубернетисе!

Answer 2

[Adamos]

Пока SQLite, а потом сравнительно безболезненно переделаете это приложение в веб-сервис на уже выстроенной логике работы с данными в базе. Только интерфейс поменять.
JSON - тупик, а noSQL - оверинжиниринг.

Comments

[Monitorz_Killah]

а возможно ли сделать так, чтобы в дальнейшем можно было итоговую рассчитанную таблицу для конкретной единицы оборудования сажать в основную базу по локалке, если там используется MS Server? Т.е. моя программа будет что-то сродни аддона/утилиты для основной нашей рабочей базы. Сейчас в основную просто через веб-морду садится эксель с парсингом и посадкой в SQL

[Adamos]

Monitorz_Killah, конкретно с M$ Server не работаю, не подскажу.
По общей клиент-серверной логике - делаете на сервере API, которое, получая данные, пишет их в базу, пишете к нему клиент...

По общей логике развития IT в этом веке и в РФ в частности - на M$ Server лучше плотно не завязываться.
Открытый Мускуль или Постгрес на интернет-сервере тоже неплохо хранит данные, и их для этого необязательно держать именно в локалке.

[Monitorz_Killah]

Adamos, ну, это не ко мне вопросы) Я не решаю ничего в отделе IT своего предприятия

[Adamos]

Monitorz_Killah, тому, кто что-либо делает не на один раз, полезно понимать не только текущие задачи, но и перспективу. Решить конкретно то, что вы делаете сейчас, можно множеством способов - я посоветовал предположительно наиболее перспективный.

[Monitorz_Killah]

Adamos, Я вас услышал)