Perché i database non sono integrati come funzionalità linguistica?

Esistono linguaggi di programmazione che hanno un database integrato come funzionalità di linguaggio di prima classe piuttosto che connettersi a un database SQL esterno (o altro)? Quali sarebbero gli svantaggi e i vantaggi di una tale funzionalità? Come sarebbe una caratteristica del genere e come cambierebbe il modo in cui programmiamo?

L'unica lingua a cui riesco a pensare sono i vecchi linguaggi xBase come DBase, Clipper e FoxPro. Esiste un progetto GNU che offre una versione gratuita e per lo più compatibile chiamata Clip

Era anche Pick Basic che collegava un linguaggio di programmazione direttamente a una piattaforma di database.

Questo è stato fatto. Era un vicolo cieco evolutivo che limitava il modo in cui una lingua poteva accedere ai dati.

Le lingue sono "piccole" e le banche dati sono "grandi"; quindi ogni volta che i due sono combinati, non è una lingua con il database come funzionalità, ma un database con la lingua come funzionalità. Molti database dispongono di alcuni linguaggi proprietari, ad esempio PL / SQL, T-SQL.

Non penso necessariamente che la domanda giusta sia "perché non ci sono?" ma "perché dovrebbe esserci?". Cosa si otterrebbe se i database fossero una caratteristica della lingua? Ricorda, la lingua è in fondo allo stack di programmazione. Far gonfiare una lingua influenza tutto . Pertanto, i progettisti del linguaggio devono essere lenti ad aggiungere nuove funzionalità, in particolare quelle che implicherebbero un tale investimento.

Esistono 3 sistemi legacy vicini alle tue esigenze:

1. Scegli ,
2. MUMPS ,
3. accesso Microsoft

Pick e MUMPS sono stati sviluppati anni prima che il primo documento accademico sui database relazionali (che era circa un decennio prima che il primo sistema di database commerciale basato su SQL arrivasse sul mercato - da una società che ora chiamiamo Oracle; il primo tentativo di IBM di un prodotto si è esaurito e un sistema basato su SQL di successo è stato successivamente). Potresti trovarli ancora in uso (il nostro sistema di trasporto pubblico locale ha utilizzato Pick fino a poco tempo fa per il sistema di pianificazione del viaggio). Non vuoi avere niente a che fare con Pick o MUMPS e il miglior consiglio che posso dare è "allontanarti dalla tastiera con le mani in aria!" Se fare avere a che fare con loro, la frase "Te ne pentirai" dovrebbe essere un ronzio nelle orecchie.

Microsoft Access viene gravemente deriso e criticato nei circoli IT in quanto è abbastanza facile per un non sviluppatore trasformare un'app aziendale critica fuori da Access e trasformarla in qualcosa di cui la società non può letteralmente vivere. È anche molto probabile che alcuni sviluppatori abbiano iniziato a svilupparsi tramite MS Access e man mano che le cose si impantanavano, hanno imparato a risolverli (il primo passo è tradizionalmente l'apprendimento di Visual Basic e la riscrittura dell'app di Access prima in VB, quindi in qualcosa di "migliore"). È possibile creare un'app di Access ben gestita che viene distribuita con un'enorme quantità di dati - l'ho visto fare - ma ci sono modi più semplici per fare le cose e ci vuole molta meno abilità per fare (e mantenere) un pozzo app comportata da VB e SQL Server.

Da SQL Server 2005, Microsoft ha introdotto la capacità di inserire CLR in stored procedure e funzioni. E se vuoi essere complicato, potresti creare tipi di dati che potresti utilizzare come colonne nel database. Penso che Oracle abbia avuto qualcosa di simile con Java.

Detto questo, non penso che ci sia qualcosa che ti impedisce di crearne uno o di ipotizzare su di loro. Pick e MUMPS sono più vecchi della maggior parte dei programmatori qui e riflettono un modo molto COBOLy di guardare il mondo.

