Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

Как SCHEMA_ID() работи в SQL Server

В SQL Server можете да използвате SCHEMA_ID() функция за връщане на идентификатора на дадена схема. По-конкретно, тази функция връща идентификатора на схемата, свързан с име на схема.

Това е като SCHEMA_NAME() освен че връща ID на схемата вместо името (и приема параметъра name вместо ID).

Ако не предадете име на схема на функцията, тя връща идентификатора на схемата по подразбиране на повикващия.

Пример 1 – Връщане на схема по подразбиране

Ето пример, който връща идентификатора на схемата по подразбиране на обаждащия се.

SELECT SCHEMA_ID() AS Result;

Резултат:

+----------+
| Result   |
|----------|
| 1        |
+----------+

Това връща идентификатора на схемата по подразбиране на обаждащия се, защото не съм посочил изрично друго име на схема.

Ето го отново, заедно с името на схемата.

SELECT 
  SCHEMA_ID() AS [Schema ID],
  SCHEMA_NAME() AS [Schema Name];

Резултат:

+-------------+---------------+
| Schema ID   | Schema Name   |
|-------------+---------------|
| 1           | dbo           |
+-------------+---------------+

Пример 2 – Посочете различна схема

В този пример аз изрично предавам име на схема на функцията.

SELECT SCHEMA_ID('Dimension') AS Result;

Резултат:

+----------+
| Result   |
|----------|
| 6        |
+----------+

Това ми казва, че схемата, наречена Dimension, има идентификатор 6.

Пример 3 – Превключване на бази данни

Предишният пример просто се изпълняваше в база данни, която имаше схема, наречена Dimension. Ако премина към друга база данни, може да получа различен идентификатор на схемата или изобщо да нямам идентификатор.

Ето пример за това, което имам предвид.

USE WideWorldImportersDW;
SELECT SCHEMA_ID('Dimension') AS Result;

USE Music;
SELECT SCHEMA_ID('Dimension') AS Result;

Резултат:

Changed database context to 'WideWorldImportersDW'.
+----------+
| Result   |
|----------|
| 6        |
+----------+
(1 row affected)
Changed database context to 'Music'.
+----------+
| Result   |
|----------|
| NULL     |
+----------+
(1 row affected)

Вторият резултат връща NULL защото в базата данни за музика няма схема, наречена Dimension.

Пример 4 – В клауза WHERE

Използване на SCHEMA_ID() в WHERE клаузата може да бъде удобен начин за филтриране на резултатите по схема.

В SQL Server различни системни изгледи използват schema_id колона за съхраняване на идентификатора на схемата, но не и името на схемата. Следователно трябва да знаете идентификатора на схемата, ако ще филтрирате резултатите по схема. Това е мястото, където SCHEMA_ID() може да бъде много полезно. Това ви спестява от необходимостта да правите присъединяване към sys.schemas преглед само за да изработите името на схемата.

Ето пример за използване на SCHEMA_ID() в WHERE клауза.

USE WideWorldImportersDW;
SELECT 
  name,
  type_desc 
FROM sys.objects
WHERE schema_id = SCHEMA_ID('Dimension');

Резултат:

Changed database context to 'WideWorldImportersDW'.
+----------------------------------------------------+------------------------+
| name                                               | type_desc              |
|----------------------------------------------------+------------------------|
| City                                               | USER_TABLE             |
| PK_Dimension_City                                  | PRIMARY_KEY_CONSTRAINT |
| DF_Dimension_City_City_Key                         | DEFAULT_CONSTRAINT     |
| Customer                                           | USER_TABLE             |
| PK_Dimension_Customer                              | PRIMARY_KEY_CONSTRAINT |
| DF_Dimension_Customer_Customer_Key                 | DEFAULT_CONSTRAINT     |
| Date                                               | USER_TABLE             |
| PK_Dimension_Date                                  | PRIMARY_KEY_CONSTRAINT |
| Employee                                           | USER_TABLE             |
| PK_Dimension_Employee                              | PRIMARY_KEY_CONSTRAINT |
| DF_Dimension_Employee_Employee_Key                 | DEFAULT_CONSTRAINT     |
| Payment Method                                     | USER_TABLE             |
| PK_Dimension_Payment_Method                        | PRIMARY_KEY_CONSTRAINT |
| DF_Dimension_Payment_Method_Payment_Method_Key     | DEFAULT_CONSTRAINT     |
| Stock Item                                         | USER_TABLE             |
| PK_Dimension_Stock_Item                            | PRIMARY_KEY_CONSTRAINT |
| DF_Dimension_Stock_Item_Stock_Item_Key             | DEFAULT_CONSTRAINT     |
| Supplier                                           | USER_TABLE             |
| PK_Dimension_Supplier                              | PRIMARY_KEY_CONSTRAINT |
| DF_Dimension_Supplier_Supplier_Key                 | DEFAULT_CONSTRAINT     |
| Transaction Type                                   | USER_TABLE             |
| PK_Dimension_Transaction_Type                      | PRIMARY_KEY_CONSTRAINT |
| DF_Dimension_Transaction_Type_Transaction_Type_Key | DEFAULT_CONSTRAINT     |
+----------------------------------------------------+------------------------+
(23 rows affected)

  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Измервате ли производителността на SQL Server с тези показатели?

  2. Как да проверите дали изчислената колона е „постоянна“ в SQL Server

  3. Най-бързият начин за намиране на остарели функции, които все още се използват в екземпляр на SQL сървър (пример за T-SQL)

  4. SQL Server (localdb)\v11.0 е обяснено

  5. Какво трябва да знаете за С NOCHECK, когато активирате ограничение CHECK в SQL Server