SQL trojúhelník

Cheat sheet pro účastníky se SQL Server backgroundem. Pomáhá orientovat se mezi třemi typy SQL endpointů ve Fabricu a srozumí, kde je hranice s klasickým SQL Serverem.

Vizuální shrnutí

                 ┌─── SQL Database ───┐
                 │  Pro OLTP / aplikace│
                 │  Plný T-SQL         │
                 │  Row-store + col.   │
                 └─────────────────────┘
                          ↓
                  pipelines / mirror
                          ↓
                  ┌────────────────┐
                  │   OneLake      │
                  │   (Delta)      │
                  └─┬──────────────┬┘
                    │              │
        ┌───────────┘              └───────────┐
        ↓                                       ↓
┌───────────────────┐               ┌──────────────────┐
│ Lakehouse SQL EP  │               │   Warehouse      │
│ Read-only T-SQL   │               │  OLAP DWH         │
│ Auto-managed      │               │  T-SQL DML        │
│ Jakýkoliv Delta   │               │  Procedures       │
└───────────────────┘               └──────────────────┘
        ↓                                       ↓
   Power BI Direct Lake / Excel / SSMS / ADS

V SQL Serveru řešili Linked Servers. V Fabric Warehouse:

Three-part naming

-- Z Warehouse "DW_Sales" dotaz na Warehouse "DW_Master" ve stejném workspace
SELECT s.OrderID, m.CustomerName
FROM dbo.SalesOrders s
JOIN [DW_Master].dbo.Customers m ON m.CustomerID = s.CustomerID;

Funguje: Warehouse → Warehouse, Lakehouse SQL EP → Lakehouse SQL EP, i mezi nimi navzájem (od 2024).

Shortcuts pro cross-workspace, cross-cloud

Lakehouse → New shortcut → OneLake / ADLS Gen2 / S3 / GCS
→ Pointer na external storage, žádná kopie dat
→ Tabulka se objeví v Tables/ jako kdyby byla lokální
→ Stejné SQL queries fungují

Příklad: firma má hlavní data v centrální workspace (HQ), divizní teams si přes Shortcuts vytvoří read pointer. Žádná duplicita, žádná latence sync, ovládání access přes workspace permissions.

Nejdůležitější sekce dokumentu. Pokud někdo vyleze z kurzu jen s tímto, vím že to bylo užitečné.

Co chybí / je jiné

4.1 Žádné clustered rowstore indexy

Warehouse má jen sloupcové indexy auto-managed. Není CREATE CLUSTERED INDEX. Optimalizace je v partitioning + V-Order, ne v indexech.

-- TOTO NEFUNGUJE
CREATE CLUSTERED INDEX IX_Sales ON FactSales (OrderDate);  -- Error

-- Místo toho: partitioning při tvorbě (auto), V-Order
-- Engine si rozhoduje sám.

4.2 Temp tabulky: jen session-scoped #temp

Session-scoped #temp tabulky Warehouse podporuje (od 2025); globální ##temp ne a mají svá omezení (viz dokumentace Temp tables). Pro většinu ETL v procedurách je i tak čistší CTE nebo staging schema:

-- Session-scoped #temp funguje (globalni ##temp ne):
CREATE TABLE #StagingData (id INT, val VARCHAR(50));

-- Alternativy:
-- a) CTE (preferred pro single-query)
WITH StagingData AS (
    SELECT id, val FROM source WHERE ...
)
SELECT * FROM StagingData JOIN dim ON ...;

-- b) Persistent tabulka v dedicated schema
CREATE SCHEMA staging;
CREATE TABLE staging.tmp_orders (...);
-- ... use ...
DROP TABLE staging.tmp_orders;

-- c) Inline derived table
SELECT *
FROM (SELECT id, val FROM source WHERE ...) AS s
JOIN dim ON ...;

4.3 Stored procedures — co funguje a co ne

Anti-pattern:

-- Funguje, ale CURSOR je v MPP enginu pomalý.
-- Místo toho přepiš na set-based:
DECLARE c CURSOR FOR ...;
OPEN c;
FETCH NEXT FROM c ...;
WHILE @@FETCH_STATUS = 0 ...

4.4 Žádný SQL Agent / SSIS

Place pro orchestraci je Pipeline (Data Factory pipelines v Fabricu).

4.5 Žádný Linked Server, žádný OPENROWSET na external

Místo Linked Server → Three-part naming (viz §3).

Místo OPENROWSET pro CSV → COPY INTO statement:

-- SQL Server style (NEFUNGUJE ve Warehouse):
SELECT * FROM OPENROWSET(BULK 'C:\data\file.csv', SINGLE_CLOB) AS T;

-- Fabric Warehouse:
COPY INTO dbo.staging
FROM 'https://onelake.dfs.fabric.microsoft.com/<workspace>/<lakehouse>/Files/file.csv'
WITH (FILE_TYPE = 'CSV', FIELDTERMINATOR = ',');

4.6 T-SQL dialekt odchylky (vybrané)

-- Fabric Warehouse: PK NOT ENFORCED
CREATE TABLE dbo.dim_kraj (
    kraj_id INT NOT NULL PRIMARY KEY NOT ENFORCED,
    kraj_nazev VARCHAR(50)
);

