Quali sono gli anti-pattern SQL più comuni? [chiuso]

Tutti noi che lavoriamo con database relazionali abbiamo imparato (o stanno imparando) che SQL è diverso. Ottenere i risultati desiderati e farlo in modo efficiente implica un processo noioso in parte caratterizzato dall'apprendimento di paradigmi sconosciuti e dalla scoperta che alcuni dei nostri schemi di programmazione più familiari non funzionano qui. Quali sono gli antipattern comuni che hai visto (o che hai commesso)?

Sono costantemente deluso dalla tendenza della maggior parte dei programmatori di mescolare la loro logica dell'interfaccia utente nel livello di accesso ai dati:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Normalmente, i programmatori lo fanno perché intendono associare il loro set di dati direttamente a una griglia, ed è conveniente avere sul server un formato SQL Server piuttosto che un formato.

Le query come quella mostrata sopra sono estremamente fragili perché associano strettamente il livello dati al livello dell'interfaccia utente. Inoltre, questo stile di programmazione impedisce che le procedure memorizzate siano riutilizzabili.

Ecco i miei 3 migliori.

Numero 1. Impossibile specificare un elenco di campi. (Modifica: per evitare confusione: questa è una regola del codice di produzione. Non si applica agli script di analisi una tantum, a meno che non sia l'autore.)

SELECT *
Insert Into blah SELECT *

dovrebbe essere

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Numero 2. Utilizzando un cursore e ciclo while, quando lo farà un ciclo while con una variabile loop.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Numero 3. DateLogic attraverso i tipi di stringa.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Dovrebbe essere

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

Ho visto un recente picco di "Una query è meglio di due, prima?"

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

Questa query richiede due o tre piani di esecuzione diversi a seconda dei valori dei parametri. Viene generato un solo piano di esecuzione e bloccato nella cache per questo testo sql. Tale piano verrà utilizzato indipendentemente dal valore dei parametri. Ciò si traduce in scarse prestazioni intermittenti. È molto meglio scrivere due query (una query per piano di esecuzione previsto).

• Campi password leggibili dall'uomo , egad. Autoesplicativo.

• Usando LIKE su colonne indicizzate , e sono quasi tentato di dire LIKE in generale.

• Riciclaggio dei valori PK generati da SQL.

• Sorpresa nessuno ha ancora menzionato la divinità . Nulla dice "organico" come 100 colonne di bit flag, stringhe di grandi dimensioni e numeri interi.

• Poi c'è il modello "Mi mancano i file .ini" : memorizzazione di CSV, stringhe delimitate da pipe o altri dati richiesti di analisi in campi di testo di grandi dimensioni.

• E per server MS SQL l'uso di cursori a tutti . C'è un modo migliore per eseguire qualsiasi attività del cursore.

Modificato perché ce ne sono così tanti!

Non è necessario scavare a fondo per questo: non usare istruzioni preparate.

Utilizzo di alias di tabella senza significato:

from employee t1,
department t2,
job t3,
...

Rende la lettura di una grande istruzione SQL molto più difficile di quanto debba essere

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Confidando ciecamente nell'input dell'utente
2. Non utilizzare query con parametri
3. Password in chiaro

I miei bugbear sono le 450 tabelle di accesso della colonna che sono state messe insieme dal figlio di 8 anni del toelettatore di cani dei migliori amici dell'amministratore delegato e la tabella di ricerca ingannevole che esiste solo perché qualcuno non sa come normalizzare correttamente una struttura di dati.

In genere, questa tabella di ricerca è simile alla seguente:

ID INT,
Nome NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Data1 DATETIME,
Data2 DATETIME

Ho perso il conto del numero di clienti che ho visto che hanno sistemi che si basano su abominazioni come questa.

Quelli che non mi piacciono di più sono

1. Usando gli spazi durante la creazione di tabelle, sprocs ecc. Sto bene con CamelCase o under_scores e singolare o plurale e MAIUSCOLO o minuscolo ma dovendo fare riferimento a una tabella o colonna [con spazi], specialmente se [è stranamente spaziato] (sì, Mi sono imbattuto in questo) mi irrita davvero.

2. Dati denormalizzati. Una tabella non deve essere perfettamente normalizzata, ma quando mi imbatto in una tabella di dipendenti che ha informazioni sul loro punteggio di valutazione corrente o sul loro elemento principale, mi dice che probabilmente dovrò creare una tabella separata ad un certo punto e quindi prova a mantenerli sincronizzati. Prima normalizzerò i dati e poi se vedo un posto in cui la denormalizzazione aiuta, la prenderò in considerazione.

3. Uso eccessivo di viste o cursori. Le viste hanno uno scopo, ma quando ogni tabella è racchiusa in una vista è troppo. Ho dovuto usare i cursori alcune volte, ma generalmente puoi usare altri meccanismi per questo.

4. Accesso. Un programma può essere un anti-schema? Abbiamo SQL Server al mio lavoro, ma un certo numero di persone utilizza l'accesso a causa della sua disponibilità, "facilità d'uso" e "facilità" per gli utenti non tecnici. C'è troppo qui per approfondire, ma se sei stato in un ambiente simile, lo sai.

usa SP come prefisso del nome della procedura del negozio perché cercherà prima nella posizione delle procedure di sistema piuttosto che in quelle personalizzate.

Uso eccessivo di tabelle e cursori temporanei.

Per la memorizzazione dei valori temporali, utilizzare solo il fuso orario UTC. L'ora locale non deve essere utilizzata.

utilizzando @@ IDENTITY anziché SCOPE_IDENTITY ()

Citato da questa risposta :

• @@ IDENTITY restituisce l'ultimo valore di identità generato per qualsiasi tabella nella sessione corrente, in tutti gli ambiti. Devi stare attento qui, poiché è attraverso gli ambiti. È possibile ottenere un valore da un trigger, anziché dall'istruzione corrente.
• SCOPE_IDENTITY restituisce l'ultimo valore di identità generato per qualsiasi tabella nella sessione corrente e nell'ambito corrente. Generalmente quello che vuoi usare.
• IDENT_CURRENT restituisce l'ultimo valore di identità generato per una tabella specifica in qualsiasi sessione e ambito. Questo ti consente di specificare da quale tabella desideri il valore, nel caso in cui i due sopra non siano proprio ciò di cui hai bisogno (molto raro). È possibile utilizzarlo se si desidera ottenere il valore IDENTITÀ corrente per una tabella in cui non è stato inserito un record.

Riutilizzare un campo "morto" per qualcosa a cui non era destinato (ad es. Memorizzazione dei dati utente in un campo "Fax") - molto allettante come soluzione rapida!

select some_column, ...
from some_table
group by some_column

e supponendo che il risultato sarà ordinato per some_column. L'ho visto un po 'con Sybase, dove il presupposto vale (per ora).

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

Oppure, stipando tutto in una riga.

• La FROM TableA, TableB WHEREsintassi per JOINS anzichéFROM TableA INNER JOIN TableB ON

• Fare ipotesi sul fatto che una query verrà restituita ordinata in un certo modo senza inserire una clausola ORDER BY, solo perché era così che si presentava durante il test nello strumento di query.

Imparare SQL nei primi sei mesi della loro carriera e non imparare mai nient'altro per i prossimi 10 anni. In particolare, non apprendere o utilizzare efficacemente le funzionalità SQL analitiche / per finestre. In particolare l'uso di over () e la partizione di.

Le funzioni della finestra, come le funzioni di aggregazione, eseguono un'aggregazione su un set definito (un gruppo) di righe, ma anziché restituire un valore per gruppo, le funzioni della finestra possono restituire più valori per ciascun gruppo.

Vedi l' Appendice A del ricettario SQL O'Reilly per una bella panoramica delle funzioni di finestratura.

Devo inserire qui il mio preferito preferito, solo per completare l'elenco. Il mio antipasto preferito non sta testando le tue domande .

Questo vale quando:

1. La tua query coinvolge più di una tabella.
2. Pensi di avere un design ottimale per una query, ma non preoccuparti di testare i tuoi presupposti.
3. Accetti la prima query che funziona, senza alcun indizio sul fatto che sia anche vicino all'ottimizzazione.

E tutti i test eseguiti su dati atipici o insufficienti non contano. Se si tratta di una procedura memorizzata, inserire l'istruzione test in un commento e salvarla, con i risultati. Altrimenti, inseriscilo in un commento nel codice con i risultati.

Abuso di tabella temporanea.

In particolare questo genere di cose:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

Non creare una tabella temporanea da una query, solo per eliminare le righe non necessarie.

E sì, ho visto pagine di codice in questo modulo nei DB di produzione.

Vista contraria: eccessiva ossessione per la normalizzazione.

La maggior parte dei sistemi SQL / RBDB offre molte funzionalità (transazioni, replica) che sono piuttosto utili, anche con dati non normalizzati. Lo spazio su disco è economico e talvolta può essere più semplice (codice più semplice, tempo di sviluppo più veloce) manipolare / filtrare / cercare dati recuperati, piuttosto che scrivere uno schema 1NF e gestire tutte le seccature (join complessi, sottoselezioni cattive) , eccetera).

