Empezar con SQL Database en Microsoft Fabric

¿Qué te enseña este módulo?

Este módulo cubre SQL Database en Fabric, un producto transaccional (OLTP) que complementa al Warehouse (que es OLAP). Los objetivos oficiales:

1. Explicar cómo funciona SQL Database en Fabric.
2. Entender las opciones de seguridad en SQL Database.
3. Explicar cómo usar Copilot para mejorar el troubleshooting.
4. Explorar las capacidades de mirroring y data virtualization.

Peso en el examen DP-700

🌸 ¿Por qué existe este producto?

Diferencia con el SQL analytics endpoint del Lakehouse/Warehouse:

• Warehouse y Lakehouse son para analytics (OLAP).
• SQL Database es para cargas transaccionales (OLTP): apps que necesitan INSERT/UPDATE/DELETE frecuentes con baja latencia.
• Antes tenías que salir de Fabric a Azure SQL. Ahora tienes OLTP nativo en Fabric.

Aviso: si vienes de SQL Server o Azure SQL, ya sabes el 90% de este módulo. La sintaxis y el engine son los mismos 💕

Definición

SQL Database en Microsoft Fabric es una transactional database versátil y developer-friendly construida sobre la base de Azure SQL Database. Permite la creación y gestión de operational databases dentro del entorno Fabric.

Diferencias clave con Azure SQL Database

• ✅ SaaS (no PaaS como Azure SQL Database).
• ✅ Low-maintenance (Fabric gestiona todo).
• ✅ Auto-mirroring a OneLake en near real-time.
• ✅ Integrado con el ecosistema Fabric.
• ✅ Copilot nativo.
• ✅ Autonomous features activadas por defecto.

Basado en el mismo engine SQL

Como está construido sobre Azure SQL Database, tiene el mismo SQL engine que ya conoces: complex queries, advanced data manipulations y un amplio rango de security features a nivel de base de datos. Si ya sabes T-SQL, ya sabes trabajar con esto.

¿Qué significa cada uno?

PaaS (Platform as a Service) — como Azure SQL Database tradicional:

• Microsoft gestiona la infraestructura.
• Tú gestionas la BBDD: configuration, tuning, scaling.
• Más control pero más responsabilidad.

SaaS (Software as a Service) — como Fabric SQL Database:

• Microsoft gestiona TODO: infraestructura + gestión de la BBDD.
• Tú solo te preocupas del schema, las queries y la aplicación.
• Menos control pero casi zero maintenance.

Comparativa práctica

Beneficio para el usuario

Menos maintenance = más foco en business logic. Ideal para equipos que no quieren dedicar DBAs, startups o proyectos rápidos, citizen developers y apps que necesitan OLTP dentro del ecosistema Fabric.

Este es EL punto más examinable del módulo. Vamos a fondo.

OLTP vs OLAP

OLTP (Online Transaction Processing):

• Workload transaccional: INSERT, UPDATE, DELETE frecuentes.
• Rows individuales o small batches.
• Baja latencia (milisegundos).
• Ejemplos: apps de banca, ecommerce, CRM operations, ERPs.

OLAP (Online Analytical Processing):

• Workload analítico: SELECT complejos con aggregations.
• Grandes volúmenes procesados en cada query.
• Latencia moderada (segundos-minutos aceptables).
• Ejemplos: reports, dashboards, BI queries, analytics.

Los 3 items SQL de Fabric

Comparativa completa

Pueden coexistir

Muy común: SQL Database para la app transaccional (bookings, orders), con auto-mirroring a OneLake; Warehouse para analytics históricos; y Lakehouse para ML training data. Todo en el mismo workspace, sin ETL manual.

Prerequisites

• Fabric capacity (F SKU o Trial).
• Workspace existente o nuevo.
• Rol Admin o Member en el workspace.

Pasos

