Это отличный вопрос. (Существует большая вероятность, что это закончится дебатами по нормализованной и денормализованной базе данных ... которые я не собираюсь начинать ... хорошо, теперь для некоторого ввода.)
кое-что из того, что я сделал на голове, (добавит больше, когда у меня будет больше времени или мне нужен перерыв)
дизайн клиента - это то, где VB-метод inline sql (даже с подготовленными операторами) доставляет вам неприятности. Вы можете потратить AGES, просто находя эти заявления. Если вы используете что-то вроде Hibernate и помещаете столько же SQL в именованные запросы, у вас есть единственное место для большей части sql (нет ничего хуже, чем пытаться протестировать sql, который находится внутри некоторого оператора IF, и вы просто не нажимаете «триггер» критерии в вашем тестировании для этого заявления IF). Прежде чем использовать hibernate (или другие orms '), когда я буду делать SQL напрямую в JDBC или ODBC, я бы поместил все операторы sql как открытые поля объекта (с соглашением об именах) или в файл свойств (также с именами Соглашение для значений говорит: PREP_STMT_xxxx. И используйте либо отражение, либо перебирайте значения при запуске в а) контрольных примерах б) при запуске приложения (некоторые rdbms позволяют предварительно скомпилировать подготовленные операторы перед выполнением, поэтому при запуске после входа в систему я будет предварительно скомпилировать prep-stmts при запуске, чтобы выполнить самотестирование приложения. Даже для сотен утверждений на хороших rdbms это всего несколько секунд и только один раз. И это сэкономило мне много времени. В одном проекте администраторы баз данных не общались (другая команда, в другой стране), и схема, казалось, менялась НОЧЬ, без причины. И каждое утро мы получали список того, где именно оно сломало приложение, при запуске.
Если вам нужна функциональность adhoc, поместите ее в класс с хорошо названным именем (т.е. опять-таки соглашение об именовании помогает в автоматическом тестировании), который действует как своего рода фабрика для вашего запроса (т.е. он создает запрос). Вам в любом случае придется написать эквивалентный код, просто поместите в место, где вы можете его протестировать. Вы даже можете написать несколько базовых методов тестирования для того же объекта или в отдельном классе.
Если вы можете, попробуйте также использовать хранимые процедуры. Их немного сложнее проверить, как указано выше. Некоторые базы данных также не проходят предварительную проверку sql в хранимых процессах по схеме во время компиляции только во время выполнения. Это обычно включает, скажем, взятие копии структуры схемы (без данных), а затем создание всех сохраненных процедур для этой копии (в случае, если команда db внесла изменения, DID не проверяется правильно). Таким образом, структура может быть проверена. но в качестве точки управления изменениями хранящиеся процы хороши. На переменах все поняли. Особенно, когда изменения в БД являются результатом изменений бизнес-процессов. И все языки (java, vb и т. Д. Получают изменения)
Я также обычно настраиваю таблицу, которую я использую, называемую system_setting и т. Д. В этой таблице мы сохраняем идентификатор VERSION. Это сделано для того, чтобы клиентские библиотеки могли подключаться и проверять, действительны ли они для этой версии схемы. В зависимости от изменений в вашей схеме вы не хотите разрешать клиентам подключаться, если они могут повредить вашу схему (т. Е. У вас не так много ссылочных правил в БД, но на клиенте). Это зависит от того, будет ли у вас несколько версий клиента (что происходит в не-веб-приложениях, т. Е. Они работают с неверным двоичным файлом). Вы также можете использовать пакетные инструменты и т. Д. Другой подход, который я также использовал, - это определение набора схем для версий операций в каком-либо файле свойств или снова в таблице system_info. Эта таблица загружается при входе в систему, а затем используется каждым «менеджером» (у меня обычно есть какой-то API-интерфейс на стороне клиента для выполнения большинства операций с базами данных) для проверки правильности этой операции, если это верная версия. Таким образом, большинство операций могут быть успешными, но вы также можете потерпеть неудачу (сгенерировать какое-то исключение) для устаревших методов и сообщить вам, ПОЧЕМУ.
управление изменением схемы -> обновляете ли вы таблицу или добавляете отношения 1-1 к новым таблицам? По этой причине я видел много магазинов, которые всегда получают доступ к данным через просмотр. Это позволяет изменять имена таблиц, столбцы и т. Д. Я играл с идеей фактически рассматривать представления как интерфейсы в COM. то есть. Вы добавляете новый ВИД для новых функций / версий. Часто, что вас здесь привлекает, так это то, что вы можете иметь много отчетов (особенно пользовательских отчетов конечного пользователя), которые принимают форматы таблиц. Представления позволяют вам развернуть новый формат таблицы, но поддерживают существующие клиентские приложения (вспомните все эти надоедливые отчеты adhoc).
Также необходимо написать сценарии обновления и отката. и снова ТЕСТ, ТЕСТ, ТЕСТ ...
------------ ОК - ЭТО СЛУЧАЙНОЕ СЛУЧАЙНОЕ ОБСУЖДЕНИЕ --------------
На самом деле был большой коммерческий проект (например, магазин программного обеспечения), где у нас была такая же проблема. Архитектура была двухуровневой, и они использовали продукт, немного похожий на PHP, но pre-php. То же самое. другое имя. во всяком случае я вошел в версии 2 ....
Обновление стоило МНОГО ДЕНЕГ. Много. то есть. уделять недели бесплатного времени на консультации.
И дело дошло до желания добавить новые функции или оптимизировать код. Некоторые из существующих кодов использовали хранимые процедуры, поэтому у нас были общие точки, где мы могли управлять кодом. но другие области были этой встроенной разметкой SQL в HTML. Это было здорово для быстрого выхода на рынок, но с каждым взаимодействием новых функций стоимость тестирования и обслуживания по крайней мере удваивалась. Поэтому, когда мы смотрели на извлечение кода типа php, вставку слоев данных (это было 2001-2002, до каких-либо ORM и т. Д.) И добавление множества новых функций (отзывы клиентов), мы рассмотрели этот вопрос о том, как создать UPGRADES. в систему. Что немаловажно, так как обновления стоят больших денег, чтобы сделать правильно. Теперь, большинство шаблонов и все другие вещи, которые люди обсуждают с определенной энергией, имеют дело с работающим ОО-кодом, но как насчет того факта, что ваши данные должны: а) интегрироваться в эту логику, б) смысл, а также структуру данные могут меняться со временем, и часто из-за того, как данные работают, вы в конечном итоге сталкиваетесь с большим количеством подпроцессов / приложений в вашей клиентской организации, которым нужны эти данные -> специальные отчеты или любые сложные пользовательские отчеты, а также пакетные задания которые были сделаны для пользовательских каналов данных и т. д.
Имея это в виду, я начал играть с чем-то немного оставленным за пределами поля. У этого также есть несколько предположений. а) данные больше читают, чем пишут. б) обновления происходят, но не на уровне банка, т.е. один или 2 секунды говорят.
Идея состояла в том, чтобы применить представление COM / Interface к тому, как клиенты обращались к данным через набор таблиц CONCRETE (которые менялись в зависимости от изменений схемы). Вы можете создать отдельное представление для каждой операции типа - обновить, удалить, вставить и прочитать. Это важно. Представления будут либо отображаться непосредственно в таблицу, либо позволять вам запускать фиктивную таблицу, которая выполняет реальные обновления или вставки и т. Д. То, что я на самом деле хотел, - это какая-то косвенная переадресация уровня, которая все еще может использоваться в отчетах Crystal и т. Д. ПРИМЕЧАНИЕ. - Для вставки, обновления и удаления вы также можете использовать хранимые процедуры. И у вас была версия для каждой версии продукта. Таким образом, ваша версия 1.0 имела свою версию схемы, и если таблицы изменились, у вас все равно будет VIEWS версии 1.0, но с НОВОЙ логикой бэкэнда для сопоставления с новыми таблицами по мере необходимости, но у вас также будут представления 2.0, которые будут поддерживать новые поля и т. д. Это действительно было просто для поддержки специальных отчетов, которые, если вы предприниматель, а не кодер, вероятно, являются причиной того, почему у вас есть продукт. (ваш продукт может быть дерьмовым, но если у вас есть лучшие в мире репортажи, которые вы все равно можете выиграть, верно и обратное - ваш продукт может быть лучшим в плане функциональности, но если его отчетность хуже, вы можете легко проиграть).
хорошо, надеюсь, что некоторые из этих идей помогут.