Perché lo standard SQL ANSI-92 non viene adottato meglio rispetto a ANSI-89?

In ogni azienda in cui ho lavorato, ho scoperto che le persone stanno ancora scrivendo le loro query SQL nello standard ANSI-89:

select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id

piuttosto che lo standard ANSI-92:

select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id

Per una query estremamente semplice come questa, non c'è una grande differenza di leggibilità, ma per query di grandi dimensioni trovo che avere i miei criteri di join raggruppati con l'elenco della tabella renda molto più facile vedere dove potrei avere problemi nel mio join e lasciami mantenere tutti i filtri nella mia clausola WHERE. Per non parlare del fatto che ritengo che gli outer join siano molto intuitivi rispetto alla sintassi (+) in Oracle.

Mentre cerco di evangelizzare ANSI-92 alle persone, ci sono vantaggi concreti in termini di prestazioni nell'utilizzo di ANSI-92 rispetto a ANSI-89? Lo proverei da solo, ma le configurazioni Oracle che abbiamo qui non ci consentono di utilizzare EXPLAIN PLAN - non vorrebbe che le persone provassero a ottimizzare il loro codice, vero?

Secondo "SQL Performance Tuning" di Peter Gulutzan e Trudy Pelzer, dei sei o otto marchi RDBMS che hanno testato, non c'era differenza nell'ottimizzazione o nelle prestazioni dei join in stile SQL-89 rispetto a SQL-92. Si può presumere che la maggior parte dei motori RDBMS trasformi la sintassi in una rappresentazione interna prima di ottimizzare o eseguire la query, quindi la sintassi leggibile dall'uomo non fa differenza.

Cerco anche di evangelizzare la sintassi SQL-92. Sedici anni dopo l'approvazione, è ora che la gente inizi a usarlo! E ora tutte le marche di database SQL lo supportano, quindi non c'è motivo di continuare a utilizzare la (+)sintassi Oracle non standard o la sintassi *=Microsoft / Sybase.

Per quanto riguarda il motivo per cui è così difficile rompere la comunità degli sviluppatori dell'abitudine SQL-89, posso solo presumere che ci sia una grande "base della piramide" di programmatori che codificano mediante copia e incolla, utilizzando antichi esempi di libri, articoli di riviste, o un'altra base di codice e queste persone non imparano la nuova sintassi in modo astratto. Alcune persone si adattano a schemi e altre imparano a memoria.

Tuttavia, vedo gradualmente persone che usano la sintassi SQL-92 più frequentemente di quanto facessi prima. Ho risposto a domande SQL online dal 1994.

Ebbene, lo standard ANSI092 include una sintassi piuttosto atroce. I natural join sono uno e la clausola USING è un altro. IMHO, l'aggiunta di una colonna a una tabella non dovrebbe rompere il codice ma un NATURAL JOIN si rompe in modo eclatante. Il modo "migliore" per rompere è per errore di compilazione. Ad esempio, se SELEZIONA * da qualche parte, l'aggiunta di una colonna potrebbenon riescono a compilare. Il modo migliore per fallire sarebbe un errore di runtime. È peggio perché i tuoi utenti potrebbero vederlo, ma ti dà comunque un bel avvertimento che hai rotto qualcosa. Se si utilizza ANSI92 e si scrivono query con join NATURALI, non si interromperà in fase di compilazione e non si interromperà in fase di esecuzione, la query inizierà improvvisamente a produrre risultati errati. Questi tipi di bug sono insidiosi. I rapporti vanno male, le informazioni potenzialmente finanziarie non sono corrette.

Per chi non ha familiarità con i giunti NATURALI. Uniscono due tabelle su ogni nome di colonna presente in entrambe le tabelle. Il che è davvero interessante quando hai un tasto a 4 colonne e sei stufo di digitarlo. Il problema si presenta quando Table1 ha una colonna preesistente denominata DESCRIPTION e aggiungi una nuova colonna a Table2 denominata, oh non lo so, qualcosa di innocuo come, mmm, DESCRIPTION e ora stai unendo le due tabelle su un VARCHAR2 (1000) campo che è in forma libera.

La clausola USING può portare a un'ambiguità totale oltre al problema descritto sopra. In un altro post SO , qualcuno ha mostrato questo SQL ANSI-92 e ha chiesto aiuto per leggerlo.

