Итак, я работал над этим проектом на работе, где Im кодирует веб-сайт php, который взаимодействует с базой данных, на которую я не контролирую. База данных была "разработана" сотрудником, который был с компанией еще много лет, чем у меня; поэтому в конечном итоге им разрешается принимать решения.
Когда меня впервые вытащили на борт по этому проекту, я пошел к сотруднику и объяснил, что схема базы данных кажется ошибочной. Я объяснил важность нормализации базы данных для обеспечения проблем с целостностью данных, экономии дискового пространства и облегчения работы программистов (меня). Я даже привел примеры того, как аномалии вставки, удаления и обновления могут возникать в текущем проекте. Тем не менее коллега объяснил мне, что они не хотят усложнять базу данных проектов и что это не изменит период.
Итак, теперь я пару месяцев в проекте, и я вытягиваю свои волосы каждый раз, когда мне приходится присоединяться к двум таблицам, чтобы вставить значение в атрибут, который имеет отношение один к одному. (Таким образом, атрибут должен был быть атрибутом основного отношения.) База данных выглядит ужасно, и я боюсь, что через несколько лет это вернет меня, поскольку я запрограммировал интерфейс, который использует базу данных.
Есть ли у кого-нибудь какие-либо предложения относительно того, как говорить "превосходного" сотрудника в правильном проектировании базы данных? Или любые предложения о том, как избежать получения патронированных лет в будущем для дизайна, в котором у меня не было какой-либо части? Должен ли я просто отказаться от работы над такими проектами в будущем? Оставить комментарий в моем коде, говоря, что база данных не была моей?
Спасибо.
Изменить: Дополнительная информация в ответ на комментарии...
Я знаю, что де-нормализация базы данных может быть полезна для скорости, поэтому я не забываю об этом. Для тех, кто читает, кто не слышал об этой тактике, я иллюстрирую пример. Часто разработчики баз данных имеют отношение адресов, в котором перечислены пользователи, город, штат и почтовый индекс. В то время как все знают, что почтовый индекс определяет город и состояние, поэтому он составляет таблицу, индексирующую почтовые индексы для города и состояний. Часто разработчики баз данных объединяют две таблицы, де-нормализуя их с предусмотрительностью, что для каждого запроса для адреса пользователя требуется соединение из таблицы адресов в zip-таблицу. Это в конечном счете ускоряет процесс запроса и является обоснованным аргументом в пользу де-нормализации частей дизайна базы данных.
Чтобы заполнить некоторые детали здесь, база данных предназначена для системы запроса тура, поэтому данные внутри связаны с информацией о посетителях, датами и т.д. Схема, которую использует текущая база данных, непредсказуема от начала до конца. Из простейших несоответствий в шаблонах именования переменных (пример: num_of_visitors, arrivalMethod и т.д.), Чтобы иметь отдельные отношения, определенные для одного состояния один-к-одному атрибуту. Пример: statusID представляет статус запроса на тур, у него может быть только одно допустимое состояние, выбранное из группы возможных состояний (одобрено, отклонено, отложено, отменено). По какой-то причине в базе данных есть таблица состояний, содержащая: tour_id (Primary ключ отношения тура), statusID. Это позволяет определять несколько состояний для каждого запроса тура. Который, по проекту, запрос на тур должен находиться только в одном состоянии в любой момент времени. Таким образом, его недостаток в дизайне не является моим контролем.