Как лучше организовать хранение данных?

Question

[Ivan_doc]

Не являюсь программистом. Изучаю python самостоятельно. Хочу написать программу для ведения истории болезни с выводом около 10 документов на печать с, зачастую, одними теми же данными в разных вариациях (паспортные данные, блоки текстовой информации в несколько абзацев) с возможностью форматирования затем в хороший отчёт для печати и сохранения документов в docx формате. Делаю для себя на 1 компьютер.
пытаюсь понять, каким образом лучше хранить данные, в том числе, для экономии времени изучения.
Варианты, которые рассматриваю на данный момент:
- json
- sqlite
- postrgres
Возможно есть другие варианты, где сразу реализована возможность сохранения форматированного текста.

Comments

[d'Ivan]

SQLite самое то в качестве СУБД для старта.

Answer 1

[Василий Банников]

Делаю для себя на 1 компьютер.

Тогда сразу выкидываем postgres.

Варианты, которые рассматриваю на данный момент:
- json
- sqlite

Я бы остановился на sqlite только из-за удобства организации данных, по сравнению с голыми json-ами.

Возможно есть другие варианты, где сразу реализована возможность сохранения форматированного текста.

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

Но вообще подводных камней при генерации отчётов очень много - лучше разбейте свою задачу на несколько, чтобы оценить свои силы (отдельно хранение и получение данных и отдельно - формирование хотябы одного печатаемого отчёта на их основе)

Comments

[Ivan_doc]

Спасибо.
Буду sqlite изучать.
Про форматированный текст вопрос появился после попытки сделать тоже самое в access. Там можно задать сразу текст rtf в ячейке и задать вывод с заполнением по ширине.
Простые отчёты делать там получилось, но для создания полноценного приложения все равно глубже лезть в программирование vba оказалось нужно.
Вот и задался вопросом, в какую сторону идти.

[Василий Банников]

Ivan_doc,

Про форматированный текст вопрос появился после попытки сделать тоже самое в access. Там можно задать сразу текст rtf в ячейке и задать вывод с заполнением по ширине.

С Access тут небольшой нюанс есть - это не только СУБД, но ещё и платформа для написания приложений (те самые формочки и возможность редактировать отображение данных в таблицах).
Такой 1С на минималках.

В случае с Python вам придётся часть с вводом-выводом данных как-то отдельно на Python делать.

Answer 2

[alexalexes]

Как бы выразиться помягче...
Вы даже не представляете какой объем системы нужно разработать, чтобы выводить 10 отчетов, и если нужно будет 11-ый отчет добавить. Вам придется решить вопросы не только хранения данных.
Обычно, студенты профильного направления только на 3 курсе начинают осознавать масштаб бедствия.
Вот пример, какого кунгфу нужно достичь, чтобы решить вашу задачу:
https://dspace.tltsu.ru/jspui/bitstream/123456789/...

Comments

[Ivan_doc]

Спасибо за ответ. Прочитал файл. Многое из этого сделано - я начинал делать таблицы в Access 2010. Пробовал реализовать свою идею в нём. Потом понял, что для создания удобного в работе приложения, с ведением историй болезни десятка пациентов все равно нужно изучать программирование Access. На рабочем месте стоит пиратская виндовс с офисом.
Посомневался, что выбрать, изучать дальше access, в ситуации все большего блокирования софта иностранного, или все таки потратить время на изучение других вариантов.
Был ранее некоторый опыт программирования в python.
Решил, что мне проще будет в нём реализовать идею. Тем более есть и другие потребности в автоматизации работы дальнейшей.
Существующие продукты не подходят, как верно указал Ваш ученик в своей работе. Даже разные отделения одного ЛПУ часто сильно отличаются по шаблонам документов отделения. Потому хочу попытаться сделать сам, чтобы возможно было ещё и править потом.
По этой работе получается оптимальным вариантом хранения все таки база данных оказалась, при чем тот же access вроде как.
Не подскажете, встроенный в python sqlite не будет более простым и достаточным вариантом для этой задачи, или все таки взять за основу уже созданные таблицы в access и наладить взаимодействие на python с дальнейшим GUI через tkinter?

[alexalexes]

Ivan_doc, пример приведен из случайного вуза, случайного студента. Просто по запросу "Диплом автоматизированная/программная/информационная система поликлиники". Но тем, не менее это не отменяет того, что нужны определенные навыки проектирования подобных систем.
---
Про выбор базы. Если очень утрированно. Пока в системе отсутствует второй пользователь, и нет никакого намека на разделение прав доступа, нет намеков на использование транзакций, то MS Access или SQLite хватит сполна. Но как только надо будет разделить между двумя пользователями ресурс системы, либо между двумя процессами, то все, добро пожаловать в клиент-серверную архитектуру, и во взрослую СУБД, хотя бы в Postgres.

[Ivan_doc]

Спасибо.
sqlite и возьму за место хранения данных.

[Александр]

Ivan_doc, Просто для информации: Насколько я знаю, некий аналог access есть в Open Offcie. Я никогда его не пробовал, но возможно он работает =)
На счёт использовать Sqlite я бы поспорил, даже если сейчас делаете только для одного компьютера. Возьни примерно одинаково что и с нормальной базой, но с нормальной базой потом нет проблем подключить ещё пользователей. А с Sqlite сначала надо будет мигрировать.

Answer 3

[rPman]

Если работа с данными не подразумевает многопользовательский доступ на запись (и с оговорками на чтение) то база данных формально не нужна. Главная фича бд - транзакции и удобный доступ к данным, ценой накладных расходов. Если же данных не много и работа с ними из одного места, то можно и в файлах все хранить, загружать из целиком в оперативную память.

Иногда стоит не усложнять систему. Пример реализации, которой я активно пользовался лет 10 назад - в ms visual studio используя winforms можно очень легко создавать интерфейс бд, там часть базы оформляется в виде реляционного слепка реальной базы в памяти, буквально кликая мышкой. Так вот объекты в памяти можно было сохранять и считывать из файла .xml. это было на столько удобно что для малых размеров база данных в принципе не нужна.