сделать чистый отрыв от ненормализованного широкого стола

Question

Я постараюсь сделать этот пример максимально простым. Я пытаюсь реализовать управляемый доменом дизайн (бизнес-объект для представления каждой таблицы) в старом приложении VB6, которое не следует шаблонам ООП. Существующий код написан так же, как вы могли ожидать от 10-летнего приложения VB (то есть использование ADODB.Recordset без intellisense для полей). Существующий код не является ООП, и я стараюсь придерживаться его существующих шаблонов. Одна из моих проблем здесь заключается в том, как обрабатывать изменения в базе данных по мере появления новых требований, не создавая слишком много путаницы для разработчиков, которые могут взглянуть на дизайн БД позже.

Предположим, в этом приложении у нас есть гипотетическая таблица «Клиент», которая явно перегружена как таковая: clientId ClientName ContactName Адрес Город Штат Почтовый индекс CreditLimit CurBalance (и так далее и так далее ...)

Новое требование требует новых финансовых полей: Условия процентной ставки

Было бы приемлемо разбить InterestRate и Условия на отдельную таблицу «Fiancials», которая может выглядеть как странное разделение, так как в исходной таблице будут существовать 2 финансовых поля?

В идеале старые финансовые поля (CreditLimit, CurBalance) должны быть перемещены в эту новую таблицу, но из-за риска взлома МНОГИХ частей приложения нежелательно перемещать поля. Я просто хочу прекратить нынешнюю практику создания стола все шире и шире.

По сути, я думаю, что я хочу оставить старый дизайн кода / таблицы в одиночку, сделать разрыв с новыми полями и создать доменные объекты для обработки любых существующих и новых таблиц, т.е. объект Client может предоставлять свойство Financials, представляющее новые Financials. таблица.

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

спасибо за любые мысли

Answer 1

Вы можете использовать представления. Вы можете сделать так, чтобы представление «Клиенты» больше не отображало финансовую информацию, а представление «Финансы» создавалось для предоставления информации. То, что они используют одну и ту же базовую таблицу, не имеет значения для конечных пользователей, потому что ...

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

Кроме того, вы можете переименовать таблицу, разделить ее и создать представление под старым именем таблицы.

Важно помнить, что бизнес-объекты не отображают 1-1 в таблицы. Будут таблицы связей для отношений (например, client_account связывает клиентов с учетными записями, скажем), но не будет никакого бизнес-объекта для отношений, вместо этого у объекта клиента обычно будет коллекция учетных записей и / или наоборот, в зависимости от ограничений проекта .

Answer 2

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