Является ли вложенный вид хорошим дизайном базы данных?

Я читал где-то давно. В книге говорится, что мы не должны допускать наличие вложенного представления в SQL Server. Я не уверен, почему мы не можем этого сделать или я могу вспомнить неправильное утверждение.

Студенты

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

Учителя

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

Школы

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

На моем рабочем месте я исследовал одно из наших внутренних приложений базы данных. Я проверил обнаруженные объекты, что есть два или три слоя представления друг друга. Так что это напоминало мне о том, что я читал в прошлом. Может ли кто-нибудь объяснить это?

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

Дополнительная информация: Я обновил пример из своей компании. Я немного изменюсь, чтобы быть более общим без слишком большого количества технических (слишком много столбцов в этом примере). В основном вложенное представление, которое мы использовали, основано на абстрактном или агрегированном представлении. Например, у нас есть большая таблица студентов со сто колонок. Скажем, Eligible Student View основан на студентах, которые регистрируются в этом году. И представление, подходящее для учащихся, может использоваться в других местах, например, в хранимой процедуре.

36 голосов | спросил Richard Sayakanit 7 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 07 Sep 2011 21:28:24 +0400 2011, 21:28:24

4 ответа


40

Независимо от платформы, применяются следующие замечания.

(-) Вложенные представления:

  • сложнее понять и отладить

    например. В какой столбец столбца указан этот столбец вида? Lemme dig through 4 уровня определения определений ...

  • затруднить оптимизатору запросов наиболее эффективный план запросов

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

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

(+) С другой стороны, вложенные представления позволяют вам:

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

Я обнаружил, что они редко нужны.


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

  • Держите: сохраняя вложенные представления, вы несете преимущества и недостатки, перечисленные выше.

  • Удалить: удаление вложенных представлений:

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

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

ответил Nick Chammas 7 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 07 Sep 2011 21:46:40 +0400 2011, 21:46:40
20

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

Если все это всего лишь вложенные представления, в которых вы делаете select *, но изменяя порядок или вершину, кажется, что это было бы лучше инкапсулировано как хранимая процедура с параметрами (или встроенными функциями, ориентированными на таблицу), чем пучок вложенных Просмотры. ИМХО.

ответил Aaron Bertrand 7 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 07 Sep 2011 21:38:03 +0400 2011, 21:38:03
6

Более поздние версии SQL (2005+) кажутся более эффективными при оптимизации использования представлений. Представления лучше всего подходят для консолидации бизнес-правил. EG: где я работаю, у нас есть база данных о телекоммуникационных продуктах. Каждый продукт присваивается тарифному плану, и этот тарифный план может быть заменен, а ставки на тарифном плане могут активироваться /деактивироваться по мере увеличения или изменения ставок.

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

Я согласен с тем, что представления могут сделать отладку грязной, если вы одновременно создаете запросы и представления. Но, если вы используете проверенное представление n-trusted, это облегчает отладку. Вы знаете, что этот вид уже прошел через звонок, поэтому вы знаете, что это скорее всего не вызывает проблемы.

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

Хорошая вещь об этом - это взгляды, позволяющие вам сильно сконфигурировать запросы на отчеты, выставление счетов и т. д. У вас может быть вид учетной записи клиента, а затем вид на уровне 2 только активных клиентов. Команда, которая с учетом адреса клиента. Команда, которая с точки зрения продукта (ов) (присоединяется к тому, у какого продукта (-ов) есть). Команда, которая для просмотра продукта (ы) тарифного плана. Команда, которая с учетом особенностей продукта. Просмотр, просмотр, просмотр, каждый пробный-n-errored для обеспечения целостности. Ваш конечный запрос с использованием представлений очень компактен.

изменить:

В качестве примера того, как представление было бы лучше, чем просто плоский запрос таблиц ... у нас был временный подрядчик, чтобы внести некоторые изменения. Они сказали ему, что есть какие-то взгляды, но он решил сгладить все его вопросы. Биллинг запускал некоторые из его запросов. Они продолжали получать несколько тарифных планов и ставок на вещи. Оказывается, в его запросах отсутствовали критерии, позволяющие оплачивать счета только в том случае, если они были между началом & что тарифный план должен был использовать те /эти ставки во время. К сожалению. Если бы он использовал представление, он бы уже учёл эту логику.

В принципе, вам нужно взвесить производительность и здравомыслие. Возможно, вы можете делать всевозможные причудливые вещи, чтобы повысить производительность базы данных. Но, если это означает, что это кошмар для нового человека, который должен взять на себя /поддерживать, действительно ли это стоит? Действительно ли это стоит того, чтобы новый парень играл в битку, чтобы найти все запросы, которые должны были изменить их логику (и рискнуть его забыть /перебрать пальцы). B /c кто-то решил, что мнения «плохие» и не объединили некоторые основные бизнес-логики в один, который мог бы использоваться в 100 других запросов? Это действительно зависит от вашего бизнеса и вашей команды IT /IS /DB. Но я бы предпочел четкость и единоначальную консолидацию по производительности.

ответил blah blah 5 MaramWed, 05 Mar 2014 01:13:15 +04002014-03-05T01:13:15+04:0001 2014, 01:13:15
3

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

ответил Ray 17 Maypm16 2016, 18:32:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132