Ho scoperto che i sistemi sovra-normalizzati sono spesso un'ottimizzazione prematura, specialmente durante le prime fasi di sviluppo.

(altri pensieri su di esso ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

Ho appena messo insieme questo, basato su alcune delle risposte SQL qui su SO.

È un grave antipattern pensare che i trigger siano per i database come i gestori di eventi sono per OOP. C'è questa percezione secondo cui qualsiasi vecchia logica può essere messa in trigger, per essere attivata quando una transazione (evento) si verifica su un tavolo.

Non vero. Una delle grandi differenze è che i trigger sono sincroni, con una vendetta, perché sono sincroni su un'operazione impostata, non su un'operazione di riga. Sul lato OOP, esattamente l'opposto: gli eventi sono un modo efficiente per implementare transazioni asincrone.

Stored procedure o funzioni senza commenti ...

1) Non so che sia un anti-pattern "ufficiale", ma non mi piace e cerco di evitare i letterali di stringa come valori magici in una colonna del database.

Un esempio dalla tabella 'image' di MediaWiki:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Noto solo involucri diversi, un'altra cosa da evitare)

Progetto casi come ricerche int in tabelle ImageMediaType e ImageMajorMime con chiavi primarie int.

2) conversione data / stringa che si basa su impostazioni NLS specifiche