1. En el Fabric portal, seleccionar Databases.
2. Bajo New, seleccionar el tile SQL database.
3. Dar un nombre a la New Database.
4. Seleccionar Create — el provisioning tarda menos de 1 minuto.

Home page de la nueva DB

Después del provisioning, ves:

• Explorer pane: muestra los database objects (tables, views, procs, etc.).
• Build your database con 3 tiles útiles:
  • Sample data: importar el sample AdventureWorksLT.
  • T-SQL: web-editor para escribir T-SQL.
  • Connection strings: información de conexión para tools externos.

Sample data

Puedes cargar el sample SalesLT / AdventureWorksLT con un click. Ideal para aprender, testing y los ejercicios del propio Learn. Después de importar → schema SalesLT con sus tablas asociadas.

Formas de cargar datos

A) Sample data button (para pruebas rápidas): un click, carga AdventureWorksLT.

B) T-SQL directo: INSERT INTO ... VALUES (...), ejecutado desde el web editor o tools externos.

C) Dataflows Gen2: como destination, ETL low-code.

D) Pipelines: actividad Copy Data con SQL Database como destination.

E) External tools con TDS: SQL Server Management Studio (SSMS), Azure Data Studio, VS Code con la extensión MSSQL o cualquier tool que soporte el Tabular Data Stream protocol.

Conectar desde external tools

Connection string desde el menú Connection strings:

Server=<fabric-server>.database.fabric.microsoft.com,1433;
Database=<database-name>;
Authentication=Active Directory Interactive;

Autenticación: Microsoft Entra Interactive (browser-based), Microsoft Entra MFA, Microsoft Entra Password y Service Principal.

Conectar desde SSMS

1. Server type: Database Engine.
2. Server name: <server>.database.fabric.microsoft.com,1433.
3. Authentication: Microsoft Entra MFA (recomendado).
4. Database Name: nombre de tu DB.
5. Connect.

Después de conectar puedes navegar en el Object Explorer, crear tablas con CREATE TABLE, insertar rows y consultar como en cualquier SQL Server.

Web editor en el portal

Fabric provee un editor T-SQL web-based integrado, con IntelliSense, syntax highlighting, Copilot integrado y result viewer (Text, Grid, File).

Open in

Botón Open in que lanza tools externos con las connection properties ya rellenadas: Visual Studio Code y SQL Server Management Studio. Facilita empezar a trabajar inmediatamente en tu tool preferido.

Query tools soportados

Cualquier tool que soporte el protocolo TDS (Tabular Data Stream): SSMS, Azure Data Studio, VS Code + MSSQL extension, SQLCMD, apps .NET con SqlClient, Python con pyodbc, Node.js con mssql, etc.

Templates en el web editor

En el tile T-SQL hay un Templates dropdown con snippets para CREATE TABLE, CREATE VIEW, queries comunes, templates de stored procedures y más. Muy útil para aprender sintaxis o empezar rápido.

Feature

El source control es esencial para gestionar SQL databases en Fabric. Permite:

• ✅ Trackear cambios.
• ✅ Colaborar con el equipo.
• ✅ Mantener el histórico de modificaciones.
• ✅ Revertir cambios si lo necesitas.

Cómo funciona

Workflow familiar para quien ya use source control:

A) Commit to source control: puedes commitear database objects a source control. Convierte la live database en código: lee las object definitions desde la DB y las escribe al repositorio.

B) Update from source control: actualiza los database objects desde el contenido del source control. El código se valida antes de aplicar el cambio diferencial a la DB.

C) History tracking: los usuarios pueden ver el histórico de los database objects, con un registro claro de cambios que facilita la colaboración.

Diferencia con Warehouse

El source control de SQL Database es más maduro y granular que en otros items: enfocado en schema objects (tables, views, procs, functions), con histórico completo de cambios DDL. Perfecto para schema management en dev/test/prod.

Sistemas soportados

• Azure DevOps (Git repos).
• GitHub.

¿Qué es?