SELECT c.* 
FROM companies AS c 
JOIN users AS u USING(companyid) 
JOIN jobs AS j USING(userid) 
JOIN useraccounts AS us USING(userid) 
WHERE j.jobid = 123

Questo è completamente ambiguo. Ho inserito una colonna UserID in entrambe le tabelle Società e utente e non ci sono lamentele. Cosa succede se la colonna UserID nelle aziende è l'ID dell'ultima persona che ha modificato quella riga?

Dico sul serio, qualcuno può spiegare perché fosse necessaria tale ambiguità? Perché è integrato direttamente nello standard?

Penso che Bill abbia ragione sul fatto che c'è una vasta base di sviluppatori che copia / incolla lì attraverso la codifica. In effetti, posso ammettere di essere gentile quando si tratta di ANSI-92. Ogni esempio che ho visto mostrava più join nidificati tra parentesi. Onestà, questo rende difficile scegliere i tavoli in sql nel migliore dei casi. Ma poi un evangilista SQL92 ha spiegato che avrebbe effettivamente forzato un ordine di join. GESÙ ... tutti quei Copy Paster che ho visto ora stanno effettivamente forzando un ordine di iscrizione - un lavoro che il 95% delle volte è meglio lasciare agli ottimizzatori, specialmente un copy / paster.

Tomalak ha capito bene quando ha detto,

le persone non passano alla nuova sintassi solo perché esiste

Deve darmi qualcosa e non vedo un lato positivo. E se c'è un lato positivo, gli aspetti negativi sono un albatro troppo grande per essere ignorato.

Mi vengono in mente alcuni motivi:

• le persone lo fanno per abitudine
• le persone sono pigre e preferiscono i join "vecchio stile" perché richiedono meno battitura
• i principianti spesso hanno i loro problemi ad avvolgere la testa intorno alla sintassi di join SQL-92
• le persone non passano alla nuova sintassi solo perché esiste
• le persone non sono consapevoli dei vantaggi che ha la nuova sintassi (se vuoi chiamarla così), principalmente che ti consente di filtrare una tabella prima di fare un outer join, e non dopo di essa quando tutto ciò che hai è la clausola WHERE.

Da parte mia, faccio tutti i miei join nella sintassi SQL-92 e converto il codice dove posso. È il modo più pulito, più leggibile e potente per farlo. Ma è difficile convincere qualcuno a utilizzare il nuovo stile, quando pensano che gli faccia male in termini di maggiore lavoro di digitazione senza modificare il risultato della query.

In risposta al post NATURAL JOIN and USING sopra.

PERCHÉ vedresti mai la necessità di usarli - non erano disponibili in ANSI-89 e sono stati aggiunti per ANSI-92 come quello che posso vedere solo come scorciatoia.

Non lascerei mai un join al caso e specificherei sempre la tabella / alias e l'ID.

Per me, l'unico modo per andare è ANSI-92. È più prolisso e la sintassi non piace ai follower di ANSI-89, ma separa nettamente i tuoi JOINS dal FILTERING.

Innanzitutto lasciatemi dire che in SQL Server la sintassi del join esterno (* =) non fornisce sempre risultati corretti. Ci sono momenti in cui lo interpreta come un cross join e non come un outer join. Quindi c'è un buon motivo per smettere di usarlo. E quella sintassi di outer join è una funzionalità deprecata e non sarà disponibile nella prossima versione di SQL Server dopo SQL Server 2008. Sarai comunque in grado di eseguire gli inner join, ma perché mai qualcuno dovrebbe volerlo? Non sono chiari e molto più difficili da mantenere. Non sai facilmente cosa fa parte del join e cos'è in realtà solo la clausola where.

Uno dei motivi per cui credo che non dovresti usare la vecchia sintassi è che la comprensione dei join e di ciò che fanno e cosa non fanno è un passaggio fondamentale per chiunque scriverà codice SQL. Non dovresti scrivere alcun codice SQL senza aver compreso a fondo i join. Se le comprendi bene, probabilmente giungerai alla conclusione che la sintassi ANSI-92 è più chiara e più facile da mantenere. Non ho mai incontrato un esperto SQL che non usasse la sintassi ANSI-92 rispetto alla vecchia sintassi.

