Quali sono le buone alternative a SQL (il linguaggio)? [chiuso]

Di tanto in tanto sento cose su come SQL fa schifo e non è un buon linguaggio, ma non ho mai sentito parlare molto di alternative ad esso. Quindi, ci sono altri buoni linguaggi che servono allo stesso scopo (accesso al database) e cosa li rende migliori di SQL? Esistono buoni database che utilizzano questo linguaggio alternativo?

EDIT: ho familiarità con SQL e lo uso sempre. Non ho problemi con esso, sono solo interessato a qualsiasi alternativa che potrebbe esistere e perché alle persone piacciono di più.

Inoltre, non sto cercando tipi alternativi di database (il movimento NoSQL), ma solo modi diversi di accedere ai database.

Sono certamente d'accordo sul fatto che la sintassi di SQL sia difficile da lavorare, sia dal punto di vista della sua generazione automatica, sia dal punto di vista dell'analisi, e non è lo stile del linguaggio che scriveremmo oggi se progettassimo SQL per le richieste che poniamo su di esso oggi. Non penso che troveremmo così tante parole chiave diverse se progettassimo il linguaggio oggi, sospetto che la sintassi di join sarebbe diversa, funzioni come GROUP_CONCATavrebbero una sintassi più regolare invece di inserire più parole chiave nel mezzo delle parentesi per controllarne il comportamento ... crea la tua lista personale di incongruenze e ridondanze in SQL che vorresti / ti aspetteresti di vedere appianate se riprogettassimo il linguaggio oggi.

Non ci sono alternative a SQL per parlare con database relazionali (cioè SQL come protocollo), ma ci sono molte alternative alla scrittura di SQL nelle vostre applicazioni. Queste alternative sono state implementate sotto forma di frontend per lavorare con database relazionali. Alcuni esempi di frontend includono:

• SchemeQL e CLSQL , che sono probabilmente i più flessibili, a causa della loro eredità Lisp, ma sembrano anche molto più simili a SQL rispetto ad altri frontend.
• LINQ (in .Net)
• ScalaQL e ScalaQuery (in Scala)
• SqlStatement , ActiveRecord e molti altri in Ruby,
• HaskellDB
• ... l'elenco continua per molte altre lingue.

Penso che il tema di fondo oggi sia che invece di sostituire SQL con un nuovo linguaggio di query, stiamo invece creando frontend specifici del linguaggio per nascondere l'SQL nei nostri linguaggi di programmazione quotidiani e trattando SQL come il protocollo per parlare con i relazionali banche dati.

Dai un'occhiata a questo elenco.

Hibernate Query Language è probabilmente il più comune. Il vantaggio di Hibernate è che gli oggetti vengono mappati molto facilmente (quasi automaticamente) al database relazionale e lo sviluppatore non deve dedicare molto tempo alla progettazione del database. Controlla il sito web di Hibernate per maggiori informazioni. Sono sicuro che altri interverranno con altri linguaggi di query interessanti ...

Certo, ci sono molte cose NoSQL là fuori, ma dici specificamente che non sei interessato a quelle.

"Di tanto in tanto sento cose su come SQL fa schifo e non è un buon linguaggio"

SQL ha più di trent'anni. Le intuizioni su "quali caratteristiche rendono qualcosa un linguaggio" buono "e quali lo rendono" cattivo "" si sono evolute più rapidamente dello stesso SQL.

Inoltre, SQL non è un linguaggio conforme agli standard attuali di "ciò che serve per essere relazionale", quindi SQL non è semplicemente un linguaggio relazionale da avviare.

"ma non ho mai sentito molto parlare di alternative ad esso."