El Performance Dashboard de Fabric SQL Database simplifica la experiencia de usuario eliminando las complejidades de monitorización y operación. Permite aprovechar plenamente las capacidades del SQL database engine, cubriendo distintos workloads.

Niveles de visibility

Ofrece distintos niveles de visibilidad de métricas para acomodar a usuarios con diferente expertise en SQL: principiantes con métricas básicas de query performance, e intermedios/avanzados con información más detallada.

Cómo acceder

Dos formas:

• A) Right-click en la item view → botón de contexto (tres puntos) → Open performance summary.
• B) Query Editor → home toolbar → Performance summary.

Qué muestra

• Query performance metrics.
• Long-running queries.
• Tendencias de uso de recursos.
• Detección de bottlenecks.
• Alertas para issues.

Uso típico

Debug de queries lentas, optimización de workloads, detección temprana de bottlenecks y asegurar una experiencia de usuario intuitiva y eficiente.

¿Qué son?

Automatic tuning es una capability integrada que aplica machine learning para optimizar la performance de tus queries. Automáticamente identifica oportunidades de tuning y las implementa para mejorar la eficiencia de la base de datos. Sin intervención manual. Es la parte "autónoma" del SaaS.

Automatic indexing

En Fabric SQL Database, los índices se gestionan dinámicamente:

• Crea índices que mejoran la query performance.
• Elimina índices que ya no se usan.
• Revierte índices si su creación causó regresiones.

Todo automáticamente, basándose en los patrones de workload observados.

Monitorizar el automatic indexing

En el performance dashboard, tab Automatic index:

• Gráfico mostrando el número de índices creados, eliminados y revertidos a lo largo del tiempo.
• Tabla listando los índices creados por la herramienta: schema name, table name, index name, status, key columns, included columns, creation date y drop date (si aplica).

Beneficio

• 🎯 Mejor query performance sin tuning manual.
• 💰 Menos tiempo de DBA dedicado a indexing.
• 🧠 Decisiones ML-driven, más inteligentes que el tuning humano en muchos casos.
• 🔄 Se adapta continuamente a los cambios de workload.

Cuándo aún necesitas DBA

Diseño de schema, business logic, índices complejos específicos que el ML no considera, indexing por compliance y optimización cross-database. Pero para el día a día, las autonomous features cubren el 80% de los casos.

La seguridad de Fabric SQL Database opera en múltiples niveles, igual que en el Warehouse.

Workspace roles

Primera capa de access control. Los roles familiares:

• Admin: full control.
• Member: gestión sin borrar el workspace.
• Contributor: crear/editar items.
• Viewer: read-only en el workspace.

Asigna a los usuarios el rol apropiado según el nivel de acceso necesario.

Item permissions

Las databases individuales pueden tener item permissions asignadas directamente. La intención principal: facilitar el sharing de la SQL database para uso downstream.

Cómo revisarlas: navegar al item en el workspace y seleccionar la quick action Manage permissions. Puedes ver los permisos de la SQL database, de su SQL analytics endpoint y de su default semantic model.

Las dos capas trabajando juntas

Necesitas AMBAS para acceso completo:

1. Item permissions: para conectarte a la DB.
2. T-SQL security (roles, permissions): para hacer operaciones dentro.

Sin item permission → no conectas. Sin T-SQL permission → conectas pero no puedes hacer nada.

Igual que en el Warehouse, SQL Database soporta seguridad T-SQL granular.

Los 4 mecanismos (repaso)

• A) Object-Level Security (OLS): controla el acceso a database objects específicos (tables, views, procedures). GRANT/DENY a nivel object.
• B) Row-Level Security (RLS): restringe las rows visibles por usuario, con WHERE clause predicates.
• C) Column-Level Security (CLS): restringe las columns visibles, con DENY SELECT ON table (column) TO user.
• D) Dynamic Data Masking (DDM): enmascara data sensible en la visualización. La data no cambia, solo se enmascara al presentarla.

