Выбор схемы БД для приложения личных финансов

International Russian
1

Хочу написать простое веб-приложение для учета личных финансов используя Yii. Собственно, базовый функционал достаточно простой - вводить операции дохода, расхода, перемещения в базу. Каждая операция должна содержать информацию о категориях по дебиту и по кредиту, сумму и другие дополнительные поля. Соответственно, категории могут быть: статьи доходов, статьи расходов и места хранения.

Я придумал два варианта организации базы данных.

2984

Variant 1.jpg

Простая схема - таблица для операция, таблица для категорий (всех), вспомогательная таблица для типов операций и таблица для типов категорий.

Плюсы данной схемы - простота и легкость в расширении (можно новые типы операций добавить, немного изменив данные во вспомогательных таблицах).

Минусы:

[list=1]

[*]Нужно делать несколько контроллеров для категорий (статьи доходов, статьи расходов и так далее), которые будут работать с одной моделью (категории). Ни в одном из примеров я не видел такого случая, поэтому есть подозрения, что имеются "подводные камни" в данном подходе.

[*]Так как типы операций и категорий представлены в виде значений объекта, а не прописаны в коде, то с ними работать сложнее - как достоверно определить, что данная операция - это, например, "Расход"?

[/list]

2985

Variant 2.jpg

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

Плюсы - каждой категории соответствует определенный AR-класс, легче с ним работать.

Минусы:

[list=1]

[*]Сложность структуры, для расширения функционала нужно создавать новые таблицы.

[*]Для каждой операции - свой класс, что не удобно, когда нужно вывести все операции в одной таблице. Или при расчете оборотов по месту хранения - он присутствует во всех таблицах. Ну и дополнительно - нужно как-то связать общую таблицу операций и таблицы конкретных операций в коде, возможно, изменять стандартное поведение AR-класса.

[/list]

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

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

Заранее спасибо.

2

Я бы выбрал этот вариант, оформленный в виде single table inheritance.

Т.е. для каждой логической сущности (расход, приход, …) - своя модель, не смотря на то, что физически это записи в одной и той же таблице.

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

Но в случае с single table inheritance вы можете сделать классический один контроллер - одна модель.

Опять же, согласно описанию single table inheritance - в зависимости от типа операции у вас будет создаваться объект соответствующего класса - т.е. и в коде будет четко разделено где какая операция.

3

Спасибо за развернутый ответ и за ссылку. Думаю, это как раз то, что я искал.

4

А вы что UML используете в Visual Paradigm или только схему БД там нарисовали?

5

Использую этот инструмент, когда надо разобраться с какой-нибудь сложной ситуацией - не только схему БД там рисую, но и схему классов, взаимодействия пользователей. Вообще, для схемы БД могу еще порекомендовать MySQL Workbehcn.