A county open-data team publishes GIS attribute extracts in blob storage and wants analysts to query them from Azure SQL without importing every file into the primary database. What should they design?
Select an answer to reveal the explanation.
Short Explanation
External tables are the county’s glass window onto the blob library—analysts can see the GIS extracts without hauling every box into the main SQL vault. That keeps open data queryable while the primary database stays lean.
Full Explanation
Open-data GIS attribute extracts often live as files in blob storage. External tables let Azure SQL present those files as queryable relations so analysts can join or filter civic open data in place without first bulk-loading every extract into the primary database. That pattern keeps the operational database lean while still offering T-SQL access for ad hoc municipal analysis and publishing pipelines. Copying every extract into a ledger table adds cryptographic hashing overhead and still imports the data; ledger solves tamper evidence, not external file access. Loading GIS files into in-memory OLTP refreshed every minute treats analytical open data like hot transactional state, which is expensive and misaligned with blob-based publishing. Graph node tables that store polygon vertices as edges invent a relationship model where the requirement is simply to query file-backed attributes. Caveat: external tables depend on data source credentials, file formats, and pushdown capabilities; performance and transactional guarantees differ from local tables, so do not use them as the system of record for operational edits. Operational check: create the external data source and external table over a sample GIS extract, run a selective SELECT with a filter on a known attribute, and verify rows return without a preceding bulk insert into a local user table.