Cómo gestionar desde el portal

Fabric portal → Security → Manage SQL security. Ahí puedes gestionar los database-level roles.

T-SQL directo

-- Create role
CREATE ROLE ReadOnlyRole;

-- Grant permissions al role
GRANT SELECT ON SCHEMA::SalesLT TO ReadOnlyRole;

-- Add member al role
ALTER ROLE ReadOnlyRole ADD MEMBER [user@company.com];

-- Row-level security policy
CREATE FUNCTION security.fn_regionAccess(@region NVARCHAR(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_result
WHERE @region = USER_NAME();

CREATE SECURITY POLICY SalesRegionFilter
ADD FILTER PREDICATE security.fn_regionAccess(Region) ON dbo.Sales
WITH (STATE = ON);

-- Column-level security
DENY SELECT ON dbo.Employee (Salary) TO AnalystRole;

-- Dynamic Data Masking
ALTER TABLE dbo.Customer
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

Aplica también al SQL analytics endpoint

Las security policies aplican independientemente del punto de acceso: conexión SQL directa, SQL analytics endpoint, Power BI, Copilot y notebooks. Esto garantiza una experiencia fluida y segura sin cambios en las aplicaciones existentes.

Integración completa

Microsoft Copilot está integrado con SQL database en Fabric: mejora la gestión y el troubleshooting de SQL, aumenta la productividad y ofrece self-help a los usuarios.

Las 4 features principales

A) Natural Language to SQL ⭐

• Traduce queries en lenguaje natural a SQL dentro del query editor.
• Schema-aware: conoce la estructura de tu DB.
• Interacciones más intuitivas.

Ejemplos que puedes preguntar:

• "Which employees have completed more than two projects this quarter?"
• "List all products that were out of stock last month."
• "Provide the rank of each department by employee satisfaction score."
• "Create a primary key constraint named PK_Product_ProductID to the column ProductID in the table Product."

B) Chat pane 💬: chat interactivo con Copilot para hacer preguntas y generar queries.

C) Code completion ⌨️: sugerencias automáticas mientras escribes T-SQL, como un IntelliSense inteligente.

D) Quick actions: Explain (entender qué hace una query existente) y Fix (corregir errores en queries), como botones en la toolbar del query editor.

Cómo acceder

En el Fabric portal: abre tu SQL database, selecciona el botón Copilot en el ribbon → chat pane. O usa los quick action buttons Explain y Fix en la toolbar del query editor.

Auto-correct de errores T-SQL

Feature poderosa: Copilot puede corregir automáticamente errores de código T-SQL según ocurren. Compartiendo contexto con la active query tab, Copilot ofrece sugerencias útiles para arreglar errores de SQL sin fricción.

Beneficio principal

Copilot mejora el troubleshooting: detecta errores, explica queries complejas, sugiere correcciones y reduce la curva de aprendizaje de T-SQL. Ideal para citizen developers o equipos cross-funcionales.

Esta es la feature MÁS distintiva de SQL Database en Fabric. Súper examinable 💕

La feature en una frase

SQL Database en Fabric se auto-mirrorea a OneLake en near real-time, convirtiendo automáticamente los datos a formato Delta Parquet.

Por qué es tan importante

Elimina la necesidad de procesos ETL complejos para llevar la data OLTP al analytics stack.

Antes (con Azure SQL Database tradicional):

Azure SQL DB → Data Factory pipeline → Storage → Lakehouse
                      (horas de setup + mantenimiento)

Ahora (con Fabric SQL Database):

Fabric SQL DB → [auto-mirror] → OneLake (Delta)
                (transparente, sin setup)

Beneficios

• ⚡ Near real-time replication (segundos-minutos de lag).
• 🚫 No manual ETL requerido.
• 💰 Reduce el Total Cost of Ownership.
• 🎯 Acelera el time-to-insight.
• 🌊 Data siempre disponible en OneLake para analytics.
• 🔗 Desbloquea escenarios de BI, AI, data engineering, data science y data sharing.

