SQL Server: я должен использовать таблицы information_schema над таблицами sys? - PullRequest
Новая
       18

SQL Server: я должен использовать таблицы information_schema над таблицами sys?

48 голосов
/ 06 сентября 2010

В SQL Server есть две схемы для метаданных:

  • INFORMATION_SCHEMA
  • SYS

Я слышал, что INFORMATION_SCHEMA таблицы основаны наСтандарт ANSI.При разработке, например, хранимых процедур, целесообразно ли использовать INFORMATION_SCHEMA таблицы над sys таблицами?

Ответы [ 4 ]

32 голосов
/ 07 сентября 2010

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

Представления Information_Schema показывают только объекты, совместимые со стандартом SQL-92. Это означает, что отсутствует представление информационной схемы даже для самых базовых конструкций, таких как индексы (они не определены в стандарте и оставлены в качестве подробностей реализации.) Не говоря уже о любых проприетарных функциях SQL Server.

Кроме того, это не совсем панацея от переносимости, которую можно предположить. Реализации все еще различаются между системами. Oracle вообще не реализует его «из коробки», и документы MySql говорят:

Пользователи SQL Server 2000 (который также следует стандарту) могут заметить сильное сходство. Тем не менее, MySQL пропустил много столбцов, которые не имеет отношения к нашей реализации, и добавлены столбцы, которые MySQL-специфичны. Одним из таких столбцов является столбец ДВИГАТЕЛЬ в Таблица INFORMATION_SCHEMA.TABLES.

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

например. См. Вопрос Замедление SQL-запроса с 1 секунды до 11 минут - почему? и планы выполнения.

INFORMATION_SCHEMA

Plan

SYS

Plan

31 голосов
/ 06 сентября 2010

Я бы всегда пытался использовать Information_schema представления для непосредственного запроса схемы sys.

Представления совместимы с ISO, поэтому теоретически вы сможете легко переносить любые запросы в разные СУБД.

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

Я предоставил некоторые ссылки с дополнительной информацией о представлениях и запросах к каталогу SQL Server.

http://msdn.microsoft.com/en-us/library/ms186778.aspx

http://msdn.microsoft.com/en-us/library/ms189082.aspx

10 голосов
/ 07 сентября 2010

INFORMATION_SCHEMA больше подходит для внешнего кода, который может потребоваться для взаимодействия с различными базами данных. Как только вы начинаете программировать в базе данных, переносимость как бы исчезает из окна. Если вы пишете хранимые процедуры, это говорит о том, что вы посвятили себя определенной платформе базы данных (к лучшему или к худшему). Если вы завершили работу с SQL Server, то непременно используйте sys views.

1 голос
/ 22 апреля 2016

Я не буду повторять некоторые другие ответы, но добавлю перспективу производительности. Представления information_schema, как Мартин Смит упоминает в своем ответе, не являются наиболее эффективным источником этой информации, поскольку они должны предоставлять стандартные столбцы, которые необходимо собирать из нескольких базовых источников. Представления sys могут быть более эффективными с этой точки зрения, поэтому, если у вас высокие требования к производительности и вам не нужно беспокоиться о переносимости, вам, вероятно, следует использовать представления sys.

Например, в первом запросе ниже используются information_schema.tables для проверки существования таблицы. Второй использует sys.tables для того же. 

if exists (select * from information_schema.tables where table_schema = 'dbo' and table_name = 'MyTable')
    print '75% cost';

if exists (select * from sys.tables where object_id = object_id('dbo.MyTable'))
    print '25% cost';

Когда вы просматриваете IO для них, первый запрос имеет 4 логических чтения к sysschobjs и sysclsobjs, а второй - нет. Кроме того, первый выполняет два поиска по некластерному индексу и поиск по ключу, а второй - только поиск по одному кластерному индексу. Первый из них стоит примерно в 3 раза больше, чем второй, согласно планам запросов. Если вам приходится делать это много раз в большой системе, например, для времени развертывания, это может привести к проблемам с производительностью. Но это действительно относится только к сильно загруженным системам. Большинство ИТ-систем бизнес-систем не имеют таких проблем с производительностью.

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

...