Esistono linguaggi di programmazione che dispongono di un database integrato come funzionalità di lingua di prima classe anziché connettersi a un database SQL esterno (o altro) esterno? Quali sarebbero gli svantaggi e i vantaggi di una tale funzione? Che aspetto avrebbe una tale caratteristica e come cambierebbe il modo in cui programmiamo?
L'unico linguaggio che posso pensare sono i vecchi linguaggi xBase come DBase, Clipper e FoxPro. C'è un progetto GNU che offre una versione gratuita e per lo più compatibile chiamata Clip
C'era anche Seleziona base che legava 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 i database sono "grandi"; quindi ogni volta che i due vengono combinati, non è una lingua con il database come funzionalità, ma un database con la lingua come funzionalità. Molti database hanno alcuni linguaggi proprietari attaccati a loro, ad es. PL / SQL, T-SQL.
Non penso necessariamente che la domanda giusta sia "perché non ci sono?" ma "perché dovrebbe esserci?". Cosa si otterrebbe dall'avere database come caratteristica della lingua? Ricorda, la lingua è in fondo allo stack di programmazione. Rendere gonfio un linguaggio colpisce tutto . Pertanto, i progettisti di linguaggi devono essere lenti nell'aggiungere nuove funzionalità, specialmente quelle che comportano un tale investimento.
Ci sono 3 sistemi legacy che sono vicini ai tuoi requisiti:
Pick e MUMPS sono stati sviluppati anni prima del primo documento accademico sui database relazionali (che era circa un decennio prima che il primo sistema di database commerciale basato su SQL lo rendesse disponibile sul mercato) da un'azienda che ora chiamiamo Oracle, il primo tentativo di IBM di il prodotto ha avuto un fiasco e un sistema basato su SQL di successo è stato più tardi). Potresti trovarli ancora in uso (il nostro sistema di trasporto pubblico locale 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 è "allontanati dalla tastiera con le mani in aria!" Se fai ha qualcosa a che fare con loro, la frase "ti scuserà" dovrebbe risuonare nelle tue orecchie.
Microsoft Access viene seriamente deriso e criticato nei circoli IT in quanto è abbastanza facile per un non sviluppatore realizzare un'app business critica da Access e farlo mutare in qualcosa di cui l'azienda non potrebbe letteralmente vivere senza. È anche abbastanza probabile che alcuni sviluppatori abbiano iniziato a sviluppare via MS Access e man mano che le cose si sono impantanate hanno imparato a risolverli (il primo passo è tradizionalmente l'apprendimento di base visiva e la riscrittura dell'app Access prima in VB, quindi in qualcosa di "migliore"). È possibile realizzare un'app Access ben gestita che funzioni distribuita con un'enorme quantità di dati - l'ho già vista - ma ci sono modi più semplici per fare le cose, e ci vuole molto meno abilità per fare (e mantenere) un pozzo app gestita da VB e SQL Server.
Da SQL Server 2005, Microsoft ha introdotto la capacità di mettere CLR in stored procedure e funzioni. E se vuoi essere complicato, puoi creare dei 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 e riflettono un modo COBOLY di guardare il mondo.
Il mio consiglio personale è di tenere le cose separate. Usa un linguaggio che sia in grado di manipolare i dati di cui il tuo progetto ha bisogno (con l'avvertenza che a volte la "migliore" lingua è quella che puoi facilmente trovare programmatori in grado di leggere / scrivere il codice). Utilizzare un sistema di database che sia in grado di conservare i dati necessari per il progetto.
L'aggiunta di un database in un linguaggio di programmazione potrebbe soddisfare solo un insieme molto ristretto di utenti. Cosa succede se vogliono utilizzare alcune funzionalità non RDBMS? O non vuoi usare un database? Il compilatore sarà inutilmente gonfio per questi 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 si vuole fare nei set grammati; in realtà non fornisce servizi come quello. :)
Detto questo, ci sono diversi motivi.
Costruire un efficiente sistema di archiviazione di database è un problema difficile, probabilmente nell'ordine di o maggiore rispetto alla costruzione di .NET Framework (per esempio). Se una squadra ha cercato di includere un database nel loro framework, questo sarebbe tutto ciò su cui hanno finito per lavorare.
Un database che viene caricato deve essere sulla propria macchina separata e non nel processo del codice che lo accede.
Gli ORM forniscono molti controlli di sicurezza di tipo e di compilazione che potrebbero essere il vantaggio di tale azione, senza che il framework cerchi di essere un database.
Detto questo, immagino sarebbe bello includere una sorta di implementazione SQLite all'interno del framework che le applicazioni con minori esigenze di accesso ai dati potrebbero operare contro. Non sono sicuro che sarebbe utile in applicazioni non banali, tuttavia.
Penso che la tua vera domanda sia "perché non ci sono linguaggi di programmazione forniti con database librerie ".
Le lingue di uso generale trattano tutto l'I / O come un unico e uguale, che si tratti di scrivere o leggere su / da un disco, una webcam, la rete, lo schermo, una posizione nella memoria - è tutto IO, ed è tutta quella programmazione le lingue si occupano di.
Infatti, a parte la lettura / scrittura sull'heap e sullo stack, la maggior parte dei linguaggi di programmazione non esegue nemmeno un IO effettivo. Alcune lingue forniscono funzionalità native per che esprimono operazioni IO (ad esempio print comando in BASIC), ma la maggior parte delle lingue le tratta come normali chiamate di funzione (ad esempio printf in C) e lascia che le librerie gestiscano la scrittura vera e propria.
Alcune lingue come C # offrono funzionalità linguistiche per l'espressione di query, ma anche in questo caso quelle sono solo espressioni sulla struttura di dati più basilare degli elenchi (o IEnumerable s, come vengono chiamati in .NET) che vengono tradotti in operazioni SQL dalle librerie - il linguaggio stesso funziona ancora 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 normalmente dipenderebbe dalla funzionalità del database.
Sì. Le lingue sulla piattaforma AS / 400 hanno 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 durante il percorso.
Dipende dalla lingua e dalla piattaforma. Ad esempio, per me è abbastanza semplice utilizzare una varietà di database mentre lavoro con C, ma uso solo la libreria appropriata.
Un linguaggio deve mantenere la sua implementazione standard, e questo in genere significa fornire l'importo minimo necessario affinché qualcuno sia in grado di costruire qualsiasi cosa vogliano costruire. Tutto il resto diventa una libreria, o forse un'estensione della lingua che viene mantenuta da altri.
Almeno, questo è il caso per le lingue che seguono standard stabiliti da organizzazioni come ISO.
Come scritto, la domanda è in parte errata, come hanno mostrato alcuni controesempi precedenti.
Quindi per prima cosa dovrei affinare la domanda: "Perché un DBMS di solito non è integrato come caratteristica di un linguaggio di programmazione generale ad alto livello?"
Questo è per lo stesso motivo per cui altri prodotti software come sistemi operativi, file system, server Web, livelli di memorizzazione nella cache, ecc. di solito non sono integrati. Le lingue di uso generale generalmente operano a un livello di astrazione superiore a quello di tali prodotti. Quindi è ragionevole per un programmatore implementare un DBMS in un linguaggio generico e che DBMS potrebbe anche esporre aspetti della sua lingua madre o un linguaggio dichiarativo specifico del DB per l'uso da parte dei programmatori di 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'entanglement dei due risulta in un intero settore impantanato in un problema chicken-and-egg, bloccato con un DBMS obsoleto e un linguaggio di programmazione obsoleto.
Utilizzato per lavorare 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 su cui sono stati eseguiti i computer.
Penso che sia probabilmente l'integrazione più vicina che puoi ottenere, dove 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 possono mai essere usati separatamente, portati su un altro ambiente.
Il più vicino che avremo sul PC sarà probabilmente MS Access, Embarcadero / Borland Delphi essendo un secondo vicino.
Dopodiché, stai osservando i database incorporati nella tua applicazione, che possono avere un limitato interesse per coloro che creano applicazioni standalone che necessitano di un insieme di dati gerarchici che non sono facilmente archiviati in un semplice file di configurazione e / o necessitano di aggiornamenti regolari come l'applicazione funziona. 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ò effettuare la connessione (utile per dire un venditore che è spesso fuori dalla portata di la rete aziendale ha ancora bisogno di dati di vendita per il suo gruppo di clienti, o di un dottore nel campo che desidera record 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, mi sembra strano che nessun linguaggio mainstream definisca il modello relazionale come parte del linguaggio.
Avere il motore di database completo non è una buona idea, ma avere il linguaggio "SQL" potrebbe essere MOLTO utile.
In OO, esiste la mancata corrispondenza dell'impedenza. Questo è accaduto perché oggetti e set non si assomigliano. Ma se una lingua mi consente di definire TABELLE, CAMPI, RELAZIONI, VINCITORI, ecc. (Senza legarlo a un particolare spazio di archiviazione) sarà molto potente. Inoltre, la creazione di un ORM sarà più una mappatura 1-a-1.
Leggi altre domande sui tag programming-languages database language-design language-features