Consumers del mirror

Una vez la data está en OneLake, muchos workloads de Fabric pueden consumirla:

• Spark notebooks para analytics batch.
• Power BI con Direct Lake mode.
• Warehouse queries con cross-database queries.
• Lakehouse con shortcuts.
• Data agents (Fabric IQ).
• Notebooks Python con Semantic Link.

Tipos de mirroring en Fabric

Fabric soporta mirroring de múltiples sources:

1. SQL Database en Fabric (esta): automático, siempre activo.
2. Azure SQL Database (external): setup manual del mirror.
3. Azure Cosmos DB: setup manual.
4. Snowflake: setup manual.
5. Otras (la lista sigue creciendo).

Todos siguen el mismo patrón: replicación near real-time a OneLake sin ETL manual.

Monitorizar el estado del mirroring

Cómo: seleccionar Monitor replication desde el tab Replication. Muestra el estado de replicación por tabla, el lag time, los errores si los hay y el volumen replicado.

Si no hay updates en las source tables, el engine hace back off y reanuda el polling regular tras detectar data actualizada.

Auto-generated

Cuando tienes una SQL Database en Fabric, se genera automáticamente un SQL analytics endpoint que apunta a la mirrored data en OneLake.

Uso típico

Ejecutar queries analíticas sobre la mirrored data: sin impactar el workload OLTP de la SQL Database original, con optimizaciones analíticas (el column-store del Delta) y compatible con analytics tools.

Similitud con Lakehouse

Muy parecido al SQL analytics endpoint del Lakehouse: read-only, queries y views T-SQL, puede tener stored procedures y es consumible desde Power BI.

Semantic model automático

También se puede crear (o se genera automáticamente en algunos casos) un default semantic model sobre el SQL analytics endpoint. Ideal para reports de Power BI en Direct Lake.

¿Qué es?

Data virtualization en SQL Database en Fabric = capacidad de acceder y manipular data de distintas sources SIN mover ni copiar la data. Provee una vista unificada de los datos, permitiendo integración y análisis fluidos entre plataformas.

Casos de uso

Consultar directamente tablas Parquet, CSV y Delta disponibles en Lakehouses de Fabric, en OneLake (cualquier folder) o en storage externo con credenciales.

Los 4 building blocks

Para montar data virtualization necesitas 4 componentes T-SQL:

A) Database Scoped Credential — credenciales para acceder a las external data sources de forma segura.

CREATE DATABASE SCOPED CREDENTIAL MyCredential
WITH IDENTITY = 'USER IDENTITY';

B) External Data Source — define las external data sources, como ficheros en OneLake.

CREATE EXTERNAL DATA SOURCE MyOneLakeDS
WITH (
    LOCATION = 'abfss://aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb@<onelake_account>.dfs.fabric.microsoft.com/bbbbbbbb-1111-2222-3333-cccccccccccc/Files/parquet/'
);

C) External File Format — especifica el formato de los ficheros externos: Parquet, CSV, Delta.

CREATE EXTERNAL FILE FORMAT MyFileFormat
WITH (
    FORMAT_TYPE = DELIMITEDTEXT,
    FORMAT_OPTIONS (
        FIELD_TERMINATOR = ',',
        STRING_DELIMITER = '"'
    )
);

D) External Table — crea tablas que referencian data almacenada fuera de la SQL database.

CREATE EXTERNAL TABLE MyExternalTable (
    Column1 INT,
    Column2 NVARCHAR(50)
)
WITH (
    LOCATION = 'myfolder/myfile.csv',
    DATA_SOURCE = MyOneLakeDS,
    FILE_FORMAT = MyFileFormat
);

Uso posterior

Una vez creada la external table, la consultas como si fuera una tabla normal:

SELECT * FROM MyExternalTable WHERE Column1 > 100;

