Как убедить кого-то нормализовать базу данных?
Итак, я работал над этим проектом на работе, где Im кодирует веб-сайт php, который взаимодействует с базой данных, на которую я не контролирую. База данных была "разработана" сотрудником, который был с компанией еще много лет, чем у меня; поэтому в конечном итоге им разрешается принимать решения.
Когда меня впервые вытащили на борт по этому проекту, я пошел к сотруднику и объяснил, что схема базы данных кажется ошибочной. Я объяснил важность нормализации базы данных для обеспечения проблем с целостностью данных, экономии дискового пространства и облегчения работы программистов (меня). Я даже привел примеры того, как аномалии вставки, удаления и обновления могут возникать в текущем проекте. Тем не менее коллега объяснил мне, что они не хотят усложнять базу данных проектов и что это не изменит период.
Итак, теперь я пару месяцев в проекте, и я вытягиваю свои волосы каждый раз, когда мне приходится присоединяться к двум таблицам, чтобы вставить значение в атрибут, который имеет отношение один к одному. (Таким образом, атрибут должен был быть атрибутом основного отношения.) База данных выглядит ужасно, и я боюсь, что через несколько лет это вернет меня, поскольку я запрограммировал интерфейс, который использует базу данных.
Есть ли у кого-нибудь какие-либо предложения относительно того, как говорить "превосходного" сотрудника в правильном проектировании базы данных? Или любые предложения о том, как избежать получения патронированных лет в будущем для дизайна, в котором у меня не было какой-либо части? Должен ли я просто отказаться от работы над такими проектами в будущем? Оставить комментарий в моем коде, говоря, что база данных не была моей?
Спасибо.
Изменить: Дополнительная информация в ответ на комментарии...
Я знаю, что де-нормализация базы данных может быть полезна для скорости, поэтому я не забываю об этом. Для тех, кто читает, кто не слышал об этой тактике, я иллюстрирую пример. Часто разработчики баз данных имеют отношение адресов, в котором перечислены пользователи, город, штат и почтовый индекс. В то время как все знают, что почтовый индекс определяет город и состояние, поэтому он составляет таблицу, индексирующую почтовые индексы для города и состояний. Часто разработчики баз данных объединяют две таблицы, де-нормализуя их с предусмотрительностью, что для каждого запроса для адреса пользователя требуется соединение из таблицы адресов в zip-таблицу. Это в конечном счете ускоряет процесс запроса и является обоснованным аргументом в пользу де-нормализации частей дизайна базы данных.
Чтобы заполнить некоторые детали здесь, база данных предназначена для системы запроса тура, поэтому данные внутри связаны с информацией о посетителях, датами и т.д. Схема, которую использует текущая база данных, непредсказуема от начала до конца. Из простейших несоответствий в шаблонах именования переменных (пример: num_of_visitors, arrivalMethod и т.д.), Чтобы иметь отдельные отношения, определенные для одного состояния один-к-одному атрибуту. Пример: statusID представляет статус запроса на тур, у него может быть только одно допустимое состояние, выбранное из группы возможных состояний (одобрено, отклонено, отложено, отменено). По какой-то причине в базе данных есть таблица состояний, содержащая: tour_id (Primary ключ отношения тура), statusID. Это позволяет определять несколько состояний для каждого запроса тура. Который, по проекту, запрос на тур должен находиться только в одном состоянии в любой момент времени. Таким образом, его недостаток в дизайне не является моим контролем.
Ответы
Ответ 1
По моему опыту, эти типы ситуаций часто приводят к беспроигрышным сражениям, к сожалению. Несколько вещей, которые вы можете сделать, чтобы дистанцироваться от дизайна, могут быть:
- Реализовать уровень доступа к данным в коде, который абстрагирует большую часть фактического дизайна базы данных, насколько это возможно. Таким образом, вы можете структурировать свой код в лучшем формате и эффективно "дистанцироваться" от использования и быть обвиненным в плохом дизайне базы данных.
- Создание представлений в БД для доступа к данным в более логичном формате
- Сделайте небольшие рефакторинги для таблиц/кода, когда у вас появится шанс, если вам это удастся.
Я бы не поместил в код уничижительные комментарии, потому что он скорее всего вернется, чтобы преследовать вас. На вашем уровне доступа к данным вы можете добавить объективные/неприступные комментарии, объясняющие, почему вы абстрагируетесь от конкретного дизайна и как его можно настроить по-другому.
Если все действительно плохо, и никто другой не поддержит вас, возможно, пришло время искать другую работу.
Ответ 2
Измените задание.
EDIT:
Короткий ответ не потому, что я шучу или не серьезно отношусь к вопросу.
Раньше я был в такой ситуации. Плохая база данных не проблема. Проблема заключается в слепом или неосведомленном управлении. Я имею в виду, если они не знают или не волнуют, что важные технические решения принимаются некомпетентными людьми, тогда все будет хуже. Это как ходить в болото.
Серьезно подумайте о поиске новой работы. Для разработчика есть действительно отличные рабочие места. Это не так. Вы зря теряете время.
Ответ 3
Возможно, вам не удастся убедить дизайнера базы данных переработать базу данных, особенно если уже существует много кода, написанного против базы данных, как она существует.
Однако вам необходимо расширить свой словарный запас, чтобы описать разницу между хорошо спроектированной базой данных и плохо разработанной. Существует много плохих проектов баз данных, которые не могут быть устранены только путем нормализации. Один из примеров, который вы даете, вырывает ваши волосы, потому что вам нужно объединить данные из отдельных таблиц, когда хороший дизайн поместил бы данные в одну и ту же таблицу.
Разделение таблицы, которая должна была быть оставлена составленной, обычно не является нормализацией. Почти все сбои в нормализации результатов в составленных таблицах, которые должны были быть разложены. от ваших комментариев о ее обучении по аномалиям обновления, я уверен, что вы уже знаете, что я мог бы научить вас нормальным формам.
Разделение таблиц по неверным причинам, иногда называемым "гипернормализацией", - это другой аромат дизайнерской ошибки. Проблемы программирования, возникающие из-за этого недостатка, сильно отличаются от тех, которые возникают из-за недонормирования.
Сколько других программистов разрабатывает код, который работает в одной и той же базе данных? Как остальные программисты относятся к дизайну? Если они действительно счастливы, это еще больше уменьшит ваши шансы на изменение вещей. Если они все согнуты по форме, вы можете уговорить дизайнера найти численность. Я знаю, что это политика, и я готов поспорить, что вы ненавидите политику.
Назад, когда я преподавал программистам о программировании и дизайне базы данных, студенты часто спрашивали, почему в работе с базами данных так много политики. Я в конце концов придумал простой ответ:
Когда база данных широко используется, происходит обмен данными. Это подразумевает обмен знаниями. Знание - сила. Когда власть делится, происходит политика.
Ответ 4
Найдите ошибку, вызванную денормализацией. Если база данных не имеет подходящих ограничений (и я предполагаю, что это не будет в данных обстоятельствах), такая ошибка будет. Я бы положил деньги на это. Если вы используете трекер ошибок, посмотрите там. Если нет, решите это самостоятельно. В любом случае, вы можете продемонстрировать, сколько урона может вызвать такая ошибка, и что они стоят для очистки.
Ответ 5
Возможно, вы можете указать операции, которые необходимо выполнить против этой базы данных, и предложить внедрить их в качестве хранимых процедур в базе данных?... Определенно поставит проблему, где она принадлежит... с человеком, который ее вызвал.
Ответ 6
Наиболее позитивным способом было бы работать с коллегой и пытаться развивать и обучать их мышлению. Возможно, обсуждение ошибок, которые вы сделали в прошлом, будет легким ледоколом и покажет ему последствия плохо разработанной системы.
Если у вас нет слишком много прошлых неудачных опытов, чтобы помочь вам, я бы посоветовал вам записать, как долго (время или деньги) решаются конкретные задачи/дефекты. Затем вы можете создавать статистику, все руководители любят график, который, мы надеемся, покажет, как с течением времени увеличилось время, необходимое для добавления функциональности или устранения дефектов.
Надеюсь, что это поможет.
Ответ 7
Попытка скрыть плохо спроектированную базу данных за слоем - это всего лишь "взломать", а ИМО - план B. Для плана A я постараюсь "перерасти" на более высокий уровень.
Как вы описали, у вас нет полномочий влиять на человека, который возится с базой данных. Затем я бы пошел к архитектору (если он есть) или менеджеру проекта, если нет архитектора.
Очень важно поддерживать ваши аргументы с хорошо документированными фактами, касающимися влияния плохого дизайна на систему, которую вы строите. Другими фактами могут быть хорошо известные проблемы для плохо спроектированной базы данных из специализированных сообществ db.
У меня недостаточно информации о вашей ситуации, но это то, что я обычно стараюсь делать, когда сталкиваются с клиентами, которые настаивают на плохо разработанном техническом решении.
Ответ 8
Часто бывает, что разработчик должен работать с клиентом, запрашивающим абсурдные вещи, или должен поддерживать/работать с устаревшим кодом, который очень плохо разработан. Конечно, вы должны попытаться убедить/просветить своих коллег, как должна создаваться база данных, но ваши основные усилия должны заключаться в предоставлении исходного кода лучшего качества. Чаще всего приходится сталкиваться с такими ситуациями.
Я бы рекомендовал следовать совету, уже предоставленному для создания слоя вокруг базы данных. Заполните его комментариями типа "Выполнение этой сложной вещи, потому что таблица 1 и 2 таблицы не нормализована". Не ставьте критику в свои комментарии. Держите их строго техническими. Раз в то же время обсудите с коллегами/менеджерами о дизайне базы данных. Купите связанную книгу и поместите ее куда-нибудь, чтобы все могли видеть. Когда кто-то спрашивает, предложите одолжить его. Тем не менее, ваши основные усилия должны заключаться в написании хорошего кода.
Ответ 9
Поднимите их в подвал.
Дайте им выбор между переносом большого кушетки или 4 маленьких стульев:)
Ответ 10
Когда она говорит, что не хочет усложнять базу данных, возможно, она имела в виду, что она не знает или не компетентна в нормализации баз данных. В этом случае одним из способов было бы попытаться убедить ее в преимуществах нормализации плюс отправить ее для изучения нормализации базы данных. Одной из причин нормализации было бы то, что просто создание базы данных не является единственным требованием для базы данных. База данных существует, потому что она используется как хранилище данных. И что хранит данные? Приложение. Таким образом, создатель базы данных должен уважать разработчика программного обеспечения настолько, что она нормализует базу данных. В противном случае это была бы действительно неудобная ситуация. Чтобы облегчить ситуацию, сначала вы можете показать несколько более простых операций нормализации, чтобы начать с нее.
Ответ 11
Покажите старшему руководству этот вопрос. Это покажет им, что нормализация в той или иной форме - это не просто "усложнение" базы данных, а стандартная процедура, которую подавляющее большинство компетентных разработчиков считают фундаментальным.
Ответ 12
Этот вопрос можно перефразировать, чтобы включить любой дизайн и реализацию независимо от проблемной области.
Это серьезная причина разочарования, когда вы попадаете в такую ситуацию. Я, к счастью, не получил в них больше, чем несколько раз, и мне удалось в значительной степени избежать затронутых частей SW. Или создайте средний слой, который позволит вам использовать более разумный формат базы данных.
Если старшему дизайнеру и руководству это не важно/понятно, то, как правило, это не очень много сделать. Это то же самое в любое время, когда требуется какое-то изменение, которое было какое-то время. Получение изменений, одобренных людьми, которые разработали систему в первую очередь, часто невозможно по различным психологическим причинам, если вы не являетесь начальником и не можете "заставить" проблему. И даже тогда это может быть в некоторых случаях нецелесообразным (вам может понадобиться слишком много изменений для вашего sw).
Одной из возможностей может быть, если у вас есть определенные проблемы, такие как производительность. Если вы можете продемонстрировать, что лучший дизайн db позволит решить эти проблемы, вы можете добиться определенного прогресса.
