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