Unifying programming and database query [closed]

Questa è la mia opinione. Mentre vedo da dove vieni, non riesco a vederlo accadere dal punto di vista del design.

La persistenza dei dati è un argomento estremamente complesso. E così anche i linguaggi di programmazione. Combinare i due porterebbe a un'esplosione di complessità. Ci vorrebbe un sacco di sforzi per rendere effettivamente entrambi abbastanza buoni per le persone che vogliono davvero usarlo. Penso che sia già stato citato MUMPS come buon esempio. Oppure puoi guardare le varie varianti SQL che hanno il linguaggio completo fissato su di esse. Potrebbero essere utilizzabili, ma non credo che le persone li userebbero volentieri.

Quindi separarli è un modo chiaro per risolvere questa complessità. Inoltre, non legandoli insieme, consente di modificarli e evolversi nel tempo. Ad esempio, SQL è vecchio e non è cambiato molto da quando è stato creato. Ma i linguaggi utilizzati per eseguire le applicazioni sono cambiati drasticamente nello stesso periodo. E ora sta accadendo l'opposto. Le lingue restano per lo più le stesse mentre i database vengono modificati ed evoluti.

La distribuzione del runtime è un altro problema. Combinare i due significherebbe che sia il database che l'applicazione o il server web dovrebbero essere eseguiti in uno stesso processo. Questo è estremamente limitante, sia dal punto di vista della manutenzione che dalla possibilità di eseguirli su computer separati o in relazioni molti-a-uno.

La suddivisione dei due in moduli separati con API chiara tra di essi è il modo migliore per ridurre la complessità e darti flessibilità su quali tecnologie vuoi utilizzare e su come vengono distribuiti i pezzi finali.

Sembra che tu stia facendo alcune ipotesi importanti. Ad esempio, si presume che tutti stiano scrivendo su database relazionali. Semplicemente non è così, ci sono molti esempi di database di altri sapori (oggetto dbs, documento dbs, ecc.) Che usano un linguaggio di programmazione nativo per scrivere tutto il codice e gestire la persistenza.

Ad esempio, Db4O è compatibile con Java e C #, ObjectDB in Java, VelocityDB in una varietà di lingue. I driver di MongoDB finiscono per farti scrivere cose nel tuo linguaggio di programmazione nativo (bonus se stai facendo JavaScript, poiché ciò significa che anche la shell usa la stessa sintassi), e così via.

C'è un sacco di discussioni in vari punti su quali motori DB sono migliori in quali contesti, e perché, troppo per lo scopo di questa risposta, per includere una domanda chiusa su questo stesso sito. Il risultato è che sono ottimizzati per cose diverse, e fino a poco tempo fa SQL era considerato una sorta di "minimo comune denominatore" per le applicazioni aziendali perché si ottiene molto gratuitamente in termini di ACID e prestazioni (anche se entrambi cambiano di recente con il cambiamento delle architetture e dei requisiti).

Vale anche la pena notare che in realtà esistevano già molti approcci "tutto in uno". I linguaggi mainframe avevano spesso la propria logica di persistenza integrata, e ci sono linguaggi come Smalltalk che non distinguono affatto tra codice e dati. Di nuovo, sono spesso buoni per alcuni casi d'uso ma non tutti.

1. Sì (non a me). Si chiamava MUMPS .

2. In base a questa domanda precedente SE.SE o questo articolo , i MUMP non sono stati progettati molto bene. Ma è stato effettivamente utilizzato nel settore sanitario (e credo che esistano ancora sistemi che lo utilizzano), quindi non un fallimento totale.

3. Troverete sicuramente informazioni a riguardo ora sapete per cosa cercare. Inizia con il link di Wikipedia sopra.

4. Ricerca di database orientati agli oggetti, molti dei quali sono specifici della lingua. Hanno cercato di affrontare la mancata corrispondenza relazionale tra oggetti in modi più semplici rispetto agli ORM.

Esistono infatti più sistemi che unificano database e linguaggio di programmazione in un singolo ambiente.

Smalltalk è probabilmente il più vicino a ciò che descrivi. Gli oggetti in memoria sono mantenuti in una "immagine", quindi l'ambiente del linguaggio può essere utilizzato come un (oggetto) database fuori dalla scatola. E la maggior parte del linguaggio moderno ha una sorta di meccanismo di persistenza incorporato che significa che gli oggetti nell'ambiente linguistico possono essere mantenuti e interrogati usando il linguaggio stesso.

Questo è molto conveniente per le applicazioni per utente singolo. Ma l'approccio non si ridimensionerà a più utenti, poiché avranno bisogno di condividere lo stesso spazio di memoria, il che ovviamente mette un limite alla quantità di utenti. Una soluzione scalabile richiede un server di database separato che gestisca la concorrenza. Anche in questo caso, esistono più database NoSql che si integrano con un ambiente linguistico specifico e consentono di mantenere e interrogare gli oggetti nella lingua stessa.

