В настоящее время я делаю систему платежных ведомостей, в которой есть две таблицы, account_table
и payslip_table
, В настоящее время у меня возникают проблемы с дизайном базы данных, я разрываюсь между созданием отношений между двумя таблицами или не создаю их вообще. Думаю, я сначала объясню, как работает эта система:
Таблица счетов имеет следующие столбцы:
1. employee_id
2. пароль
3. first_name
4. фамилия
5. user_type
Таблица платежных ведомостей имеет следующие столбцы:
1. payslip_id
2. employee_id
3. зарплата
4. налог
5. total_deductions
6. итоговая зарплата
Требования к этой системе: владелец хочет загрузить платежную ведомость, даже если у него «нет учетной записи для пользователя».
В. Тогда почему ваши столы спроектированы таким образом?
О. Платежный лист по своей природе имеет значение employee_id, и его присутствие является ключом к определению того, какой платежный лист принадлежит кому. Для того, чтобы я эффективно показал листок с зарплатой, все, что мне нужно сделать, — это сравнить пользователя сеанса (который я упомянул, это идентификатор его сотрудника, поскольку это его имя пользователя) с employee_id в таблице платежных ведомостей и просто повторить строку, к которой был применен запрос.
В. Что происходит с платежными ведомостями, когда пользователь больше не является сотрудником? На payslip_table будут бесполезные строки
A. Я решил создать столбец с именем created_on
и добавьте триггер для удаления платежных ведомостей, которым исполнилось 3 месяца (поскольку они уже не используются)
В. Что происходит с учетной записью, когда пользователь больше не является сотрудником?
A. Администраторы имеют право удалять пользователя. После того как пользователь ушел из компании, администраторы могут закрыть учетную запись, и, как упоминалось выше, платежные ведомости удаленного пользователя будут в конечном итоге удалены.
В. Зачем проходить через все эти неприятности?
О. Владелец конкретно заявил, что он хотел, чтобы платежные ведомости были готовы, даже если учетная запись еще не была создана, поэтому, если один человек должен был создать учетную запись, его платежные ведомости автоматически готовы к просмотру.
У меня очень минимальные знания в проектировании баз данных, и я очень открыт для предложений.
Или, если вы, ребята, могли бы предложить альтернативный способ выполнения требования с использованием внешних ключей, тогда это был бы наилучший путь.
Вы должны создать отношения между ними, как вы можете видеть Вот Вы сможете добавить нулевое значение в поле внешнего ключа и заполнить его позже employee_id.
Это поможет найти строки и убедиться, что нет бесполезных данных о потере места.
Единственная проблема, которую я вижу, заключается в том, как администратор связывает платежные ведомости, уже находящиеся в системе, с новой учетной записью сотрудника. например найти правильные платежные ведомости для нового номера сотрудника
Других решений пока нет …