Проектирование моей первой схемы базы данных: требуется предложение

Question

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

Как работает стоимость еды управления в моем отделе:

1. Всего пользователей: 15
2. Один администратора, чтобы вести учет всех затрат. он будет ежедневно обновлять базу данных.
3. Каждый член может сделать только один раз в день. Если у кого-то есть гость в любой конкретный день, он может заказать несколько блюд.
4. Обычно участники оплачивают свой счет на неделю или две заранее.
5. одно или два человека несут ответственность за привоз пищи извне, и им не нужно платить за обед. Транспортные расходы также предоставляются им. их стоимость еды + стоимость перевозки распределяется поровну с другими 15 членами расходов.

Баз данные запросы:

От администратора точки зрения:

1. он будет управлять/добавить ежедневный заказ. (Таблица: заказы)
2. он добавит платежи для всех членов, которые будут зачислены в счет «Баланс» соответствующего участника (Таблица: платежи)
3. он сможет просмотреть обзор всех заказов участников/стоимость историю и их текущий баланс в диаграмме в течение одного месяца за раз.
4. Если какой-либо участник имеет отрицательный баланс или меньше определенной суммы денег, он будет уведомлен о панели управления администратора.

С точки зрения члена:

1. он сможет увидеть его текущий баланс и историю заказов/стоимость за последний месяц за один раз.
2. он сможет увидеть последний x номер истории платежей, которые он сделал.

на основе запросов, которые я упоминал выше, я пытался разработать схему базы данных, которая выглядит, как на рисунке ниже:

Elaboration некоторых атрибутов:

EPlatenum : Добавлено количество дополнительной тарелки пищи, кроме количества заказанной тарелки.

Eplatecost: стоимость дополнительной тарелки продуктов питания. эта стоимость распределяется поровну между индивидуальной стоимостью 15 человек.

EPersonnum & EPersoncost: Количество дополнительного человека, вовлеченного в результате чего продукты питания и их общую стоимость. стоимость будет распределена поровну между индивидуальной стоимостью 15 человек.

TransCost: стоимость перевозки. стоимость будет распределена поровну между индивидуальной стоимостью 15 человек.

Вопросы:

1. какие ошибки я сделал и как я могу их преодолеть?

2. Для моей таблицы DailyList я использовал «дату» в качестве основного ключа. Можно ли использовать дату в качестве первичного ключа? ЕСЛИ не в порядке, что здесь может быть основным ключом?

3. Когда я собираюсь заполнить обзор диаграммы в течение 30-месячной стоимости/истории заказа, запрос базы данных будет огромным, я предполагаю. какой подход следует использовать для оптимизации запроса?

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

Answer 1

Мое первое впечатление:

1. Я думаю, что платеж должен быть связан на заказ (потому что пользователь платит за конкретный заказ).
2. Я не знаю, что такое DailyList, но если может быть больше двух с той же датой (и, как я могу представить, это может быть), вы не должны использовать его как ключ primari.
3. Пароль должен быть закодирован, например. SHA (поэтому varchar 15 меньше).