Risposte:
Penso che tu stia provando a vivere nel mondo dei sogni di Joe Celko dove puoi usare solo SQL standard e in una determinata settimana potresti dover portare tutto il tuo codice da SQL Server a Oracle e quindi Oracle a DB2 e poi di nuovo a SQL Server . Due volte.
Mentre gli aspetti fondamentali e fondamentali dell'SQL standard ti aiuteranno ovunque, cercare di limitarti a quel set di linguaggio per paura del futuro porting (o solo per principio) non è un percorso che consiglierei. Personalmente, mi attengo alle cose standard ANSI quando posso (ad esempio <> vs.! =, COALESCE vs. ISNULL, CURRENT_TIMESTAMP vs. GETDATE (), ecc.), Ma non ho nemmeno paura di usare lo specifico SQL Server cose che mi semplificano il lavoro.
È importante capire come funziona SQL in generale; è altrettanto importante capire come funziona la lingua nei tuoi RDBMS - comprese le deviazioni dallo standard, le deviazioni dal modo in cui un altro RDBMS potrebbe aver implementato lo stesso concetto e le estensioni proprietarie che non esistono altrove.
SQL Server, ad esempio, copre buona parte dello standard e si avvicina alla piena conformità con ogni nuova versione. Coprirà mai il 100%? Altamente dubbioso. Continuerà ad aggiungere estensioni proprietarie non nello standard? Certamente. Se tutti coprissero lo standard e nessuno ne uscisse, allora non ci sarebbero vantaggi nella scelta di una piattaforma piuttosto che di un'altra, e tutti useremmo la stessa cosa.
Nessuno di loro. Puoi imparare l'SQL standard (-ish) per qualsiasi RDBMS.
SQL standard non viene utilizzato nel mondo reale per pagare lavori su progetti di successo ...
Detto questo, MySQL è un buon punto di partenza ed ecco un tutorial
constructive guidance
incredibilmente ipocrita. Dov'è la tua guida costruttiva qui per gbn per migliorare la sua risposta?
Tutti i principali RDBMS supportano le diverse versioni della specifica SQL in misura diversa, con le versioni precedenti della specifica più supportate. Non tutti prendono la conformità allo stesso modo sul serio (ad esempio, Oracle ha iniziato a supportare "ansi joins" nel 2001, quasi un decennio dopo SQL-92 ), e come già detto da @gbn, in pratica è necessario conoscere il sapore dell'SQL utilizzato da ciascun prodotto usate.
Postgres è un'eccezione in quanto "è orgoglioso della conformità agli standard" . Per "scopi di apprendimento e di riferimento", è necessaria una pratica pratica con un database, non solo la conoscenza di un libro o di uno standard, e Postgres è una piattaforma ideale per imparare le corde perché:
D'accordo con Jack e gbn, non esiste uno standard e devi fare una scelta. Per fare questa scelta, devi prima selezionare RDBMS. Consiglierei di pensare alle seguenti cose: 1) vuoi essere DB-developer o DBA? 2) Con quali sistemi operativi vuoi lavorare? Sono d'accordo, questa domanda è un po 'strana, ma quando parlo con gli studenti, dicono che è importante.
Ad esempio (solo un esempio, forse mi sbaglio) se vuoi essere un DBA e non vuoi lavorare con Windows, non devi pensare a MSSQL. E se vuoi essere DBA e ti piace lavorare con la stringa di comando e i file di configurazione, forse Oracle è ciò di cui hai bisogno. Se vuoi diventare sviluppatore vuoi usare le tue conoscenze in progetti freelance, forse hai bisogno di MySQL?