Разработка базы данных для отслеживания и распределения расходов

Question

Я хочу разработать веб-приложение для отслеживания финансов членов организации.Некоторые функции очень похожи на Splittr .Я определяю свои требования с помощью диаграмм базы данных MWE:

• Таблицы "Финансы": у каждого пользователя будет одна личная финансовая учетная запись, для которой я использую три следующие таблицы красная :
• Таблицы «SharedExpense»: каждый пользователь может разделить расходы с другими пользователями во многих «группах общих расходов».Для каждой группы я использую следующие три таблицы blue :

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

Проблема : я должен связать пользователей с их 3 личными «финансами»таблицы и таблицы 3N "SharedExpense" (где N - это число групп общих расходов, к которым принадлежит пользователь).

Попытки решения :

1. Несколько баз данных.Каждый пользователь имеет уникальную базу данных для своих таблиц «Финансы».Каждая «группа общих расходов» имеет уникальную базу данных на сервере.Затем я могу связать пользователей из одной основной базы данных со следующими четырьмя фиолетовыми таблицами:
   
   Недостатки: внешние ключи поступают из разных баз данных, большое количествобазы данных для резервного копирования.

2. Несколько таблиц.Я могу создать все таблицы в одной базе данных и связать их все с четырьмя зелеными основными таблицами:
   Здесь количество таблиц является потенциальной проблемой,Если есть M пользователей и N 'групп с общими расходами, тогда будет 3M + 3N таблиц!

Вопрос: Есть либолее элегантный и простой дизайн базы данных для этой цели?Если нет, то какое из этих двух решений лучше и почему?

Ссылки на соответствующие предыдущие вопросы и ответы StackOverflow :

• База данных приложения для личных финансовдизайн
• Разработка базы данных для отслеживания прогресса во времени
• SQL для разделения счетов домохозяйств дБ
• Сравнение 1 базы данных с несколькими таблицами с несколькими базами данных с меньшим количеством таблиц в каждой

Answer 1

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

1. Основные нарушения дизайна: такие как таблица / база данных для каждого пользователя
2. дизайн объекта, 3NF: такой как category.budget и ledger.transaction_type
3. дизайн ссылочной целостности / отношения:
   • учетная запись для одного пользователя, но таблица учетных записей не содержит идентификатор пользователя;
   • usershare - это подмножество главной книги, но они оба указывают на пользователя;
4. вопросы именования объектов:
   • четкие и непротиворечивые объекты именования, основанные нана реальном использовании.Является ли участник пользователем или пользователем участником?Если они одинаковые, выберите одно имя.Если они не одинаковы, дизайн отличается.Использует ли персонал клиента или клиента, а не участника?
   • последовательность в названии вашего ключа.Имя ключа должно напрямую связывать его с исходным объектом.Members.ID должен указываться как members_id, а не user_id.Тем не менее, посмотрите следующую запись, прежде чем исправлять это.
   • Будьте последовательны в множественности вашей сущности.По общему мнению, имя должно описывать одну запись (Пользователь), а не все записи (Пользователи).
   • ledger.spent_on - это имя, очевидно, не является датой.Это может быть также указание на пользователя или категорию.Имя атрибута должно описывать атрибут без необходимости дополнительного объяснения.Например, ledger.Purchase_Date не требует пояснений.Также должно быть понятно, как это связано с сущностью.UserShare.Share действительно не говорит мне, что это содержит.

Извините, что тупой, но я бы начал все сначала.Считайте, что у вас есть хороший пробный запуск, и начните снова, используя дополнительную информацию, которую вы имеете.

• Задайте вопросы своим проектам (Все ли пользователи? Все ли пользователи?).Если ответом является что-то отличное от «Да» или «Нет», разбейте его дальше.
• Попробуйте сценарии «что, если» (Что, если общий регистр превышает бюджет категории? Как будут восприняты предыдущие расходы, если бюджет категории изменится?)
• Подумайте, какие вопросы для отчетности можно задать (Кто превысил бюджет? Сколько мы тратим на эту категорию?), А затем рассмотрим запрос, чтобы ответить на вопрос.

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

Чем лучше вы понимаете свои данные и бизнес, тем лучше будет ваш дизайн, илучше получится конечный продукт.