Fabric traduce esto a: leer del fichero externo, aplicar el filtro y devolver resultados. Todo transparente.

Beneficios

• ✅ No data movement: los datos siguen en su source.
• ✅ Real-time: siempre lees los últimos datos.
• ✅ Unified queries: joins entre tablas locales y externas.
• ✅ Ahorro de storage: no duplicas data.
• ✅ Flexibilidad de formato: Parquet, CSV, Delta.

Casos de uso reales

Escenario 1: enriquecer datos OLTP con big data.

-- Tu SQL Database tiene customer master data
-- El Lakehouse tiene web logs enriched

SELECT
    c.customer_id,
    c.name,
    l.total_pageviews
FROM dbo.Customers c
INNER JOIN LakehouseLogs l ON c.customer_id = l.user_id;

Escenario 2: reporting mixto — live OLTP data (SQL Database) e historical archived data (Lakehouse Delta), con un solo query que combina ambos.

Feature

SQL Database en Fabric soporta cross-database queries dentro del mismo workspace. Sintaxis: three-part naming database.schema.table.

Ejemplo

SELECT
    s.OrderID,
    s.Total,
    c.CustomerName
FROM Sales_DB.dbo.Orders s
INNER JOIN Customer_DB.dbo.Customers c
    ON s.CustomerID = c.CustomerID;

La query cruza dos SQL databases distintas en el mismo workspace.

También cross-item type

Puedes hacer cross-query entre distintos tipos de items: SQL Database ↔ Warehouse, y SQL Database ↔ SQL analytics endpoint de Lakehouse. Todo con three-part naming siempre que estén en el mismo workspace.

Limitaciones

• Solo mismo workspace (cross-workspace requiere shortcuts).
• Read-only en el remote (típicamente).

SQL Database es un first-class citizen

SQL Database en Fabric está integrado nativamente con todo el ecosistema:

Data ingestion: los pipelines pueden usar SQL Database como source/destination, y los Dataflows Gen2 igual.

Analytics downstream: el mirror automático a OneLake habilita Power BI Direct Lake, notebooks y warehouse queries.

Governance: integración con Purview, soporte de sensitivity labels y endorsement (Promoted, Certified).

Copilot: Copilot for SQL Database integrado en el editor, y Fabric IQ puede consultar la SQL Database para analytics con IA.

DevOps: Git integration para source control y deployment pipelines para dev → test → prod.

GraphQL API integration

SQL Database en Fabric puede exponerse como GraphQL API usando API for GraphQL (item de Fabric): una data API moderna para aplicaciones, consumible desde web apps, mobile apps y servicios. Lo vemos en el Módulo 13: GraphQL en Fabric.

Casos ideales

A) Apps transaccionales que viven dentro del ecosistema Fabric: apps customer-facing que necesitan OLTP, backend de aplicaciones internas, order management, booking systems.

B) Aplicaciones que necesitan tanto OLTP como analytics: el auto-mirror elimina la necesidad de dos productos; un solo item soluciona ambos casos.

C) Prototipos y proyectos rápidos: SaaS = zero setup, sample data listo, Copilot para acelerar el desarrollo.

D) Equipos sin DBAs dedicados: las autonomous features gestionan el tuning y el indexing, con menos carga de mantenimiento.

E) Modern app development: combinación con GraphQL API, integración con AI/Copilot e integración directa con Power BI para reports operacionales.

Cuándo NO usar SQL Database

• A) Big data analytics puro → mejor Warehouse o Lakehouse.
• B) Data science con ML → mejor Lakehouse con Spark.
• C) Data lake pattern → Lakehouse.
• D) Streaming ingestion → Eventhouse / KQL Database.
• E) On-prem workloads → seguir con SQL Server / Azure SQL Managed Instance.

