SQL Server 2005: упаковка таблиц по представлениям - за и против

Question

Фон

Я работаю над устаревшей системой автоматизации малого бизнеса (инвентаризация, продажи, закупки и т. Д.), В которой есть одна база данных, размещенная на SQL Server 2005, и несколько клиентских приложений. Основным клиентом (используемым всеми пользователями) является приложение MS Access 2003 (ADP), а другие клиенты включают в себя различные приложения VB / VBA, такие как надстройки Excel и утилиты командной строки.

В дополнение к примерно 60 таблицам (в основном в 3NF) база данных содержит около 200 представлений, около 170 UDF (в основном скалярных и табличных встроенных) и около 50 хранимых процедур. Как вы могли догадаться, некоторая часть так называемой «бизнес-логики» инкапсулирована в эту массу кода T-SQL (и, таким образом, используется всеми клиентами).

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

FWIW, у меня довольно длинный и приличный опыт разработки приложений (C / C ++, Java, VB и еще много чего), но я не администратор. Итак, если вопрос покажется вам глупым, теперь вы знаете, почему это так. : -)

Вопрос

Размышляя о рефакторинге всего этого беспорядка (конечно, мирным способом), я пришел к следующей мысли:

1. Для каждой таблицы создайте представление «обертка», в котором (а) есть все столбцы таблицы; и (b) в некоторых случаях имеет некоторые дополнительные вычисляемые столбцы, основанные на «реальных» столбцах таблицы.

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

2. Реорганизовать весь код (как клиентский код T-SQL, так и VB / VBA), чтобы только представления «обертки» обращались к таблицам напрямую.

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

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

Этот подход, по-видимому, дает много преимуществ, особенно с точки зрения удобства обслуживания. Например:

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

• Проще реализовать производные атрибуты (проще, чем использование вычисляемых столбцов).

• Вы можете эффективно использовать псевдонимы для имен столбцов.

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

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

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

Кто-нибудь знает другие, более сильные недостатки?

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

Будем весьма благодарны за любые комментарии (особенно если вы поделитесь реальным опытом).

Спасибо!

---

P.S. Я наступил на следующую старую статью, в которой обсуждается идея «упаковочных» представлений:

Миф о большом взгляде

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

Статья действительно старая (1999 г.), поэтому, если бы причины были хорошими, то теперь они могут быть не очень хорошими (и наоборот). Было бы действительно интересно услышать от кого-то, кто рассматривал или даже попробовал эту идею недавно, с последними версиями SQL Server и MS Access ...

Answer 1

При проектировании базы данных я предпочитаю следующее:

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

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

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

Answer 2

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

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

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

Проще реализовать производные атрибуты (проще, чем использование вычисляемых столбцов).

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

Вы можете эффективно использовать псевдонимы для имен столбцов.

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

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

Answer 3

Я согласен с комментарием Стивена - главным образом потому, что вы используете Access. При перепроектировании этой базы данных крайне важно держать в центре внимания плюсы и минусы Access. Я был там, сделал это с помощью интерфейса Access / SQL Server (хотя это не был проект ADP).

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