-- Tohle PROJDE bez chyby:
INSERT INTO dbo.dim_kraj VALUES (1, 'Praha');
INSERT INTO dbo.dim_kraj VALUES (1, 'Druhá Praha');  -- duplicita PK = OK

Pattern pro vynucení:

-- Idempotent insert s anti-join
INSERT INTO dbo.dim_kraj (kraj_id, kraj_nazev)
SELECT s.kraj_id, s.kraj_nazev
FROM staging.dim_kraj_new s
LEFT JOIN dbo.dim_kraj t ON t.kraj_id = s.kraj_id
WHERE t.kraj_id IS NULL;

4.7 Žádné variables typu BLOB / FILESTREAM

VARBINARY(MAX) funguje, ale FILESTREAM ne. Pro velké binární data (obrázky, PDFs) → ulož do Lakehouse Files, v tabulce drž jen path.

4.8 Tempdb — implicitní, neviditelný

V SQL Serveru ladíte tempdb manualně (multiple files, location). Ve Fabricu to engine řeší automaticky. Nevidíte jeho existenci v UI. Nelze hintovat. Důsledek: některé tuning techniky (např. forcing parallelism, query hints) prostě nejsou.

Co umí

-- Vše čtecí: SELECT, JOINs, window funkce, aggregace
SELECT YEAR(date) AS rok, COUNT(*) AS pocet
FROM nehody_silver
GROUP BY YEAR(date)
ORDER BY rok DESC;

-- Views
CREATE VIEW v_nehody_summary AS
    SELECT rok, kraj_nazev, COUNT(*) AS pocet
    FROM nehody_silver
    GROUP BY rok, kraj_nazev;

-- Stored procedures (read-only)
CREATE PROCEDURE sp_kraj_summary @rok INT
AS
    SELECT kraj_nazev, COUNT(*) AS pocet
    FROM nehody_silver
    WHERE rok = @rok
    GROUP BY kraj_nazev;

Co neumí

-- Žádný write
INSERT INTO nehody_silver ... ;        -- Error
UPDATE nehody_silver SET ... ;         -- Error
DELETE FROM nehody_silver WHERE ... ;  -- Error
CREATE TABLE ...;                       -- Error
TRUNCATE TABLE ...;                     -- Error

Pro write do Lakehouse: notebook (Spark / Python), Dataflow Gen2, Pipeline. SQL endpoint je striktně read-only fasáda.

Pattern A: SQL Database jako landing pro app data

Aplikace → SQL Database → Mirroring → OneLake → Power BI

Mirroring (od 2024) replikuje SQL DB do OneLake near real-time bez CU spotřeby. App neví o Fabricu, BI tým má fresh data.

Pattern B: Lakehouse + Warehouse hybrid

CSVs / sources → Lakehouse Files (Bronze)
                    ↓ Spark/PQ
                Lakehouse Tables (Silver)
                    ↓ T-SQL procedures
                Warehouse (Gold)
                    ↓
                Power BI Direct Lake

Bronze v Lakehouse (cheap, raw, schema-on-read). Silver v Lakehouse (Delta, schema-on-write). Gold ve Warehouse (T-SQL friendly, OLAP optimization).

Pattern C: Pure Warehouse pro SQL-only tým

SQL sources (mirror nebo COPY INTO) → Warehouse Bronze schema
                                        ↓ stored procedures
                                      Warehouse Silver schema
                                        ↓ stored procedures
                                      Warehouse Gold schema
                                        ↓
                                      Power BI

Tohle je nejnižší overhead pro SQL Server team — celá stack v T-SQL. Tradeoff: některé operace (např. JSON parsing, semi-structured) budou pomalejší než v Spark.

Když firma zvažuje "přesun DWH do Fabricu", projdi:

• ☐ Inventory stored procedur: kolik, co používají (linked servers, openrowset, xp_cmdshell)
• ☐ Inventory SQL Agent jobů → mapování na Pipelines
• ☐ Inventory SSIS packages → mapování na Pipelines (nebo migrate tool)
• ☐ Inventory CHECK constraints → přepsat na validation v procedure / pipeline
• ☐ Inventory ##temp (globálních) tabulek → přepsat na session #temp, CTE nebo persist staging
• ☐ Inventory TRIGGERS → přepsat na pipeline / change feed pattern (Fabric nemá)
• ☐ Inventory DBMail / SQL Mail → Office 365 connector v pipeline
• ☐ Indexy: zkontrolovat, kolik clustered rowstore vs nonclustered → ve Fabricu se vším rozhodne engine
• ☐ Partitioning existing tables — zda velikost a partition strategie sedne na V-Order

• Warehouse T-SQL surface: https://learn.microsoft.com/fabric/data-warehouse/tsql-surface-area
• Warehouse limitations: https://learn.microsoft.com/fabric/data-warehouse/limitations
• Lakehouse SQL Endpoint: https://learn.microsoft.com/fabric/data-engineering/lakehouse-sql-analytics-endpoint
• SQL Database in Fabric: https://learn.microsoft.com/fabric/database/sql/overview
• Mirroring: https://learn.microsoft.com/fabric/database/mirrored-database/overview
• Cross-database queries: Query the Warehouse (vč. cross-database)