Dal lato relazionale delle cose abbiamo linguaggi come T-SQL che è un linguaggio di programmazione completo che è un superset di SQL, quindi l'interrogazione e il DML possono essere mescolati con una logica procedurale arbitraria complessa. Le applicazioni aziendali complesse sono state create utilizzando T-SQL, quindi è certamente fattibile, ma la tendenza attuale è la logica aziendale procedurale away dal database.

In questi casi è davvero molto elegante e comodo avere il database integrato con il linguaggio di programmazione ed evitare il "mismatch di impedenza". Quindi, perché le persone usano ancora i database relazionali separati dall'ambiente di programmazione e cercano di creare un ponte con alcuni ORM-kludge?

Risulta che ci sono una serie di vantaggi nell'avere dati e query separati da qualsiasi linguaggio e ambiente di programmazione specifici.

• Indipendenza dei dati. Nella maggior parte delle organizzazioni, i dati sono effettivamente accessibili da più applicazioni. Un negozio potrebbe avere un database utilizzato dal front-end Web, uno strumento di assistenza clienti, un motore di reporting e così via. I dati stessi sono spesso longevi, mentre le applicazioni vanno e vengono. Accoppiare i dati a un ambiente di programmazione specifico sarebbe il lock-in in uno specifico ambiente di programmazione. Ma i linguaggi di programmazione vanno e vengono, mentre i dati vivono per sempre.
• query ad hoc. È estremamente comodo essere in grado di aprire un prompt del database e scrivere una query. Se le query fossero strettamente collegate all'ambiente di programmazione, questo sarebbe un compito di programmazione e solo gli sviluppatori sarebbero in grado di farlo.
• Evita il lock-in. Poiché SQL è uno standard, più fornitori possono fornire sistemi di gestione di database più o meno intercambiabili. Ciò evita il blocco del fornitore e semplifica il confronto dei prodotti.
• Accoppiamento lento. Avere un'interfaccia ben definita tra il livello dell'applicazione e il database rende possibile ottimizzare e ottimizzare il database indipendentemente dalla logica dell'applicazione.
• Interfaccia condivisa. Poiché l'interfaccia del database è indipendente dalla logica dell'applicazione, è possibile utilizzare strumenti standard per la profilazione, la replica, l'analisi e così via.

È una buona domanda che stavo elaborando nella mia testa molte volte. Un esempio di una soluzione esistente che risolve il problema è un database grafico ArangoDB in cui si utilizza JavaScript (in esecuzione sul motore interno) per scrivere controller che possono generare intere pagine web. I dati vengono passati a / dalla memoria utilizzando JSON, quindi è nativamente accessibile in JavaScript e le query vengono eseguite in un linguaggio di query incorporato. Quindi questo caso è un esempio di estensione di JavaScript da eseguire nel database.

In pratica tali controllori non dovrebbero essere esposti al pubblico per motivi di sicurezza come difetto nella configurazione del database o un bug risulterà nell'esporre i tuoi preziosi dati al pubblico.

A mio parere personale questo è un buon approccio e considerando se il database supporta un tipo di funzione mappa / riduzione che aggiornerà gli indici aggregati di dati / testo e altri dati frequentemente interrogati in tempo reale, aggiungendo un sottile strato di sicurezza intermedio ( chiamalo load balancer) renderebbe un'applicazione funzionale in esecuzione in un database distribuito.

1. Actually built such a unified system

Sì, l'ho fatto in Sciter .

Lo script di Sciter è un " JavaScript ++ " che ha persistenza integrata:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Dove ndb.root è normale Oggetto in termini di JS. Tutte le sue proprietà e sotto-oggetti accessibili da esso sono permanenti - memorizzati e recuperati nel DB quando necessario - in modo trasparente per il codice:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

I dati sono archiviati in DB sul ciclo GC, quando non c'è abbastanza memoria o su esplicita chiamata ndb.commit() .

La classe Storage è accompagnata da Index classe - insiemi di oggetti ordinati persistibili con chiavi univoche / non univoche.

Il set di funzionalità è simile a MongoDB o altri database NoSQL ma l'ID non richiede ORM separato - l'accesso a db viene effettuato con mezzi puramente script.

Sono assolutamente d'accordo e non ho idea da dove cominciare. SQL può essere brillante e immagino sarebbe bello avere tutto quel potere e le garanzie transazionali proprio nel tuo linguaggio di programmazione per tutti gli usi (invece di dover scrivere query come raccolte di stringhe o usare, dio non voglia, un ORM).

L'unico sistema che si avvicina alla tua idea che conosco si chiama aquameta (tag line: "web dev stack costruito in PostgreSQL"; vedi link , collegamento ). Ci sono alcuni video introduttivi che non sono un po 'meno pazzi dell'idea stessa (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg ), e quando dico pazzo, intendo che hanno implementato il proprio editor e il proprio sistema di controllo delle versioni all'interno di Postgres.

Penso che questa fosse esattamente la ragione per l'invenzione di Microsoft di LINQ. È stato utilizzato per diversi anni nella produzione su larga scala, quindi è facile trovare letteratura su di esso e riflessioni dalle esperienze del mondo reale, sia positive che negative. (La maggior parte dei negozi di sviluppo .net lo abbracciano.)

Un buon punto di partenza su linq: link