Цитата flintpit @
Вопросы:
1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное?
1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное?
Строго реляционную. Потому, как с помощью этого решаемо на 100%, потому как более широко используемо, потому как больше кому будет помочь советом.
Возможно. Но с этими двумя на практике не знаком, без комментариев.
Сперва искать ликбез по проектированию реляционных БД.
Ну а теперь "вкусненькое" ...
Типа броне-костюм для строевой подготовки на минном поле
1) "Реляцоинность" данных! Без этого в будущем будут невзгоды и лишения, которые, согласно присяге, вам нужно будет преодолевать. А оно надо вам?
Простой пример. Общеупотребимая практика. Для учета граждан создается основная таблица, состоящая из множества полей типа VARCHAR - ФИО, Адрес проживания, иногда и телефон ... Но, и фамилии меняются, и адреса, и телефоны. Со временем. А вам нужно что?
Вместо этого собираем наши информационные сущности как из "конструктора".
а) Создаем каталог "Описателей", типа:
<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>
ID - уникальный идентификатор
Name - название (используемое в UI), например ФАМИЛИЯ
Prompt - короткая подсказка
Help - длинный хелп по назначению и способу заполнения
Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия
б) Создаем каталог "Информационных сущностей", типа:
<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>
ID - уникальный идентификатор
Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО"
c) Создаем каталог "Конструкторов Информационных сущностей", типа:
<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>
ID - уникальный идентификатор
Target - ссылка на б)
Info - ссылка на a)
Cost - желаемый порядок размещения в UI
Что в результате? В результате вместо статической структуры, известной на момент сборки - получаем возможность строить нужные нам динамические структуры на момент ввода в эксплуатацию, равно как и во время самой эксплуатации. Нужно нам 90 полей - пожалуйста, нужно 91-е поле, нет проблем - решается администрированием путем создания (при необходимости поля) и "привязки" его к нужной информационной сущности.
2) "Версионность" данных! Вот оно самое:
Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа:
<{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}>
Id - уникальный идентификатор
Date - дата изменения
Type - тип изменения
Rel - ссылка на новое значение
Cause - ссылка на рубрикатор причин
Note - коментарии
Таким образом, наша сборная карточка в последствии будет иметь версионность в виде цепочки изменений. Каждое из которых можно отследить по времени и по исполнителю (об этом ниже).
3) "Журналирование" данных!
Каждую операцию нужно журналировать. "Кто-что-когда". Это позволит в будущем делать и анализ работы учетных подразделений, и позволит, при необходимости делать откаты изменений.
Ну естественно, не нужно путать принцип "Бритвы Оккама" с неоправданным упрощением информационных моделей.
По поводу "движка БД" - посоветую глянуть в сторону SQLite. Сам с ней не работал, но в планах - намереваюсь.
Удачи!
Добавлено
Вдогоночку. Забыл упомянуть про "Отчетность". Давно надумалось неплохое решение - если хранить отчеты, их UI-входные формы и выходные формы, в самой БД. Нет проблем не только для M$ Access! Простой пример. Сам интерфейс пишется на Qt/C++ , а отчеты хранятся в БД в виде VARCHAR, содержащие скриптовые подпрограммы на QtScript. Переработка отчетности совсем не потребует переработки программы. Более того, идеально решается вопрос дистрибуции изменений в отчетности.
. С этим - согласен.
! 
