Есть ли надежда на написание хорошего кода поверх ужасно спроектированной базы данных?

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

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

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

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

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

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

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

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

Создайте интерфейсный слой, который обрабатывает все содержимое БД, а затем напишите свое приложение для взаимодействия с ним. В случае, если база данных когда-либо будет «исправлена», вы просто замените / обновите свой «интерфейс». Этот подход сэкономил мне массу времени, когда я имел дело с плохой базой данных или базой данных, которая подпитывала другие приложения и не могла быть испорчена.

Ой ... Вы унаследовали кошмарный беспорядок, у вас есть 30 дней, чтобы сделать его пригодным для вашей организации, и половина вашего дня занята операционными задачами?

Я уверен, что вы могли бы рефакторинг, но, конечно, не в такое количество времени.

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

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

Базы данных могут быть реорганизованы так же, как и другой код. Исправьте часть, на которую влияет код, который вам нужен для написания и написания тестов, чтобы убедиться, что больше ничего не сломается. Делайте по одному маленькому кусочку за раз, как и любой другой рефакторинг. Есть хорошая книга по рефакторингу базы данных, которая может помочь вам начать работу по устранению проблем. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Есть и другие, но я лично читал и работал с методами в этом.

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

Чтобы получить максимальную отдачу, создайте обновляемые представления, чтобы восстановить некоторую «реляционность» и предоставить более значимые имена столбцов.

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

По правде говоря, остается много вопросов, сможете ли вы сделать это за ~ 15 дней работы. В частности, это может зависеть от того, нужна ли вам двусторонняя репликация (т.е. ваше новое приложение будет фактически обновлять данные) или только один способ (ваше новое приложение просто позволяет людям просматривать данные). В последнем случае (конечно) значительно проще разобраться.

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

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