La maggior parte delle persone che ho incontrato o con cui ho avuto a che fare che usano il vecchio codice, davvero non capiscono i join e quindi si mettono nei guai quando interrogano il database. Questa è la mia esperienza personale, quindi non dico che sia sempre vero. Ma come specialista dei dati, ho dovuto sistemare troppa di questa spazzatura nel corso degli anni per non crederci.

Mi è stato insegnato ANSI-89 a scuola e ho lavorato nell'industria per alcuni anni. Poi ho lasciato il favoloso mondo del DBMS per 8 anni. Ma poi sono tornato e mi veniva insegnato questo nuovo materiale ANSI 92. Ho imparato la sintassi Join On e ora insegno effettivamente SQL e raccomando la nuova sintassi JOIN ON.

Ma lo svantaggio che vedo è che le sottoquery correlate non sembrano avere senso alla luce dei join ANSI 92. Quando le informazioni di join sono state incluse in WHERE e le sottoquery correlate sono "unite" in WHERE, tutto sembrava corretto e coerente. In ANSI 92 i criteri di join della tabella non sono nel WHERE e il "join" della sottoquery è, la sintassi sembra incoerente. D'altra parte, provare a "correggere" questa incoerenza probabilmente peggiorerebbe la situazione.

Non so con certezza la risposta .. questa è una guerra di religione (anche se di grado inferiore rispetto a Mac-Pc o altri)

Si presume che fino a tempi relativamente recenti Oracle (e forse anche altri fornitori) non adottasse lo standard ANSI-92 (penso fosse in Oracle v9, o giù di lì) e quindi, per gli sviluppatori DBA / Db che lavorano in aziende che stavano ancora usando queste versioni, (o volevano che il codice fosse portabile su server che potevano usare queste versioni, dovevano attenersi al vecchio standard ...

È davvero un peccato, perché la nuova sintassi di join è molto più leggibile e la vecchia sintassi genera risultati errati (errati) in diversi scenari ben documentati.

• In particolare, i join esterni quando sono presenti predicati di filtro condizionale su colonne non correlate al join dalla tabella sul lato "esterno" del join.

Inerzia e praticità.

ANSI-92 SQL è come la digitazione al tocco. In qualche modo teorico potrebbe migliorare tutto un giorno, ma ora posso scrivere molto più velocemente guardando i tasti con quattro dita. Avrei bisogno di tornare indietro per andare avanti, senza alcuna garanzia che ci sarebbe mai stata una ricompensa.

Scrivere SQL è circa il 10% del mio lavoro. Se ho bisogno di ANSI-92 SQL per risolvere un problema che ANSI-89 SQL non può risolvere, lo userò. (Lo uso in Access, infatti.) Se utilizzarlo tutto il tempo mi aiutasse a risolvere i miei problemi esistenti molto più velocemente, spenderei il tempo per assimilarlo. Ma posso tirare fuori ANSI-89 SQL senza mai pensare alla sintassi. Vengo pagato per risolvere i problemi: pensare alla sintassi SQL è una perdita di tempo e di denaro del mio datore di lavoro.

Un giorno, giovane Grasshopper, difenderai il tuo uso della sintassi SQL ANSI-92 contro i giovani che si lamentano che dovresti usare SQL3 (o qualsiasi altra cosa). E poi capirai. :-)

Avevo una query scritta originariamente per SQL Server 6.5, che non supportava la sintassi di join SQL 92, ad es

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

è stato invece scritto come

select foo.baz
from foo, bar
where foo.a *= bar.a

La query era in circolazione da un po 'di tempo e i dati rilevanti si erano accumulati per rendere la query troppo lenta, circa 90 secondi per essere completata. Quando si è verificato questo problema, eravamo passati a SQL Server 7.

Dopo aver perso tempo con gli indici e altre operazioni di Easter Egging, ho modificato la sintassi del join in modo che fosse conforme a SQL 92. Il tempo della query è sceso a 3 secondi.

C'è una buona ragione per cambiare.

Ripubblicato da qui .

Posso rispondere dal punto di vista di uno sviluppatore medio, conoscendo SQL quel tanto che basta per capire entrambe le sintassi, ma comunque cercando su Google l'esatta sintassi di insert ogni volta che ne ho bisogno ... :-P (Non faccio SQL tutto il giorno , risolvendo solo alcuni problemi di volta in volta.)

