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

Question

Я создаю систему управления волонтерами, и у меня возникают некоторые проблемы с проектированием БД:

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

Например: волонтер, который добровольно вызвался 10 часов, получает бесплатную футболку.

Проблема, с которой я сталкиваюсь, заключается в том, как спроектировать БД таким образом, чтобы один профиль вознаграждения мог быть связан с несколькими проектами, а также иметь один профиль вознаграждения как «многоуровневый». Главное в этом то, что структуры вознаграждений могут измениться, поэтому их нельзя просто закодировать.

Пример того, что я имею в виду под «многоуровневым» профилем вознаграждения: Доброволец, который добровольно вызвался 10 часов, получает бесплатную футболку. Доброволец, который добровольно вызвался 40 часов, получает бесплатный чек на благодарность в размере 50 долларов США.

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

rewardprofile:
rID(primary key) - int
description - varchar / char(100)
details - varchar / file (XML)

Кроме того, могут ли записи в полях БД быть файлами?

OR

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

rewards:
rID(primary key) - int
rpID (references rewardsProfile) - int
numberOfHrs - int
rewardDesc - varchar / char(100)

rewardsprofile:
rpID(primary key) - int
description

так что это может выглядеть примерно так:

rewardsprofile:
rpid | desc
rp01 | no reward
rp02 | t-shirt only
rp03 | t-shirt and check

rewards
rid | rpID | hours | desc
r01 | rp02 |  10   | t-shirt
r02 | rp03 |  10   | t-shirt
r03 | rp03 |  40   | check

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

Ура, Иеремия Тантонгко

Answer 1

Да, поля базы данных могут быть файлами (типа бинарный, символьный большой объект или xml) в зависимости от реализации конкретной базы данных.

Таблица профилей вознаграждений может показаться сложной, если в будущем у вас будет большое количество различных наград. Одна вещь, которую вы могли бы рассмотреть, это структура вроде:

rewards:
rID(primary key) - int
numberOfHrs - int
rewardDesc - varchar / char(100)

volunteers:
vID(primary key) - int
.. any other fields you want here ..

rewardshistory:
vID (foreign key references volunteers)
rID (foreign key references rewards)

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

Answer 2

Утро

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

На рынке имеется множество хороших книг по дизайну баз данных. Я использую «Дизайн базы данных для простых смертных». Это очень легко читать и понимать.

Надеюсь, это поможет.

Answer 3

Это грубая структура того, как я справлюсь с этим:

Volunteers
    volunteerid
    firstname
    lastname

VolunteerAddress
    volunteerid
    Street1
    Street2
    City
    State
    POstalcode
    Country
    Addresstype (home, business, etc.)

VolunteerPhone
    volunteerid
    Phone number
    Phonetype

VolunteerEmail  
    volunteerid 
    EmailAddress

Project
    Projectid
    projectname

VolunteerHours
    volunteerid
    hoursworked
    projectid
    DateWorked

Rewards
    Rewardid
    Rewardtype (Continual, datelimited, etc.)
    Reward
    RewardBeginDate
    RewardEndDate
         RequiredHours

Awarded
    VolunteerID
    RewardID
    RewardDate

У вас, вероятно, будут ограниченные по времени награды, поэтому я добавил поля даты. Затем вы должны создать задание для расчета вознаграждений раз в неделю или раз в месяц или около того. Не забудьте исключить тех, кто уже получил эту конкретную награду, если это уместно (Вы не хотите давать новую футболку за каждые 10 часов работы?)

Answer 4

Да, записи полей БД могут быть файлами. Или, точнее, они могут быть спецификациями файлов, которые ссылаются на файлы. Это то, что вы действительно имели в виду?

Пока мы говорим о полях данных, которые ссылаются на другие данные, сколько вы знаете о внешних ключах? Что вы можете сделать с помощью ссылок на файлы, которые вы не смогли бы добиться еще лучше при разумном использовании внешних ключей?

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