Schema mentale per query SQL [chiuso]

2

Durante la preparazione del materiale introduttivo SQL, ho finito di chiedermi la linea di pensiero seguita da uno sviluppatore durante la scrittura di una query. Credo che potrebbe essere troppo prezioso dal punto di vista di un principiante.

Lasciatemi illustrare l'argomento con un esempio. Per brevità, non includerò lo schema del database, sperando che la query sia abbastanza descrittiva da sola.

Supponiamo di voler scrivere una query per recuperare tutti i nuovi clienti dall'ultimo trimestre. Tipico. Io, la prima cosa a cui penso è l'insieme delle entità coinvolte, a cominciare da quelle corrispondenti ai dati richiesti. Quindi, poiché voglio ottenere clienti, prima di tutto scrivo la seguente query scheletro:

    SELECT
      FROM Customers AS NewCustomer
     WHERE 

Seguono immediatamente le restanti entità . In questo contesto fittizio, un nuovo cliente è un cliente che ha effettuato un ordine per la prima volta:

    SELECT
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
 LEFT JOIN Orders AS OlderOrder
     WHERE 
       AND OlderOrder.Id IS NULL

Con tutte le entità identificate, procedo scrivendo le relazioni tra loro:

    SELECT
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
        ON RecentOrder.CustomerId = NewCustomer.Id
 LEFT JOIN Orders AS OlderOrder
        ON OlderOrder.CustomerId = RecentOrder.CustomerId
       AND OlderOrder.PlacementDate < RecentOrder.PlacementDate
     WHERE 
       AND OlderOrder.Id IS NULL

Una volta che ho finito con le entità, è tempo che io definisca le restrizioni da applicare sul set di dati risultante:

    SELECT 
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
        ON RecentOrder.CustomerId = NewCustomer.Id
 LEFT JOIN Orders AS OlderOrder
        ON OlderOrder.CustomerId = RecentOrder.CustomerId
       AND OlderOrder.PlacementDate < RecentOrder.PlacementDate
     WHERE RecentOrder.PlacementDate BETWEEN @fromDate AND @toDate
       AND OlderOrder.PlacementDate < @fromDate
       AND OlderOrder.Id IS NULL

Infine, mi chiedo quali dati concreti campi voglio che la query restituisca, completando così la clausola SELECT :

    SELECT NewCustomer.FirstName, NewCustomer.LastName
      FROM Customers AS NewCustomer
INNER JOIN Orders AS RecentOrder
        ON RecentOrder.CustomerId = NewCustomer.Id
 LEFT JOIN Orders AS OlderOrder
        ON OlderOrder.CustomerId = RecentOrder.CustomerId
       AND OlderOrder.PlacementDate < RecentOrder.PlacementDate
     WHERE RecentOrder.PlacementDate BETWEEN @fromDate AND @toDate
       AND OlderOrder.PlacementDate < @fromDate
       AND OlderOrder.Id IS NULL

Naturalmente, questa è una query molto semplice, senza aggregazioni, query annidate e altre cose avanzate. Ma questa è la mia linea di pensiero generale, indipendentemente dalla complessità della query:

  1. Enti
  2. Relazioni
  3. Restrizioni
  4. Campi

La mia domanda è, è uno schema adatto per essere insegnato esplicitamente a un principiante? Come potrebbe essere migliorato, comunque, per appianare la sua curva di apprendimento?

    
posta rucamzu 29.01.2014 - 00:05
fonte

1 risposta

5

tl; dr

Penso che tu sia esattamente al contrario.

Uno sviluppatore esperto costruisce le sue query nell'ordine in cui lo menzioni perché questo è l'ordine delle dipendenze - Non sai quali relazioni devi seguire fino a quando non sai quali entità hai bisogno, non sai quali sono le restrizioni necessario senza prima identificare le tue relazioni e non puoi sapere cosa restringere finché non conosci il campo impostato a tua disposizione.

Quindi uno sviluppatore esperto spesso segue l'ordine come stabilito perché nel mondo reale abbiamo bisogno del componente di livello più alto - l'entità - e quella parte spinge come usiamo tutti gli altri.

Tuttavia, questo ordine è dal livello più alto più dipendente dai pezzi meno dipendenti di livello più basso. Per qualcuno che non ha familiarità con SQL, non si desidera insegnare prima alle entità quando non conoscono ancora relazioni, restrizioni o campi; in modo transitorio non dovresti insegnare le relazioni a qualcuno che non conosce restrizioni o campi, o restrizioni a qualcuno che non conosce i campi.

Dato il concetto che stai descrivendo sopra e analizzando il modo in cui lo vedo, dovresti insegnare loro esattamente nell'ordine opposto che hai suggerito.

Penso che questo diventi ovvio se si guarda alla query di esempio che si è sopra riportata - per interrogare le entità concettuali si finisce con una query molto più complessa di quella che un nuovo sviluppatore SQL dovrebbe cercare prima. Inoltre, fino all'ultimo pezzo non hai una query SQL completa perché la tua ultima cosa da insegnare è il pezzo più dipendente che ogni altro pezzo richiede solo per funzionare. Il modo in cui suggerisci di farlo potrebbe darti esempi SQL incompleti come hai fatto prima di aver insegnato tutti i concetti, sembra più ragionevole dare esempi più piccoli completi che diventano più complessi piuttosto che crescere più completi.

    
risposta data 29.01.2014 - 00:16
fonte

Leggi altre domande sui tag