Bene, in realtà, trovo la prima forma più intuitiva, che non rende apparente la gerarchia tra le due tabelle. Il fatto di aver imparato SQL con libri forse vecchi, mostrando il primo modulo, probabilmente non aiuta ... ;-)
E il primo riferimento che trovo su una ricerca sql select in Google (che restituisce per me principalmente risposte francesi ... ) mostra prima la forma più vecchia (poi spiega la seconda).

Dando solo qualche suggerimento sulla domanda "perché" ... ^ _ ^ Dovrei leggere un buon libro moderno (agnostico DB) sull'argomento. Se qualcuno ha suggerimenti ...

Non posso parlare per tutte le scuole, ma alla mia università quando stavamo facendo il modulo SQL del nostro corso, non insegnavano ANSI-92, insegnavano ANSI-89 - su un vecchio sistema VAX a quello! Non sono stato esposto a ANSI-92 fino a quando non ho iniziato a scavare in Access dopo aver creato alcune query utilizzando il designer di query e quindi scavando nel codice SQL. Rendendomi conto che non avevo idea di come si completassero i join o delle implicazioni della sintassi, ho iniziato a scavare più a fondo in modo da poterlo capire.

Dato che la documentazione disponibile non è esattamente intuitiva in molti casi, e che le persone tendono ad attenersi a ciò che sanno e in molti casi non si sforzano di imparare più del necessario per svolgere il proprio lavoro, è è facile capire perché l'adozione stia impiegando così tanto tempo.

Naturalmente, ci sono quegli evangelisti tecnici che amano armeggiare e capire e tendono ad essere quei tipi che adottano i principi "più nuovi" e cercano di convertire il resto.

Stranamente, mi sembra che molti programmatori escano dalla scuola e smettano di avanzare; pensando che poiché questo è ciò che è stato insegnato loro, è così che è fatto. È solo quando ti togli i paraocchi che ti rendi conto che la scuola aveva lo scopo solo di insegnarti le basi e darti abbastanza comprensione per imparare il resto da solo e che in realtà hai appena scalfito la superficie di ciò che c'è da sapere; ora tocca a te continuare quel percorso.

Certo, questa è solo la mia opinione basata sulla mia esperienza.

1) Metodo standard per scrivere OUTER JOIN, rispetto a * = o (+) =

2) NATURAL JOIN

3) A seconda del motore di database, le tendenze ANSI-92 sono più ottimali.

4) Ottimizzazione manuale:

Diciamo che abbiamo la sintassi successiva (ANSI-89):

(1)select * from TABLE_OFFICES to,BIG_TABLE_USERS btu
where to.iduser=tbu.iduser and to.idoffice=1

Potrebbe essere scritto come:

(2)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser
where to.idoffice=1

Ma anche come:

(3)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser and to.idoffice=1

Tutti (1), (2), (3) restituiscono lo stesso risultato, tuttavia sono ottimizzati in modo diverso, dipende dal motore del database ma la maggior parte di essi lo fa:

• (1) spetta al motore di database decidere l'ottimizzazione.
• (2) unisce entrambe le tabelle, quindi esegue il filtro per ufficio.
• (3) filtra BIG_TABLE_USERS utilizzando idoffice quindi unisce entrambe le tabelle.

5) Le query più lunghe sono meno disordinate.

Motivi per cui le persone usano ANSI-89 dalla mia esperienza pratica con programmatori vecchi e giovani, tirocinanti e neolaureati:

• Imparano SQL dal codice esistente che vedono (piuttosto che dai libri) e apprendono ANSI-89 dal codice
• ANSI-89 perché digita meno
• Non ci pensano e usano l'uno o l'altro stile e non sanno nemmeno quale di entrambi sia considerato nuovo o vecchio e non gliene importa neanche
• L'idea che il codice sia anche una comunicazione al prossimo programmatore che si avvicina per mantenere il codice non esiste. Pensano di parlare al computer e al computer non importa.
• L'arte della "codifica pulita" è sconosciuta
• La conoscenza del linguaggio di programmazione e di SQL in particolare è così scarsa che copiano e incollano insieme ciò che trovano altrove
• Preferenza personale

