Как убедить кого-то нормализовать базу данных?

Изменить задание.

РЕДАКТИРОВАТЬ:

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

Серьезно подумайте о поиске новой работы. Для разработчика действительно отличные рабочие места. Это не так. Вы зря теряете время.

Может быть, вы можете указать операции, которые необходимо выполнить с этой базой данных, и предложить ей реализовать их как хранимые процедуры в базе данных? ... Определенно поставил бы проблему там, где она должна быть ... с человеком, который ее вызвал.

Самым позитивным способом было бы работать с коллегой и пытаться развиваться и воспитывать их образ мышления. Возможно, обсуждение ошибок, которые вы допустили в прошлом, поможет ему легко разобраться и показать ему / ей последствия плохо спроектированной системы.

Если у вас не так уж много плохого опыта, который мог бы вам помочь, я бы посоветовал вам записать, сколько времени (время или деньги) уходит на выполнение конкретных задач / дефектов. Затем вы можете производить статистику, всем менеджерам нравится график, который, мы надеемся, покажет, как со временем увеличилось время, необходимое для добавления функций или устранения дефектов.

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

Попытка скрыть плохо спроектированную базу данных за слоем - это всего лишь «взлом», и ИМО, это должен быть план Б. Для плана А я бы попытался «перейти на более высокий уровень».

Как вы описали, у вас нет полномочий влиять на человека, вносящего изменения в базу данных. Затем я бы пошел к архитектору (если он есть) или к менеджеру проекта, если архитектора нет.

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

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

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

Я бы порекомендовал последовать уже данному совету, чтобы создать слой вокруг базы данных. Заполните его комментариями типа «Делаем эту сложную вещь, потому что таблицы БД 1 и 2 не нормализованы». Не подвергайте критике свои комментарии. Держите их строго техническими. Время от времени обсуждайте с коллегами / менеджером дизайн базы данных. Купите книгу по теме и положите ее где-нибудь на обозрение. Когда кто-то спрашивает, предлагаю одолжить. Тем не менее, ваши основные усилия должны заключаться в написании хорошего кода.

Отнесите их в подвал. Дайте им выбор: носить с собой большой диван или 4 маленьких стула :)

Когда она говорит, что не хочет чрезмерно усложнять базу данных, возможно, она имела в виду, что не знает или не компетентна в нормализации баз данных. В этом случае одним из способов было бы попытаться убедить ее в преимуществах нормализации и отправить ее на изучение нормализации базы данных. Одна из причин для нормализации заключается в том, что просто создание базы данных - не единственное требование к базе данных. База данных существует, потому что она используется как хранилище данных. А что хранит данные? Прикладное программное обеспечение. Таким образом, создатель базы данных должен настолько уважать разработчика программного обеспечения, чтобы он нормализовал базу данных. В противном случае это была бы действительно неловкая ситуация. Чтобы упростить задачу, вы можете сначала показать несколько более простых операций нормализации, чтобы начать с ними работать.

Этот вопрос можно перефразировать, включив в него любой дизайн и реализацию, независимо от предметной области.

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

Если старший дизайнер и руководство не заботятся / не понимают, обычно делать не так уж и много. То же самое всегда, когда требуется какое-либо изменение в sw, которое существует уже некоторое время. Получить одобрение изменений людьми, которые изначально разработали систему, часто невозможно по разным психологическим причинам, если только вы не являетесь начальником и не можете «форсировать» проблему. И даже тогда в некоторых случаях это может оказаться невыполнимым (вы можете перестать нуждаться в слишком большом количестве изменений в вашем ПО).

Тем не менее, одним из возможных вариантов может быть конкретная проблема, например, с производительностью. Если вы сможете продемонстрировать, что лучший дизайн БД решит эти проблемы, вы сможете добиться некоторого прогресса.

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

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

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

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

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

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

Когда база данных широко используется, происходит обмен данными. Это подразумевает обмен знаниями. Знание - сила. Когда власть делится, происходит политика.

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

Покажите высшему руководству этот вопрос. Это покажет им, что нормализация в той или иной форме - это не просто «усложнение» базы данных.