SQL Server Express-Äquivalent für EXTERNAL DATA SOURCE

Question

Gemäß https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-query-getting-started-vertical/ ist es jetzt möglich, dass eine Datenbank in Azure SQL andere Azure SQL-Datenbanken abfragt. Für meinen Anwendungsfall beabsichtige ich, eine Datenbank zu haben, die Referenzdaten für andere Datenbanken bereitstellt, die gut zu Topologie 1 (vertikales Sharding) passt.

Dies ist ideal für eine bereitgestellte Umgebung, aber für die lokale Entwicklung entwickle ich normalerweise mit SQL Server Express. Ab SQL Server 2012 Express ist CREATE EXTERNAL DATA SOURCE keine gültige Syntax.

Ist es auch möglich, den Vorteil externer Datenquellen für die lokale Entwicklung zu nutzen?

Answer 1

Wenn wir über SQL Server sprechen, werden externe Datenquellen/Tabellen/Dateiformate beginnend mit SQL Server 2016 - https://msdn.microsoft.com/en-us/library/dn935022.aspx unterstützt.

Answer 2

Nach dem Abwägen der Feature-Sets entschied ich mich, die Einrichtung meiner lokalen Datenbank und Azure SQL zu unterscheiden.

• Wenn lokale SQL-Server-Datenbank will eine Azure SQL-Datenbank verweisen, kann es tun, so Linked Server mit
• Wenn ein Kerl Azure SQL-Datenbank eines andere Azure SQL-Datenbank verweisen will, nur dann über die externe Datenquelle

dh lokal

-- Make a link to the cloud 
EXEC sp_addlinkedserver 
    @server=N'MyExternalServer', 
    @srvproduct=N'Azure SQL Db', 
    @provider=N'SQLNCLI', 
    @datasrc=N'<server address>', 
    @catalog='<database name>'; 
GO 

EXEC sp_addlinkedsrvlogin 
    @rmtsrvname = '<server address>', 
    @useself = 'FALSE', 
    @locallogin=NULL, 
    @rmtuser = '<username>', 
    @rmtpassword = '<password>' 
GO 

select * from [MyExternalServer].[<database name>].[<schema>].[<table name>] 

Während für Azure SQL:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'; 
CREATE DATABASE SCOPED CREDENTIAL ElasticDBQueryCred 
WITH IDENTITY = '<username>', 
SECRET = '<password>'; 

CREATE EXTERNAL DATA SOURCE MyElasticDBQueryDataSrc WITH 
    (TYPE = RDBMS, 
    LOCATION = '<server>', 
    DATABASE_NAME = '<database name>', 
    CREDENTIAL = ElasticDBQueryCred, 
) ; 


create schema <internalschema> 

CREATE EXTERNAL TABLE <internalschema>.<internaltablename> 
(
    ... // list of columns 
WITH 
(DATA_SOURCE = MyElasticDBQueryDataSrc, 
SCHEMA_NAME = <schema>, 
OBJECT_NAME = <table name> 
) 

select * from <internalschema>.<internaltablename> 

Die Herausforderung besteht nun darin, die Datenbankskripte mit beiden Methoden gemeinsam zu machen. Um eine Tabelle unter Verwendung von Verbindungsserver zu referenzieren, muss sie unter Verwendung der vierteiligen Kennung [server].[database].[schema].[tablename] adressiert werden. Vergleichen Sie dies mit einer externen Datenquelle, in der es nur unter Verwendung von [schema].[tablename] adressiert werden kann.

Ausgehend von dieser Frage: https://dba.stackexchange.com/questions/74566/sql-server-using-4-part-identifiers-when-database-may-be-on-the-same-server, ist mein Ansatz, ein Synonym für meine lokale Datenbank zu erstellen, die [schema].[tablename] zu [externalserver].[externaldatabase].[externalschema].[tablename] umleitet.

dh lokal:

create schema <internalschema> 
CREATE SYNONYM <internalschema>.<internaltablename> FOR [MyExternalServer].[<database name>].[<schema>].[<table name>] 

Nach dem, die gleiche Aussage für beide Fälle funktionieren würde:

select * from <internalschema>.<internaltablename> 

EDIT: Ein großes Problem bei diesem Ansatz ist, dass Sie nicht Ihr Skript wickeln können unter verteilter Transaktion, da Azure SQL DTC nicht zulässt.