Il mio consiglio personale è di tenere le cose separate. Usa una lingua che è brava a manipolare i dati di cui il tuo progetto ha bisogno (con l'avvertenza che a volte la lingua "migliore" è quella che puoi facilmente trovare programmatori in grado di leggere / scrivere il codice). Utilizzare un sistema di database in grado di conservare i dati necessari al progetto.

L'aggiunta di database in un linguaggio di programmazione potrebbe soddisfare solo un numero molto ristretto di utenti. E se vogliono usare alcune funzionalità non RDBMS? O non vuoi usare affatto un database? Il compilatore sarà inutilmente gonfiato per tali casi d'uso.

Err.

Bene, in primo luogo, ti stai chiedendo perché il framework in cui opera la lingua non fornisce un database. Una lingua è semplicemente un mezzo per esprimere qualcosa che vuoi fare in grammatiche prestabilite; non fornisce realmente servizi del genere. :)

Detto questo, ci sono diverse ragioni.

• La creazione di un sistema di archiviazione di database efficiente è un problema difficile, probabilmente nell'ordine o superiore alla creazione di .NET Framework (ad esempio). Se un team cercasse di includere un database nel proprio framework, sarebbe tutto ciò su cui avrebbero finito per lavorare.

• Un database che viene caricato dovrebbe trovarsi su una propria macchina separata e non nel processo del codice a cui accede.

• Gli ORM forniscono un sacco di sicurezza del tipo e controllo del tempo di compilazione che sarebbe il vantaggio di tale azione, senza che il framework tenti di essere un database.

Detto questo, immagino che sarebbe opportuno includere una sorta di implementazione di SQLite nel framework contro cui potrebbero funzionare le applicazioni con esigenze minori di accesso ai dati. Non sono sicuro che sarebbe utile in applicazioni non banali, tuttavia.

loro sono; tali lingue sono chiamate 4GL . DataFlex è il mio preferito, anche se non lo uso più.

Avvertenza: ho contribuito a sviluppare la versione orientata agli oggetti di DataFlex, v3.0

Penso che la tua vera domanda sia "perché non ci sono linguaggi di programmazione forniti con le librerie di database ".

I linguaggi per scopi generici trattano tutti gli IO come uno stesso, sia che si tratti di scrivere o leggere su / da un disco, una webcam, della rete, dello schermo, di una posizione in memoria: è tutto IO, ed è tutto ciò che i linguaggi di programmazione riguardano se stessi con.

Infatti, oltre a leggere / scrivere nell'heap e nello stack, la maggior parte dei linguaggi di programmazione non esegue nemmeno alcun IO reale. Alcune lingue offrono funzionalità native per esprimere operazioni di I / O (ad es. Il print comando in BASIC), ma la maggior parte delle lingue le tratta semplicemente come normali chiamate di funzione (ad es. printfIn C) e consente alle librerie di gestire la scrittura effettiva.

Alcuni linguaggi come C # offrono funzionalità linguistiche per esprimere query, ma anche in questo caso, si tratta solo di espressioni sulla struttura dei dati più semplice di elenchi (o IEnumerables, come vengono chiamati in .NET) che vengono tradotti in operazioni SQL dalle librerie - il linguaggio stesso sta ancora lavorando con nozioni molto astratte di IO.

Per quanto riguarda il motivo per cui la creazione di un pacchetto di database nella libreria standard di un linguaggio di programmazione non è una buona idea, è molto probabile perché nient'altro in una libreria standard dipenderebbe normalmente dalla funzionalità del database.

Sì. Le lingue sulla piattaforma AS / 400 hanno un supporto nativo di prima classe per i database.

Questo perché la piattaforma AS / 400 ha il database completamente integrato ovunque e consente molte funzioni molto carine, come la facilità di navigazione attraverso un set di risultati che aggiorna i valori lungo il percorso.

Dipende dalla lingua e dalla piattaforma. Ad esempio, è abbastanza banale per me utilizzare una varietà di database mentre lavoro con C, utilizzo solo la libreria appropriata.

