Esiste un SQL standard che può sostituire tutte le varie versioni personalizzate?

Question

Esiste un SQL standard che può sostituire tutte le varie versioni personalizzate?

#1 da (9 voti)
#2 da (0 voti)
#3 da (-1 voti)

3

Scrivo SQL da oltre 10 anni. Sono estremamente bravo e ho esperienza di lavoro in SQL Server, Oracle, MySQL, PostgreSQL, ecc. Mentre ci sono più standard in circolazione, sembrano essere più suggerimenti che standard. Quando inizi a parlare dei tipi di colonna e delle stored procedure, non c'è quasi coerenza su tutta la linea.

Mi chiedo se qualcuno abbia mai preso in considerazione la definizione di un nuovo linguaggio di query. Recentemente ho giocato con alcune idee. Ecco alcuni esempi: link . Ovviamente, questo copre solo il DML più ovvio. Questa sintassi renderebbe più semplice supportare il completamento automatico, dare un maggiore controllo sulla generazione della tabella temporanea, semplificare la sintassi del join, semplificare il lavoro con i dati raggruppati e rendere più facili le sottoespressioni / calcoli, solo per citarne alcuni . Mi piace particolarmente perché potrebbe essere facilmente esteso per supportare anche alcuni database noSQL. Immagina cosa potrebbe dare un comitato con più tempo!

La mia domanda è se sia stato fatto qualche sforzo per definire un diverso linguaggio di interrogazione, supportato dai diversi provider. Riconosco che SQL è "abbastanza buono" e che definire e attuare un nuovo standard sarebbe un'impresa monumentale. So che ci sono stati molti standard SQL proposti nel corso degli anni. Mi chiedo solo se uno standard non "SQL" sia mai stato proposto e se abbia fatto progressi o sia semplicemente svanito.

sql database nosql standards standardization

posta Travis Parks 02.10.2014 - 20:24

fonte

3 risposte

Leggi altre domande sui tag sql database nosql standards standardization

proprietà di chiusura del tipo di dati "tupla" in python Evita i nomi smurf durante il wrapping di una libreria

score 9 · Answer 1

La risposta a questo era ANSI SQL.

Sebbene l'adozione iniziale fosse difficile, soprattutto per i database come Oracle, molti di questi ora consentono lo standard ANSI.

Ad esempio, Oracle ha iniziato a consentire tale formato in 9i (vedi link )

Inoltre - PostgreSQL è orgoglioso della conformità agli standard. La sua implementazione SQL è strongmente conforme allo standard ANSI-SQL: 2008 ( link )

Per mysql, vedi link che afferma:

This section describes how MySQL relates to the ANSI/ISO SQL standards. MySQL Server has many extensions to the SQL standard, and here you can find out what they are and how to use them. You can also find information about functionality missing from MySQL Server, and how to work around some of the differences.

The SQL standard has been evolving since 1986 and several versions exist. In this manual, “SQL-92” refers to the standard released in 1992, “SQL:1999” refers to the standard released in 1999, “SQL:2003” refers to the standard released in 2003, and “SQL:2008” refers to the most recent version of the standard, released in 2008.

score 0 · Answer 2

... make the join syntax easier, make working with grouped data easier and make sub-expressions/calculations easier to build up, just to name a few. I especially like it because it could very easily be extended to support some noSQL databases...

Ora penso che sia dove Uno standard per domarli si rompe ... Le attuali soluzioni NoSQL non sono ottimali come quelle del RDBMS tradizionale per l'esecuzione di operazioni di join, se addirittura lo supportano in modo nativo nel primo luogo, e per buone ragioni. Certo, stanno cercando di migliorare in questo aspetto, ma non c'è ancora una bacchetta magica. E perché fermarsi a NoSQL vs RDBMS, che ne dici di database grafici? Cypher per Neo4j ha una clausola MATCH invece che 'è analoga a JOIN in SQL '.

Penso che uno dovrebbe guardare ai framework di persistenza polyglot per gestire adeguatamente il problema "vari SQL personalizzati". Se si scopre che l'applicazione utilizza una piccola soluzione RDBMS in-memory per la semplice memorizzazione nella cache e scrive in un data warehouse multi-terabyte basato su una soluzione NoSQL, la "soluzione" a un'interfaccia di database standardizzata potrebbe non essere un comune dialetto comune ma una struttura ben scritta che comprende le differenze e le gestisce in modo appropriato.

score -1 · Answer 3

No. La realtà è che l'SQL richiesto da Oracle, DB2, SQLite, MySQL, PostgreSQL e il nome del tuo altro DBMS relazionale preferito è diverso dall'SQL richiesto da ciascuno degli altri sistemi DBMS - nonostante i vari "standard" SQL.

Funzionalità e semantica di base, come quali tipi di dati sono supportati (e come vengono chiamati), come sono allocati gli identificatori di riga (con quale semantica) e quale tipo di operazioni sono supportate (incluse parole chiave, funzioni, restrizioni, e semantica) differiscono enormemente. Queste molte differenze sono il motivo per cui le migrazioni DBMS sono così famose e perché richiedono strumenti personalizzati e servizi di consulenza.

Sì, la forma di base di SELECT * FROM table WHERE ... è comune a tutti i sistemi di database relazionali. Ma il diavolo delle applicazioni reali è nei dettagli, e i dettagli differiscono in modi importanti tra diversi archivi di dati.

Questo non vuol dire nulla delle differenze ancora maggiori viste tra DBMS relazionali e non relazionali (siano essi gerarchici tradizionali, rete, file flat, archivi di dischi o il nuovo hotness di NoSQL). Anche se hanno "livelli di compatibilità SQL", l'estensione e la semantica del loro SQL variano notevolmente.

L'omogeneizzazione di SQL (e altre definizioni di dati e query langauge) è un approccio che è stato lavorato, provato e sperato almeno per quattro decenni ora. Non funziona mai abbastanza bene come sperato. Dato il fondamentale incentivo economico per i produttori di DBMS per impedire ai loro clienti di migrare facilmente verso prodotti o venditori concorrenti, c'è poca speranza che questo possa essere risolto in qualsiasi momento nei prossimi dieci anni.