Programmazione unificante e query del database [chiuso]

Prendi in considerazione un tutorial comune per linguaggi di programmazione orientati agli oggetti come C ++ o Java: crea un semplice sistema di elaborazione degli ordini con oggetti che rappresentano account, ordini, articoli ecc. (O qualcosa di più o meno equivalente). Ha un perfetto senso intuitivo, ma l'elefante al tavolo da pranzo è che non è reale perché si tratta di oggetti in memoria; in un sistema reale, gli account, gli ordini ecc . non vivono in realtà nella memoria in primo luogo, vivono in un database, con la rappresentazione della memoria solo un suo specchio di breve durata.

Puoi scrivere un sacco di codice per leggere e scrivere dal database, ma è così noioso e soggetto a errori che nessuno lo fa davvero.

Tutti finiscono per usare un ORM, ma quelli sono così problematici di per sé che un famoso documento li chiama "il Vietnam del nostro settore".

Non penso che sia una discrepanza tra oggetto e relazione tanto quanto una discrepanza tra il linguaggio di programmazione e il database essendo cose separate che non si conoscono . Congettura: la soluzione è quella di avere un unico linguaggio che sia sia il linguaggio di programmazione che quello della query del database, il che a sua volta richiederebbe che il runtime della lingua sia anche il database e che il compilatore JIT sia anche l'ottimizzatore delle query.

Quindi questo è il riassunto dei problemi che lo vedo. La mia domanda è: qualcuno ha ancora

1. In realtà costruito un tale sistema unificato

2. Ho provato ma non sono riuscito a costruire un tale sistema unificato

3. Ho scritto qualcosa di sostanziale sull'argomento di come faresti per costruirlo, o perché o perché no

4. Ti viene in mente un modo alternativo per risolvere il problema?

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

La persistenza dei dati è un argomento estremamente complesso. E così sono i linguaggi di programmazione. La combinazione dei due comporterebbe un'esplosione della complessità. Ci vorrebbe molto sforzo per renderli entrambi abbastanza buoni da permettere alle persone di usarli davvero. Penso che già menzionato MUMPS sia un buon esempio. Oppure puoi guardare varie varianti SQL che hanno il linguaggio completo imbullonato 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 sia di essere cambiati che di evolversi nel tempo. Ad esempio, SQL è vecchio e non è cambiato molto da quando è stato creato. Ma le lingue utilizzate per eseguire le applicazioni sono cambiate drasticamente nello stesso periodo. E ora sta accadendo il contrario. Le lingue rimangono per lo più le stesse mentre i database vengono modificati ed evoluti.

La distribuzione in fase di esecuzione è un altro problema. La combinazione dei due significherebbe che sia il database che l'applicazione o il server Web dovrebbero essere eseguiti nello stesso processo. Ciò è estremamente limitante, sia dal punto di vista della manutenzione sia dalla capacità di eseguirli su computer separati o in relazioni multiple.

Dividere i due in moduli separati con una chiara API tra loro è il modo migliore per mantenere bassa la complessità e darti flessibilità in quali tecnologie vuoi usare e come vengono distribuiti i pezzi finali.