CONVERT(NVARCHAR, GETDATE())

senza identificatore di formato

Sottoquery identiche in una query.

• La vista alterata - Una vista che viene modificata troppo spesso e senza preavviso o motivo. Il cambiamento verrà notato nel momento più inappropriato o peggio sarà sbagliato e mai notato. Forse l'applicazione si interromperà perché qualcuno ha pensato a un nome migliore per quella colonna. Di norma le opinioni dovrebbero estendere l'utilità delle tabelle di base mantenendo un contratto con i consumatori. Risolvi i problemi, ma non aggiungere funzionalità o peggiorare il comportamento, per questo creare una nuova vista. Per mitigare non condividere le opinioni con altri progetti e, utilizzare CTE quando le piattaforme lo consentono. Se il tuo negozio ha un DBA, probabilmente non puoi modificare le visualizzazioni, ma tutte le visualizzazioni saranno obsolete e / o inutili in quel caso.

• Il! Paramed - Una query può avere più di uno scopo? Probabilmente, ma la prossima persona che lo legge non lo saprà fino a quando la meditazione profonda. Anche se non ne hai bisogno in questo momento è probabile che lo farai, anche se è "solo" il debug. L'aggiunta di parametri riduce i tempi di manutenzione e mantiene le cose ASCIUTTE. Se hai una clausola where dovresti avere dei parametri.

• Il caso per nessun caso -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

I due che trovo di più e che possono avere un costo significativo in termini di prestazioni sono:

• Utilizzo dei cursori anziché di un'espressione basata su set. Immagino che questo si verifichi frequentemente quando il programmatore sta pensando in modo procedurale.

• Utilizzando le query secondarie correlate, quando un join a una tabella derivata può eseguire il lavoro.

Inserimento di elementi nelle tabelle temporanee, in particolare le persone che passano da SQL Server a Oracle hanno l'abitudine di abusare delle tabelle temporanee. Usa solo le istruzioni selezionate nidificate.

Gli sviluppatori che scrivono query senza avere una buona idea di ciò che rende le applicazioni SQL (sia singole query che sistemi multiutente) veloci o lente. Ciò include l'ignoranza su:

• strategie di minimizzazione degli I / O fisici, dato che il collo di bottiglia della maggior parte delle query è I / O non CPU
• perfetto impatto di diversi tipi di accesso all'archiviazione fisica (ad es. molti I / O sequenziali saranno più veloci di molti piccoli I / O casuali, anche se meno se l'archiviazione fisica è un SSD!)
• come ottimizzare manualmente una query se il DBMS produce un piano di query scadente
• come diagnosticare scarse prestazioni del database, come "eseguire il debug" di una query lenta e come leggere un piano di query (o EXPLAIN, a seconda del DBMS scelto)
• strategie di blocco per ottimizzare il throughput ed evitare deadlock nelle applicazioni multiutente
• importanza del batch e altri trucchi per gestire l'elaborazione dei set di dati
• progettazione di tabelle e indici per bilanciare al meglio lo spazio e le prestazioni (ad es. coprire gli indici, mantenere gli indici piccoli ove possibile, ridurre i tipi di dati alla dimensione minima necessaria, ecc.)

Utilizzo di SQL come pacchetto ISAM (metodo di accesso sequenziale indicizzato) glorificato. In particolare, annidando i cursori invece di combinare le istruzioni SQL in una singola istruzione, sebbene più ampia. Questo vale anche come "abuso dell'ottimizzatore" poiché in realtà non c'è molto che l'ottimizzatore possa fare. Questo può essere combinato con dichiarazioni non preparate per la massima inefficienza:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

La soluzione corretta (quasi sempre) è combinare le due istruzioni SELECT in una:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

L'unico vantaggio della versione a doppio loop è che puoi facilmente individuare le interruzioni tra i valori in Tabella1 perché il loop interno termina. Questo può essere un fattore nei rapporti di interruzione del controllo.

Inoltre, l'ordinamento nell'applicazione è di solito un no-no.

Utilizzo delle chiavi primarie come surrogato per gli indirizzi dei record e utilizzo delle chiavi esterne come surrogato per i puntatori incorporati nei record.