Una lingua deve mantenere la sua implementazione standard e ciò significa in genere fornire la quantità minima necessaria affinché qualcuno possa costruire tutto ciò che vuole costruire. Tutto il resto diventa una biblioteca, o forse un'estensione della lingua gestita da altri.

Almeno, questo è il caso delle lingue che seguono gli standard stabiliti da organizzazioni come ISO.

Come scritto, la domanda è parzialmente sbagliata, come hanno dimostrato alcuni controesempi sopra.

Quindi, per prima cosa affinare la domanda: "Perché un DBMS di solito non è integrato come caratteristica di un linguaggio di programmazione di alto livello per scopi generici?"

Questo è per lo stesso motivo per cui altri prodotti software come sistemi operativi, file system, web server, livelli di cache, ecc. Di solito non sono integrati. Le lingue di uso generale operano generalmente a un livello di astrazione superiore a quello di tali prodotti. Quindi è ragionevole per un programmatore implementare un DBMS inun linguaggio di uso generale e che DBMS potrebbe persino esporre aspetti della sua lingua madre o di un linguaggio dichiarativo specifico del DB per l'utilizzo da parte dei programmatori DB. Ma ci sono troppe opzioni di progettazione nella scrittura di un DBMS perché sia ​​saggio correggerle in un linguaggio di programmazione generico. Se li risolvi, finisci con un caso come MUMPS, in cui l'intreccio dei due risultati in un intero settore si è impantanato in un problema di gallina e uovo, bloccato con un DBMS obsoleto e un linguaggio di programmazione obsoleto.

Utilizzato per funzionare in NonStop / SQL che era completamente integrato in NonStop / C, NonStop / C ++, NonStop / Cobol, NonStop / Fortran e probabilmente in altre lingue, oltre ad essere completamente integrato con NonStop / Guardian, il sistema operativo su cui i computer corse.

Penso che sia probabilmente l'integrazione più vicina che puoi ottenere, in cui il database è il filesystem del sistema operativo. È anche un vicolo cieco, non c'è modo di disaccoppiare nessuno dei componenti, il database, il sistema operativo, l'hardware e qualsiasi software scritto su di esso non può mai essere utilizzato separatamente, portato su un altro ambiente.

Il più vicino che otterrai su un PC sarebbe probabilmente MS Access, Embarcadero / Borland Delphi al secondo posto.

Successivamente, stai esaminando i database incorporati nella tua applicazione, che possono avere un fascino limitato per coloro che creano applicazioni autonome che richiedono un set di dati gerarchici che non sono facilmente archiviati in un semplice file di configurazione e / o necessitano di aggiornamenti regolari durante l'esecuzione dell'applicazione . O per le persone che desiderano avere una versione portatile di un'applicazione che mantenga un'istantanea di una parte di un database più grande e magari la sincronizzi con il database più grande nei momenti in cui l'applicazione può stabilire una connessione (utile per dire un venditore che è spesso fuori portata la rete aziendale ha ancora bisogno dei dati di vendita per il suo gruppo di clienti, o un dottore sul campo che desidera i dati dei pazienti ma non può connettersi alla rete dell'ospedale perché non c'è accesso alla rete dove deve andare).

Come ex sviluppatore di Visual Foxpro, è difficile che nessun linguaggio tradizionale definisca il modello relazionale come parte del linguaggio.

Avere il motore di database completo non è una buona idea, ma avere il linguaggio "SQL" invece potrebbe essere MOLTO utile.

In OO esiste la mancata corrispondenza dell'impedenza. Ciò è accaduto perché gli oggetti e gli oggetti non si sovrappongono. Ma se una lingua mi permetta di definire TAVOLI, CAMPI, RELAZIONI, VINCOLI, ecc. (Senza legarlo a un particolare archivio) sarà molto potente. Inoltre, fare un ORM sarà più mappatura 1 a 1.