Sembra che tu stia facendo alcune ipotesi importanti. Ad esempio, stai supponendo che tutti stiano scrivendo su database relazionali. Semplicemente non è così, ci sono molti esempi di database di altri tipi (oggetti dbs, documenti 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. Tutti 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'è molta discussione in vari luoghi su quali motori DB siano migliori in quali contesti e perché, troppo per lo scopo di questa risposta, per includere una domanda chiusa proprio su questo sito. Il risultato è che ognuno di essi è ottimizzato 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 stanno cambiando recentemente come cambiano architetture e requisiti).

Vale anche la pena notare che prima c'erano davvero molti approcci "tutto in uno". Le lingue dei mainframe avevano spesso la propria logica di persistenza incorporata e ci sono lingue come Smalltalk che non distinguono affatto tra codice e dati. Ancora una volta, sono spesso utili per alcuni casi d'uso, ma non per tutti.

1. Sì (non io). Si chiamava MUMPS .

2. Secondo questa precedente domanda SE.SE , o questo articolo , i MUMP non sono stati progettati molto bene. Ma è stato effettivamente utilizzato nel settore sanitario (e immagino che ci siano ancora sistemi esistenti che lo utilizzano), quindi non un fallimento totale.

3. Troverai sicuramente informazioni a riguardo ora che sai cosa cercare. Inizia con il link Wikipedia sopra.

4. Cerca database orientati agli oggetti, molti dei quali sono specifici della lingua. Hanno cercato di affrontare la discrepanza relazionale agli oggetti in modo più semplice rispetto agli ORM.

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

Smalltalk è probabilmente il più vicino a ciò che descrivi. Gli oggetti in memoria sono persistenti in una "immagine", quindi l'ambiente linguistico può essere utilizzato immediatamente come un database (oggetto). E la maggior parte del linguaggio moderno ha una sorta di meccanismo di persistenza incorporato, il che significa che gli oggetti nell'ambiente linguistico possono essere persistenti 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 della condivisione dello stesso spazio di memoria, il che ovviamente pone 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 di linguaggio specifico e consentono di persistere e interrogare oggetti nella lingua stessa.

Dal lato relazionale delle cose abbiamo linguaggi come T-SQL che è un linguaggio di programmazione a tutti gli effetti che è un superset di SQL, quindi l'interrogazione e il DML possono essere mescolati con una logica procedurale complessa arbitraria. Complesse applicazioni aziendali sono state costruite utilizzando T-SQL, quindi questo è certamente fattibile, ma l'attuale tendenza è quella della logica aziendale procedurale lontano dal database.

In questi casi è davvero molto elegante e conveniente avere il database integrato con il linguaggio di programmazione ed evitare la "mancata corrispondenza dell'impedenza". Quindi perché le persone usano ancora database relazionali separati dall'ambiente di programmazione e provano a collegarsi con alcuni ORM-kludge?

Si scopre che ci sono una serie di vantaggi nell'avere dati e query separati da qualsiasi linguaggio di programmazione e ambiente 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 frontend Web, da uno strumento di assistenza clienti, da un motore di reporting e così via. I dati stessi sono spesso di lunga durata, mentre le applicazioni vanno e vengono. L'accoppiamento dei dati a un ambiente di programmazione specifico sarebbe bloccato in un ambiente di programmazione specifico. Ma i linguaggi di programmazione vanno e vengono, mentre i dati vivono per sempre.
• Interrogazioni ad hoc. È estremamente conveniente essere in grado di aprire un prompt del database e scrivere una query. Se le query fossero strettamente legate all'ambiente di programmazione, questo sarebbe un compito di programmazione e solo gli sviluppatori sarebbero in grado di farlo.
• Evitare il blocco. Poiché SQL è uno standard, più fornitori possono fornire sistemi di gestione del database più o meno intercambiabili. Questo evita il blocco del fornitore e semplifica il confronto dei prodotti.
• Accoppiamento lasco. Avere un'interfaccia ben definita tra il livello dell'applicazione e il database consente di 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 standardizzati per la creazione di profili, la replica, l'analisi e così via.

È una buona domanda che stavo elaborando molte volte nella mia testa. Un esempio di una soluzione esistente che risolve il problema è un database grafico ArangoDB in cui si utilizza JavaScript (in esecuzione su un motore interno) per scrivere controller in grado di generare intere pagine Web. I dati vengono passati a / dalla memoria tramite JSON, quindi sono nativamente accessibili 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 controller non dovrebbero essere esposti al pubblico per motivi di sicurezza poiché un difetto nella configurazione del database o un bug comporteranno l'esposizione dei dati preziosi al pubblico.

Secondo la mia opinione personale, questo è un buon approccio e considerando se il database supporta una sorta di funzione mappa / riduzione che aggiornerà dati aggregati / indici di testo e altri dati frequentemente interrogati in tempo reale, aggiungendo un sottile livello di sicurezza tra (chiamalo carico bilanciamento) renderebbe un'applicazione funzionale in esecuzione in un database distribuito.

1. In realtà costruito un tale sistema unificato

Sì, l'ho fatto in Sciter .

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

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

Dov'è ndb.rootl'oggetto normale in termini di JS. Tutte le sue proprietà e oggetti secondari 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 vengono archiviati nel DB sul ciclo GC, quando non c'è memoria sufficiente o su ndb.commit()chiamata esplicita .

Storageclasse è accompagnato da Indexclasse - è una serie di oggetti persistibili ordinate con chiavi univoche / non univoco.

Il set di funzionalità è simile a MongoDB o ad altri database NoSQL ma l'id non richiede un ORM separato: l'accesso al db viene effettuato esclusivamente tramite script.

Sono assolutamente per questo e non ho idea da dove cominciare. L'SQL può essere brillante e immagino che sarebbe fantastico 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, god forbid, un ORM).

L'unico sistema che si avvicina alla tua idea che conosco si chiama aquameta (tag line: "stack di sviluppo web costruito in PostgreSQL"; vedi https://github.com/aquametalabs/aquameta , http://aquameta.org ). Ci sono alcuni video introduttivi che non sono un po 'meno folli 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 dire che hanno implementato il proprio editor e il proprio sistema di controllo delle versioni all'interno di Postgres.

Penso che questa fosse esattamente la logica dell'invenzione di LINQ da parte di Microsoft. È stato in uso su vasta scala per diversi anni, quindi è facile trovare letteratura a riguardo e riflessioni da esperienze del mondo reale, sia positive che negative. (La maggior parte dei negozi di sviluppo .net lo abbraccia.)

Un buon punto di partenza su linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/