Ti invito a riflettere sulla possibilità che tu stia cercando di ascoltare solo nei posti sbagliati (cioè, esclusivamente nell'industria commerciale dei DBMS).

"Quindi, ci sono altri buoni linguaggi che hanno lo stesso scopo (accesso al database) e cosa li rende migliori di SQL?"

Date e Darwen descrivono le caratteristiche alle quali un moderno linguaggio di manipolazione dei dati deve conformarsi nel loro "Terzo Manifesto", la cui versione più recente è contenuta nel loro libro "Databases, Types & the Relational Model".

"Esistono dei buoni database che utilizzano questo linguaggio alternativo?"

Se per "buono" intendi qualcosa come "forza industriale", allora no. La cosa più vicina disponibile sarebbe probabilmente Dataphor.

Il progetto Rel offre un'implementazione per il linguaggio Tutorial D definito in "Database, tipi e modello relazionale", ma l'attuale obiettivo principale di Rel è essere di natura educativa.

Il mio progetto SIRA_PRISE offre un'implementazione per la gestione dei dati "veramente relazionale", ma esito a etichettarlo anche "un'implementazione di un linguaggio".

E, naturalmente, potresti anche esaminare alcune cose non relazionali, come alcuni hanno proposto, ma personalmente respingo la gestione dei dati non relazionali come molteplici decenni di regressione tecnologica. Non vale la pena considerare, cioè.

Oh, a proposito, un sistema software utilizzato per gestire i database non è "un database", ma "un sistema di gestione di database", in breve "DBMS". Proprio come una fotografia non è la stessa cosa di una macchina fotografica, e se parli di macchine fotografiche e vuoi evitare confusione, allora dovresti usare la parola corretta "macchine fotografiche" invece di "fotografia".

Forse stai pensando alle critiche che C. Date ei suoi amici hanno mosso contro i database relazionali esistenti e SQL; dicono che i sistemi e il linguaggio non sono relazionali al 100% e dovrebbero esserlo. Non vedo davvero alcun problema reale qui; per quanto ne so puoi avere un sistema relazionale al 100%, se vuoi, semplicemente disciplinando il modo in cui usi SQL.

Quello che personalmente continuo a incontrare è la mancanza di potere espressivo che SQL eredita dalla sua base teorica, l'algebra relazionale. Un problema è la mancanza di supporto per l'uso dell'ordinamento del dominio, in cui ti imbatti quando lavori con dati contrassegnati da date, timestamp, ecc. Una volta ho provato a fare un'applicazione di reportistica interamente in semplice SQL su un database pieno di timestamp e semplicemente non era fattibile. Un altro è la mancanza di supporto per l'attraversamento del percorso: la maggior parte dei miei dati assomiglia a grafici diretti in cui ho bisogno di attraversare i percorsi e SQL non può farlo. (Manca la "chiusura transitiva". SQL-1999 può farlo con "sottoquery ricorsive" ma non le ho ancora viste in uso. Ci sono anche vari hack per far fronte a SQL, ma sono brutti.) Questi problemi sono discusso anche da alcuni degli scritti di Date, tra l'altro.

Recentemente mi è stato indicato .QL che sembra affrontare bene il problema della chiusura transitiva, ma non so se può risolvere il problema con i domini ordinati.

Risposta diretta: non credo che ci sia alcun serio concorrente là fuori. DBase ei suoi imitatori (Foxpro, Codebase ecc.) Sono stati un contendente per un po ', ma penso che fondamentalmente abbiano perso la guerra del linguaggio delle query del database. Ci sono stati molti altri prodotti di database che avevano il proprio linguaggio di query, come Progress e Paradox e molti altri che ho usato di cui non ricordo i nomi e sicuramente molti altri di cui non ho mai sentito parlare. Ma non penso che nessun altro concorrente si sia mai avvicinato a ottenere una quota di mercato non banale.

Come semplice prova dell'esistenza di una differenza tra un formato di database e un linguaggio di query, l'ultima versione di DBase che ho usato - molti anni fa ora - offriva sia il linguaggio di query DBase "tradizionale" che SQL, entrambi i quali potevano essere utilizzati per accedere agli stessi dati.

Divagazione laterale: non direi che SQL fa schifo, ma ha molti difetti. Con il vantaggio degli anni di esperienza e del senno di poi che abbiamo ora, sono sicuro che si potrebbe progettare un linguaggio di query migliore. Ma creare un linguaggio di query migliore e convincere le persone a usarlo sono due cose molto diverse. Sarebbe abbastanza meglio convincere le persone che valeva la pena di imparare. Le persone hanno investito molti anni della loro vita imparando a usare efficacemente SQL. Anche se la tua nuova lingua fosse più facile da usare, ci sarebbe sicuramente una curva di apprendimento. E come migreresti i tuoi sistemi esistenti da SQL alla nuova lingua? Ecc. Può essere fatto, ovviamente, proprio come C ++, C # e Java hanno ampiamente rovesciato COBOL e FORTRAN. Ma ci vuole una combinazione di superiorità tecnica e buon marketing per riuscirci.

Tuttavia, ricevo una risatina dalle persone che si affrettano a difendere SQL ogni volta che qualcuno lo critica, che insistono sul fatto che qualsiasi problema che hai con SQL deve essere la tua inettitudine nell'usarlo e non una colpa di SQL, che semplicemente non devi avere raggiunto il piano più alto di cose necessarie per comprenderne la perfezione, ecc. Calmati, fai un respiro profondo: stiamo insultando un linguaggio informatico, non tua madre.

Dai un'occhiata a LINQ to SQL ...

L'ho provato un paio di mesi fa e non ho mai guardato indietro ...

Già negli anni '80 ObjectStore forniva un accesso trasparente agli oggetti. Era un po 'come un RDBMS più un ORM, tranne che senza tutti quei livelli di astrazione che perdono in più: memorizzava gli oggetti direttamente nel database.

Quindi questa alternativa era davvero "nessuna lingua", o forse "la lingua che stai già utilizzando". Si scriveva codice C ++ e si creavano o si attraversavano oggetti come se fossero oggetti nativi e il database si prendeva cura di tutto secondo necessità. Un po 'come ActiveRecord, ma in realtà ha funzionato così come affermano i blitz di marketing di ActiveRecord. :-)

(Ovviamente, non aveva i muscoli di marketing di Oracle e non aveva il costo zero di MySQL, quindi tutti l'hanno ignorato. E ora proviamo a replicarlo con RDBMS e ORM, e alcune persone cercano di sostenere che le tabelle in realtà ha senso per memorizzare gli oggetti e che scrivere un gigantesco file XML per dire al tuo computer come mappare gli oggetti alle tabelle è in qualche modo una soluzione ragionevole.)

Il movimento generale in questi giorni è NoSQL; generalmente queste tecnologie sono:

• "Tabelle hash" distribuite che memorizzano i dati come coppie chiave / valore
• Database orientati ai documenti

Personalmente penso che non ci sia nulla di sbagliato in SQL fintanto che si adatta alle tue esigenze. SQL è espressivo e ottimo per lavorare con dati strutturati.

Penso che potresti essere interessato a guardare Dataphor , che è un ambiente di sviluppo relazionale open source con il proprio server di database (che parla D) e la capacità di derivare le interfacce utente dal suo linguaggio di query.

Inoltre, sembra che Ingres supporti ancora QUEL ed è open source.

SQL funziona bene per il dominio per il quale è stato progettato: tabelle di dati correlate. Questo si trova generalmente nell'elaborazione tradizionale dei dati aziendali. SQL non funziona così bene quando si cerca di mantenere una complessa rete di oggetti.

Se le tue esigenze sono archiviare ed elaborare dati relativamente tradizionali, utilizza alcuni DBMS basati su SQL.

In risposta alla tua modifica:

Se stai cercando alternative a SQL DML per il recupero di dati da archivi di dati relazionali, non ho mai sentito parlare di alcuna alternativa seria a SQL.

I colpi che SQL ottiene non sono, credo, tanto contro il linguaggio quanto contro i principi di archiviazione dei dati su cui si basa il linguaggio. Le persone spesso confondono il linguaggio SQL con il modello di dati relazionali su cui sono costruiti gli RDBMS.

I database relazionali non sono l'unico tipo di database in circolazione. Dovrei dire una parola sugli oggetti-database perché non l'ho visto nelle risposte degli altri. Ho avuto una certa esperienza con il framework python Zope che usa ZODB per la persistenza degli oggetti invece di RDBMS (beh, è ​​teoricamente possibile sostituire ZODB con un altro database all'interno di zope ma l'ultima volta che ho controllato non sono riuscito a farlo funzionare, quindi posso essere positivo al riguardo).

La mentalità ZODB è davvero diversa, più simile alla programmazione di oggetti che sarebbe persistente.

ORM può essere visto come una sorta di linguaggio

In un certo senso credo che il modello di database a oggetti sia ciò di cui si occupa l'ORM: accedere ai dati persistenti attraverso il tuo solito modello di oggetti. È una specie di linguaggio e sta guadagnando quote di mercato, ma per ora non lo vediamo come un linguaggio ma come uno strato di astrazione. Tuttavia, credo che sarebbe molto più efficiente utilizzare un ORM su un database di oggetti rispetto a SQL (in altre parole le prestazioni degli ORM che mi è capitato di utilizzare utilizzando alcuni database SQL come livelli di base risucchiati).

Esistono molte implementazioni di SQL (SQL Server, mysql, Oracle, ecc.), Ma non esiste nessun altro linguaggio che abbia lo stesso scopo nel senso di essere un linguaggio generico progettato per l'archiviazione e il recupero dei dati relazionali .

Esistono database a oggetti come db4o e ci sono cosiddetti database noSQL simili che si riferiscono a quasi tutti i meccanismi di archiviazione dei dati che non si basano su SQL, ma più comunemente prodotti open source come Cassandra si basano vagamente sul concetto Bigtable di Google .

Ci sono anche una serie di prodotti di database per scopi speciali come CDF, ma probabilmente non devi preoccuparti di quelli - se ne hai bisogno, lo saprai.

Nessuno di questi è equivalente a SQL.

Ciò non significa che siano "migliori" o "peggiori" - semplicemente non sono la stessa cosa. Dennis Forbes ha recentemente scritto un ottimo post analizzando una serie di strane affermazioni che emergono contro SQL. Sostiene (e sono d'accordo) che questi reclami provengono in gran parte da persone e negozi che hanno scelto lo strumento sbagliato per il lavoro in primo luogo, o non utilizzano correttamente il proprio DBMS SQL (non sono nemmeno più sorpreso quando ho vedere un altro database SQL in cui ogni colonna è una varchar(50)e non c'è un singolo indice o chiave, ovunque).

Se stai implementando un altro sito di social networking e non ti preoccupi troppo dei principi ACID , inizia a cercare prodotti come db4o. Se stai sviluppando un sistema aziendale mission-critical, tuttavia, ti consiglio vivamente di pensarci due volte prima di unirti al coro "SQL fa schifo". Fai prima la ricerca, scopri quali caratteristiche possono o non possono supportare i vari prodotti.

Modifica: ero impegnato a scrivere la mia risposta e non ho ricevuto l'aggiornamento della domanda da pochi minuti. Detto questo, SQL è essenzialmente inseparabile dal DBMS stesso. Se esegui un prodotto database SQL, accederai con SQL, punto.

Forse stai cercando astrazioni sulla sintassi; Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic e una miriade di altri strumenti ORM forniscono tutti la propria sintassi simile a SQL che non è proprio SQL. Tutti questi si "compilano" in SQL. Se esegui SQL Server, puoi anche scrivere Funzioni / Procedure / Trigger CLR, che ti consentono di scrivere codice in qualsiasi linguaggio .NET che verrà eseguito all'interno del database; tuttavia, questo non è realmente un sostituto di SQL, più che altro un'estensione.

Non sono a conoscenza di alcuna "lingua" completa che è possibile sovrapporre a un database SQL; a parte il passaggio a un prodotto di database diverso, alla fine vedrai SQL sul pipe.

SQL è di fatto.

I framework che cercano di proteggere gli sviluppatori da esso hanno alla fine creato il proprio linguaggio specifico (viene in mente Hibernate HQL).

SQL risolve un problema abbastanza bene. Non è più difficile da imparare di un linguaggio di programmazione di alto livello. Se conosci già un linguaggio funzionale, apprendere SQL è un gioco da ragazzi.

Considerando i principali fornitori di database che forniscono database all'avanguardia (Oracle e SQL Server) supportano SQL e hanno investito anni in motori di ottimizzazione, ecc. E tutti i principali software di modellazione dati e software di gestione delle modifiche in SQL, direi che è il scommessa più sicura.

Inoltre, in un database c'è di più che semplici query. C'è scalabilità, backup e ripristino, data mining. I grandi fornitori supportano molte cose che nemmeno i nuovi motori "cache" non prendono in considerazione.

Problemi con SQL mi hanno spinto a creare una bozza di linguaggio di query chiamato SMEQL nel wiki di Portland Pattern Repository . Commenti Benvenuto. Prende in prestito idee dalla programmazione funzionale e dal linguaggio sperimentale di IBM Business System 12. (Inizialmente l'ho chiamato TQL, ma in seguito ho scoperto che quel nome è stato preso.)

Nel mondo .NET, sebbene abbia ancora un aspetto simile a SQL, LINQ-to-SQL ti consentirà di avere un buon mix di SQL e l'elaborazione .NET in memoria dei tuoi dati. Inoltre, semplifica molto l'impianto di dati di livello inferiore che nessuno vuole veramente fare.

Se vuoi vedere un tipo di database con una mentalità completamente diversa, dai un'occhiata a CouchDB . "Migliore" è ovviamente un requisito relativo e questo tipo di database non correlato è "Migliore", ma solo in determinati scenari.

SQL la lingua è molto potente ei sistemi di gestione dei database relazionali hanno avuto e sono ancora un enorme successo. Ma esiste una classe di applicazioni che richiede una scalabilità e una disponibilità molto elevate, ma non necessariamente un alto grado di coerenza dei dati (la coerenza finale è ciò che conta). Una varietà di sistemi offre prestazioni e scalabilità migliori rispetto a un RDBMS riducendo la necessità di transazioni completamente conformi ad ACID. Questi sono stati chiamati "NoSQL", ma come altri sottolineano, questo è un termine improprio: che forse dovrebbero essere chiamati database NoACID.

Michael Stonebraker copre questo aspetto nella discussione "NoSQL" non ha nulla a che fare con SQL .