• Trampa 1: "SQL Database en Fabric = Azure SQL Database" ❌ Diferentes: Fabric SQL DB es SaaS, Azure SQL DB es PaaS. Mismo engine pero distinta gestión.
• Trampa 2: "SQL Database es un data warehouse" ❌ NO. SQL Database es OLTP (transaccional). El Warehouse es OLAP (analítico).
• Trampa 3: "Necesito hacer setup del mirroring" ❌ El mirror a OneLake es automático desde el momento cero en SQL Database en Fabric. No requiere configuración.
• Trampa 4: "Los item permissions dan acceso a los datos" ❌ Los item permissions solo permiten conectar. Las T-SQL security policies dentro de la DB deciden qué puedes ver.
• Trampa 5: "Automatic indexing requiere configuración manual" ❌ Es automático por defecto. Puedes monitorizarlo pero no hace falta configurarlo.
• Trampa 6: "Copilot usa mis datos para generar SQL" ❌ NO. Copilot solo usa schema information (nombres de tablas/columnas), NUNCA los datos reales de las tablas.
• Trampa 7: "El mirror es real-time exactamente" ❌ Es near real-time. Hay latencia de segundos-minutos según el workload.
• Trampa 8: "Las external tables copian los datos" ❌ Solo referencian. Data virtualization = NO data movement.
• Trampa 9: "Puedo hacer INSERT en el SQL analytics endpoint del mirror" ❌ Read-only. Los writes van a la SQL Database original, que luego se mirrorea.
• Trampa 10: "Las cross-database queries funcionan cross-workspace" ❌ Solo mismo workspace. Cross-workspace requiere shortcuts.
• Trampa 11: "SQL Database y Warehouse son intercambiables" ❌ Propósitos muy distintos: OLTP vs OLAP. Elegir según workload.
• Trampa 12: "Las autonomous features me libran de TODO trabajo DBA" ❌ Automatic tuning e indexing cubren el 80%. Aún necesitas diseño de schema, business logic y decisiones de compliance.
• Trampa 13: "SQL Database solo se conecta desde el web editor" ❌ Cualquier tool con protocolo TDS: SSMS, ADS, VS Code, apps custom.
• Trampa 14: "El Performance dashboard requiere Copilot" ❌ Son features independientes. El Performance dashboard funciona sin Copilot.
• Trampa 15: "El source control es opcional y raramente útil" ✅ Es una best practice fuerte — para trackear cambios de schema y colaborar.
• Trampa 16: "El mirror del SQL Database va a un Lakehouse" ❌ Va directamente a OneLake como ficheros Delta. Distintos workloads de Fabric pueden consumirlos.
• Trampa 17: "SQL Database y SQL analytics endpoint son lo mismo" ❌ SQL Database = OLTP writable. SQL analytics endpoint = read-only sobre el mirror en OneLake.

SQL Database vs Warehouse vs Lakehouse

SaaS vs PaaS (Fabric SQL DB vs Azure SQL DB)

Mirror pattern

Copilot capabilities

⚠️ NO usa data de las tablas para las sugerencias.

T-SQL security en SQL Database (igual que Warehouse)

Data virtualization: 4 building blocks

Autonomous features

3 tiles útiles al crear SQL Database

• Módulo Learn: get-started-sql-database-microsoft-fabric
• SQL Database in Fabric overview: database/sql/overview
• Create SQL database: database/sql/create
• SQL database tutorial: tutorial-introduction
• Copilot for SQL Database: copilot-sql-database
• Copilot chat pane: copilot-chat-pane
• Automatic tuning: automatic-tuning
• Performance dashboard: performance-dashboard
• Authentication: authentication
• Configure access controls: configure-sql-access-controls
• Share and manage permissions: share-sql-manage-permission
• Source control integration: source-control
• Mirroring for analytics: mirroring-overview
• Azure SQL Database mirror tutorial: azure-sql-database-tutorial
• SQL analytics endpoint: sql-analytics-endpoint
• Data virtualization: data-virtualization
• SSMS connect quickstart: ssms-connect-query-sql-database-fabric