Personalmente preferisco ANSI-92 e cambio ogni query che vedo nella sintassi ANSI-89 a volte solo per comprendere meglio l'istruzione SQL a portata di mano. Ma mi sono reso conto che la maggior parte delle persone con cui lavoro non è abbastanza esperta per scrivere join su molte tabelle. Codificano nel miglior modo possibile e usano ciò che hanno memorizzato la prima volta che hanno incontrato un'istruzione SQL.

Ecco alcuni punti che confrontano SQL-89 e SQL-92 e chiariscono alcune idee sbagliate in altre risposte.

1. NATURAL JOINSsono un'idea orribile. Sono impliciti e richiedono meta-informazioni sulla tabella. Niente di SQL-92 richiede il loro utilizzo, quindi ignorali . Non sono rilevanti per questa discussione.
2. USING è un'ottima idea, ha due effetti:
   1. Produce solo una colonna sul set di risultati da un equijoin.
   2. Si impone una convenzione sana e sana. In SQL-89 c'erano persone che scrivevano la colonna idsu entrambe le tabelle. Dopo esserti unito alle tabelle, questo diventa ambiguo e richiede un alias esplicito. Inoltre, idi messaggi sul join quasi certamente avevano dati diversi. Se ti unisci da persona a azienda, ora devi alias uno ida person_ide uno ida company_id, senza il quale l'unione produrrebbe due colonne ambigue. L'utilizzo di un identificatore univoco globale per la chiave surrogata della tabella è la convenzione con cui vengono premiati gli standard USING.
3. La sintassi SQL-89 è implicita CROSS JOIN. A CROSS JOINnon riduce l'insieme, lo accresce implicitamente. FROM T1,T2è lo stesso FROM T1 CROSS JOIN T2che produce un join cartesiano che di solito non è quello che vuoi. Avere la selettività per ridurre quello rimosso a un WHEREcondizionale distante significa che è più probabile che tu commetta errori durante la progettazione.
4. I messaggi ,espliciti SQL-89 e SQL-92 JOINhanno una precedenza diversa. JOINha una precedenza maggiore. Ancora peggio, alcuni database come MySQL si sono sbagliati per molto tempo. . Quindi mescolare i due stili è una cattiva idea, e lo stile molto più popolare oggi è lo stile SQL-92.

Oracle non implementa affatto bene ANSI-92. Ho avuto diversi problemi, non ultimo perché le tabelle di dati in Oracle Apps sono molto ben dotate di colonne. Se il numero di colonne nei tuoi join supera circa 1050 colonne (cosa molto facile da fare in App), otterrai questo errore spurio che non ha assolutamente senso logico:

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

Riscrivere la query per utilizzare la sintassi di join vecchio stile fa scomparire il problema, il che sembra puntare il dito contro l'implementazione dei join ANSI-92.

Fino a quando non ho riscontrato questo problema, ero un convinto promotore di ASNI-92, a causa dei vantaggi nel ridurre la possibilità di un cross join accidentale, che è fin troppo facile da fare con la sintassi vecchio stile.

Ora, tuttavia, trovo molto più difficile insistere su questo punto. Indicano la cattiva implementazione di Oracle e dicono "Lo faremo a modo nostro, grazie".

Un nuovo standard SQL eredita tutto dallo standard precedente, ovvero "i vincoli della compatibilità". Quindi lo stile di join "vecchio" / "separato da virgole" / "non qualificato" è il sytax SQL-92 perfettamente valido.

Ora, sostengo che SQL-92 NATURAL JOINsia l'unico join di cui hai bisogno. Ad esempio, sostengo che sia superiore a inner joinperché non genera colonne duplicate - non più variabili di intervallo inSELECT clausole per disambiguare le colonne! Ma non posso aspettarmi di cambiare ogni cuore e mente, quindi ho bisogno di lavorare con programmatori che continueranno ad adottare quelli che personalmente considero stili di join legacy (e potrebbero persino riferirsi a variabili di intervallo come "alias"!). Questa è la natura del lavoro di squadra e non operare nel vuoto.

Una delle critiche al linguaggio SQL è che lo stesso risultato può essere ottenuto utilizzando un numero di sintassi semanticamente equivalenti (alcune usano l'algebra relazionale, altre usano il calcolo relazionale), dove la scelta del 'migliore' dipende semplicemente dallo stile personale . Quindi mi trovo a mio agio con i join "vecchio stile" come lo sono con INNER. Se mi prenderò il tempo per riscriverli NATURALdipende dal contesto.