Primi 11 database open source per il tuo prossimo progetto

I dati sono tutto. E per estensione, lo sono anche i database. Ecco alcune fantastiche opzioni open source per il tuo prossimo progetto kick-ass.


Per un mondo dominato così a lungo da database come Oracle e SQL Server, ora sembra esserci una raffica infinita di soluzioni. Una parte del motivo è l’innovazione alimentata dall’Open Source – sviluppatori di grande talento che vogliono grattarsi un prurito e creare qualcosa in cui poter divertirsi.

L’altra parte è l’emergere di nuovi modelli di business, in cui le aziende mantengono una versione comunitaria del loro prodotto per ottenere la condivisione della mente e la trazione, fornendo anche un’offerta commerciale aggiuntiva.

Il risultato?

Più database di quanti ne possano tenere il passo. Non ci sono statistiche ufficiali su questo, ma sono abbastanza sicuro che oggi abbiamo oltre un centinaio di opzioni disponibili se combini di tutto, dai database di oggetti specifici dello stack a progetti non così popolari dalle università.

Lo so, mi spaventa anche. Troppe opzioni – troppa documentazione da attraversare – e una vita così breve. ��

Ecco perché ho deciso di scrivere questo articolo, presentando dieci dei migliori database che puoi utilizzare per migliorare le tue soluzioni, sia per te che per gli altri.

No MySQL

Nota: questo elenco non conterrà MySQL, anche se è probabilmente la soluzione di database Open Source più popolare in circolazione.

Perché? Semplicemente perché MySQL è ovunque: è quello che tutti imparano per primi, è supportato praticamente da ogni CMS o framework là fuori ed è molto, molto buono per la maggior parte dei casi d’uso. In altre parole, MySQL non ha bisogno di essere “scoperto”. ��

Detto questo, tieni presente che le seguenti non sono necessariamente alternative a MySQL. In alcuni casi, potrebbero esserlo, mentre in altri rappresentano una soluzione completamente diversa per un’esigenza completamente diversa. Non ti preoccupare, poiché parlerò anche dei loro usi.

Nota speciale: compatibilità

Prima di iniziare, devo anche menzionare che la compatibilità è qualcosa che devi tenere a mente. Se hai un progetto che, per qualsiasi motivo, supporta solo un determinato motore di database, le tue scelte vengono praticamente prese in considerazione.

Ad esempio, se stai utilizzando WordPress, questo articolo non ti sarà utile. �� Allo stesso modo, coloro che gestiscono siti statici su JAMStack non guadagneranno nulla cercando alternative troppo sul serio.

Sta a te capire l’equazione di compatibilità. Tuttavia, se hai una lavagna vuota e l’architettura dipende da te, ecco alcuni consigli accurati.

PostgreSQL

Se vieni dalla terra di PHP (WordPress, Magento, Drupal, ecc.), Allora PostgreSQL ti suonerà estraneo. Tuttavia, questa soluzione di database relazionale esiste dal 1997 ed è la scelta migliore in comunità come Ruby, Python, Go, ecc..

In effetti, molti sviluppatori alla fine si “laureano” in PostgreSQL per le funzionalità che offre, o semplicemente per la stabilità. È difficile convincere qualcuno in una breve scrittura come questa, ma pensa a PostgreSQL come un prodotto ingegnosamente progettato che non ti delude mai.

Ci sono molti buoni client SQL disponibili per connettersi al database PostgreSQL per l’amministrazione e lo sviluppo.

Caratteristiche uniche

PostgreSQL ha diverse caratteristiche affascinanti rispetto ad altri database relazionali (in particolare, MySQL), come:

  • Tipi di dati integrati per array, intervallo, UUID, geolocalizzazione, ecc.
  • Supporto nativo per archiviazione documenti (stile JSON), XML e archiviazione valori-chiave (Hstore)
  • Replica sincrona e asincrona
  • Scriptable in PL, Perl, Python e altro
  • Ricerca full-text

I miei preferiti personali sono il motore di geolocalizzazione (che elimina il dolore quando si lavora con app basate sulla posizione – prova a trovare manualmente tutti i punti vicini e capirai cosa intendo) e il supporto per gli array (molti progetti MySQL sono annullati per mancanza di array, optando invece per le famigerate stringhe separate da virgola).

Quando usare PostgreSQL

PostgreSQL è sempre una scelta migliore rispetto a qualsiasi altro motore di database relazionale. Cioè, se stai iniziando un nuovo progetto e sei già stato morso da MySQL, è un buon momento per considerare PostgreSQL. Ho amici che hanno rinunciato a combattere i misteriosi errori di blocco transazionale di MySQL e sono andati avanti in modo permanente. Se decidi lo stesso, non esagererai.

PostgreSQL ha anche un chiaro vantaggio se hai bisogno di strutture NoSQL parziali per un modello di dati ibrido. Poiché l’archiviazione di documenti e valori-chiave è supportata in modo nativo, non è necessario cercare, installare, apprendere e gestire un’altra soluzione di database.

Quando non usare PostgreSQL

PostgreSQL non ha senso quando il tuo modello di dati non è relazionale e / o quando hai requisiti architetturali molto specifici. Ad esempio, si consideri Analytics, in cui vengono costantemente creati nuovi report da dati esistenti. Tali sistemi sono molto pesanti e soffrono quando viene loro imposto uno schema rigoroso. Certo, PostgreSQL ha un motore di archiviazione dei documenti, ma le cose iniziano a crollare quando si ha a che fare con set di dati di grandi dimensioni.

In altre parole, usa sempre PostgreSQL, a meno che tu non sappia al 100% quello che stai facendo! ��

Controlla questo SQL & Corso PostgreSQL per principianti se interessati a saperne di più.

MariaDB

MariaDB è stato creato in sostituzione di MySQL, dalla stessa persona che ha sviluppato MySQL.

Confuso?

Bene, in realtà, dopo che MySQL è stata rilevata da Oracle nel 2010 (acquisendo Sun Microsystems, che, per inciso, è anche il modo in cui Oracle è arrivata a controllare Java), il creatore di MySQL ha avviato un nuovo progetto open source chiamato MariaDB.

Perché tutti questi dettagli noiosi contano, chiedi? È perché MariaDB è stato creato dalla stessa base di codice di quella di MySQL (nel mondo open source, questo è noto come “biforcazione” di un progetto esistente). Di conseguenza, MariaDB viene presentato come sostituto “drop-in” per MySQL.

Cioè, se stai usando MySQL e vuoi migrare su MariaDB, il processo è così semplice che non ci crederai.

Sfortunatamente, tale migrazione è una strada a senso unico. Il ritorno da MariaDB a MySQL non è possibile e, se si tenta di usare la forza, è garantito il danneggiamento permanente del database!

Caratteristiche uniche

Mentre MariaDB è essenzialmente un clone di MySQL, non è strettamente vero. Sin dall’introduzione del database, le differenze tra i due sono aumentate. Al momento della stesura, l’adozione di MariaDB deve essere una decisione ponderata da parte vostra. Detto questo, ci sono molte cose nuove in corso in MariaDB che potrebbero aiutarti a fare questa transizione:

  • Veramente gratuito e aperto: poiché non esiste una singola entità aziendale che controlla MariaDB, puoi essere libero da improvvise licenze predatorie e altre preoccupazioni.
  • Diverse altre opzioni di motori di archiviazione per esigenze specifiche: ad esempio il motore Spider per transazioni distribuite; ColumnStore per il data warehousing di massa; il motore ColumnStore per archiviazione distribuita parallela; e molti altri ancora.
  • Miglioramenti della velocità su MySQL, soprattutto grazie al motore di archiviazione Aria per query complesse.
  • Colonne dinamiche per diverse righe in una tabella.
  • Migliori capacità di replica (ad esempio, replica multi-sorgente)
  • Diverse funzioni JSON
  • Colonne virtuali

. . . E molti altri ancora. È faticoso tenere il passo con tutte le funzionalità di MariaDB. ��

Quando usare MariaDB

Dovresti MariaDB se vuoi un vero sostituto di MySQL, vuoi rimanere sulla curva dell’innovazione e non hai intenzione di tornare di nuovo su MySQL. Un eccellente caso d’uso è l’uso di nuovi motori di archiviazione in MariaDB per integrare il modello di dati relazionali esistente del progetto.

Quando non usare MariaDB

La compatibilità con MySQL è l’unica preoccupazione qui. Detto questo, sta diventando sempre meno un problema dato che progetti come WordPress, Joomla, Magento, ecc., Hanno iniziato a supportare MariaDB. Il mio consiglio sarebbe di non usare MariaDB per ingannare un CMS che non lo supporta, poiché ci sono molti trucchi specifici del database che causano l’arresto anomalo del sistema facilmente.

CockroachDB

La squadra dietro CockroachDB sembra essere composta da masochisti. Con un nome di prodotto del genere, sicuramente vogliono rovesciare tutte le probabilità contro di loro e comunque vincere?

Bene, non proprio.

L’idea dietro “scarafaggio” è che è un insetto costruito per la sopravvivenza. Qualunque cosa accada: predatori, alluvioni, oscurità eterna, cibo in decomposizione, bombardamenti, lo scarafaggio trova il modo di sopravvivere e moltiplicarsi.

L’idea è che il team dietro CockroachDB (composto da ex ingegneri di Google) fosse frustrato con i limiti delle soluzioni SQL tradizionali quando si trattava su larga scala. Questo perché storicamente le soluzioni SQL dovevano essere ospitate su una singola macchina (i dati non erano così grandi). Per molto tempo, non c’era modo di costruire un cluster di database che eseguono SQL, motivo per cui MongoDB ha catturato così tanta attenzione.

Anche quando la replica e il clustering sono usciti in MySQL, PostgreSQL e MariaDB, nel migliore dei casi è stato doloroso. CoackroachDB vuole cambiarlo, portando sharding, clustering e alta disponibilità senza sforzo nel mondo di SQL.

Quando usare CockroachDB

CockroachDB è il sogno dell’architetto di sistema che diventa realtà. Se giuri per SQL e hai fatto sobbollire le capacità di ridimensionamento di MongoDB, adorerai CockroachDB. Ora puoi creare rapidamente un cluster, fare domande e dormire sonni tranquilli di notte. ��

Quando non usare CockroachDB

Meglio il diavolo che conosci di quello che non conosci. Con questo voglio dire, se il tuo RDBMS esistente sta funzionando bene per te e pensi di poter gestire i dolori di ridimensionamento che porta, segui. Per tutto il genio coinvolto, CockroachDB è un nuovo prodotto e non vorrai più lottare contro di esso in seguito. Un altro motivo importante è la compatibilità SQL: se stai facendo cose esotiche SQL e fai affidamento su di essa per cose critiche, CockroachDB presenterà troppi casi limite per i tuoi gusti.

D’ora in poi considereremo soluzioni di database non SQL (o NoSQL, come viene chiamato) per esigenze altamente specializzate.

Neo4j

Uno degli sviluppi più significativi dell’ultimo decennio sono i dati connessi. Il mondo che ci circonda non è suddiviso in tabelle, righe e scatole: è un casino enorme con tutto ciò che è collegato a quasi tutto il resto.

I social network sono un ottimo esempio e la creazione di un modello di dati simile utilizzando SQL o persino database basati su documenti è un incubo.

Questo perché la struttura dei dati ideale per queste soluzioni è il grafico, che è una bestia completamente diversa. E per questo, hai bisogno di un database grafico come Neo4j.

L’esempio sopra è stato preso direttamente dal sito Web Neo4j e mostra come gli studenti universitari sono collegati ai loro dipartimenti e corsi. Un simile modello di dati è semplicemente impossibile con SQL, poiché sarà difficile evitare loop infiniti e sovraccarichi di memoria.

Caratteristiche uniche

I database di grafi sono unici in sé e Neo4j è praticamente l’unica opzione per lavorare con i grafici. Di conseguenza, qualunque funzionalità abbia è unica. ��

  • Supporto per applicazioni transazionali e analisi dei grafici.
  • Capacità di trasformazione dei dati per digerire i dati tabulari su larga scala in grafici.
  • Linguaggio di query specializzato (Cypher) per l’interrogazione del database dei grafici
  • Funzionalità di visualizzazione e scoperta

È un punto controverso discutere quando usare Neo4j e quando no. Se hai bisogno di relazioni basate su grafici tra i tuoi dati, hai bisogno di Neo4j. ��

MongoDB

MongoDB è stato il primo database non relazionale a fare grandi ondate nel settore tecnologico e continua a dominare una buona dose di attenzione.

A differenza dei database relazionali, MongoDB è un “database di documenti”, il che significa che archivia i dati in blocchi, con i dati correlati raggruppati insieme nello stesso blocco. Questo è meglio compreso immaginando un’aggregazione di strutture JSON come questa:

Qui, a differenza di una struttura basata su tabella, i dettagli di contatto e i livelli di accesso di un utente risiedono all’interno dello stesso oggetto. Il recupero dell’oggetto utente recupera automaticamente i dati associati e non esiste un concetto di join. Ecco un’introduzione più dettagliata a MongoDB.

Caratteristiche uniche

MongoDB ha alcune serie (voglio quasi scrivere “kick-ass” per trasmettere l’impatto, ma non sarebbe corretto su un sito Web pubblico, forse) caratteristiche che hanno costretto molti architetti esperti ad abbandonare la terra relazionale per sempre:

  • Uno schema flessibile per casi d’uso specializzati / imprevedibili.
  • Sharing e cluster ridicolmente semplici. Devi solo impostare la configurazione per un cluster e dimenticartene.
  • L’aggiunta o la rimozione di un nodo da un cluster è semplicissima.
  • Blocchi transazionali distribuiti. Questa funzione mancava nelle versioni precedenti ma alla fine è stata introdotta.
  • È ottimizzato per le scritture molto veloci, rendendolo altamente adatto per i dati di analisi come sistema di memorizzazione nella cache.

Se sembro un portavoce di MongoDB, mi scuso, ma è difficile sopravvalutare i vantaggi di MongoDB. Certo, la modellazione dei dati NoSQL è inizialmente strana, e alcuni non se ne accorgono mai, ma per molti architetti vince quasi sempre su uno schema basato su tabella.

Quando usare MongoDB

MongoDB è un grande ponte crossover dal mondo strutturato e rigoroso di SQL a quello amorfo, quasi confuso di NoSQL. Eccelle nello sviluppo di prototipi, in quanto non esiste semplicemente uno schema di cui preoccuparsi e quando è davvero necessario ridimensionarlo. Sì, è possibile utilizzare un servizio SQL cloud per eliminare i problemi di ridimensionamento del database, ma è costoso!

Infine, ci sono casi d’uso in cui le soluzioni basate su SQL non funzioneranno. Ad esempio, se stai creando un prodotto come Canva, in cui l’utente può creare progetti arbitrariamente complessi ed essere in grado di modificarli in un secondo momento, buona fortuna con un database relazionale!

Quando non usare MongoDB

La completa mancanza di schema fornita da MongoDB può funzionare come un pozzo per coloro che non sanno cosa stanno facendo. Mancata corrispondenza dei dati, dati morti, campi vuoti che non dovrebbero essere vuoti: tutto questo e molto altro è possibile. MongoDB è essenzialmente un archivio dati “stupido” e, se lo si sceglie, il codice dell’applicazione deve assumersi molte responsabilità per il mantenimento dell’integrità dei dati.

Se sei uno sviluppatore, allora troverai questo utile.

RethinkDB

Come dice il nome, RethinkDB “Ripensa” all’idea e alle capacità di un database quando si tratta di app in tempo reale.

Quando un database viene aggiornato, non è possibile che l’applicazione lo sappia. L’approccio accettato è che l’app emetta una notifica non appena c’è un aggiornamento, che viene portato al front-end attraverso un bridge complesso (PHP -> Redis -> Nodo -> Socket.io è un esempio).

E se gli aggiornamenti potessero essere trasferiti direttamente dal database al front-end?!

Sì, questa è la promessa di RethinkDB. Quindi, se stai per creare una vera applicazione in tempo reale (gioco, marketplace, analisi, ecc.), Rethink DB vale la pena dare un’occhiata.

Redis

Quando si tratta di database, è quasi troppo facile trascurare l’esistenza di Redis. Questo perché Redis è un database in memoria ed è utilizzato principalmente nelle funzioni di supporto come la memorizzazione nella cache.

Imparare questo database è un lavoro di dieci minuti (letteralmente!), ed è un semplice archivio di valori-chiave che memorizza le stringhe con un tempo di scadenza (che può essere impostato su infinito, ovviamente). Ciò che Redis perde nelle funzionalità che compensa in utilità e prestazioni. Dato che vive interamente nella RAM, le letture e le scritture sono incredibilmente veloci (alcune centinaia di migliaia di operazioni al secondo non sono inaudite).

Redis ha anche un sofisticato sistema pub-sub, che rende questo “database” due volte più attraente.

In altre parole, se hai un progetto che potrebbe trarre vantaggio dalla memorizzazione nella cache o ha alcuni componenti distribuiti, Redis è la prima scelta.

SQLite

Sì, ho promesso che avevamo finito con i database relazionali, ma SQLite è troppo carino per essere ignorato.

SQLite è una libreria C leggera che ha fornito un motore di archiviazione del database relazionale. Tutto in questo database vive in un singolo file (con estensione .sqlite) che puoi mettere ovunque nel tuo filesystem. E questo è tutto ciò che serve per usarlo! Sì, nessun software “server” da installare e nessun servizio a cui connettersi.

Caratteristiche utili

Anche se SQLite è un’alternativa leggera a un database come MySQL, offre un bel pugno. Alcune delle sue caratteristiche scioccanti sono:

  • Supporto completo per le transazioni, con COMMIT, ROLLBACK e BEGIN.
  • Supporto per 32.000 colonne per tabella
  • Supporto JSON
  • Supporto JOIN a 64 vie
  • Sottoquery, ricerca full-text, ecc.
  • Dimensione massima del database di 140 terabyte!
  • Dimensione massima della riga di 1 gigabyte!
  • 35% più veloce dell’I / O dei file

Quando usare SQLite

SQLite è un database estremamente specializzato che si concentra su un approccio semplice e intuitivo. Se la tua app è relativamente semplice e non vuoi la seccatura di un database completo, SQLite è un candidato serio. È particolarmente utile per CMS di piccole e medie dimensioni e applicazioni demo.

Quando non usare SQLite

Sebbene impressionante, SQLite non copre tutte le funzionalità di SQL standard o del tuo motore di database preferito. Manca il clustering, le stored procedure e le estensioni di script. Inoltre, non esiste un client per connettersi, eseguire query ed esplorare il database. Infine, con l’aumentare delle dimensioni dell’applicazione, le prestazioni diminuiranno.

cassandra

Mentre molti proclamano che la fine è vicina a Java, ogni tanto la community lancia una bomba e mette a tacere i critici. cassandra ne è un esempio.

Cassandra appartiene alla cosiddetta famiglia di database “colonnare”. L’astrazione di archiviazione in Cassandra è una colonna anziché una riga. L’idea qui è di archiviare fisicamente tutti i dati in una colonna sul disco, riducendo al minimo i tempi di ricerca.

Caratteristiche uniche

Cassandra è stato progettato pensando a un caso d’uso specifico, che si occupa di carichi pesanti in scrittura e tolleranza zero per i tempi di fermo. Questi diventano i suoi punti di forza unici.

  • Prestazioni di scrittura estremamente veloci. Cassandra è senza dubbio il database più veloce in circolazione quando si tratta di gestire carichi di scrittura pesanti.
  • Scalabilità lineare Cioè, puoi continuare ad aggiungere tutti i nodi a un cluster che vuoi e ci sarà un aumento zero della complessità o della fragilità del cluster.
  • Tolleranza della partizione senza pari. Cioè, anche se più nodi in un cluster Cassandra si interrompono, il database è progettato per continuare a funzionare senza perdita di integrità.
  • Digitazione statica

Quando usare Cassandra

Registrazione e analisi sono due dei migliori casi d’uso per Cassandra. Ma non è tutto: il punto debole è quando è necessario gestire dati di grandi dimensioni (Apple ha una distribuzione Cassandra che gestisce oltre 400 petabyte di dati mentre su Netflix gestisce 1 trilione di richieste al giorno) con tempi di inattività letteralmente zero. L’alta disponibilità è uno dei tratti distintivi di Cassandra.

Quando non usare Cassandra

Lo schema di archiviazione delle colonne di Cassandra ha anche i suoi svantaggi. Il modello di dati è piuttosto piatto e, se hai bisogno di aggregazioni, Cassandra non è all’altezza. Inoltre, raggiunge un’elevata disponibilità sacrificando la coerenza (ricordare il teorema CAP per i sistemi distribuiti), il che lo rende meno adatto a sistemi dove è richiesta un’elevata precisione di lettura.

Orizzonte temporale

Nuovi sviluppi richiedono nuovi tipi di database e Internet of Things (IoT) è uno di questi fenomeni. Uno dei migliori database open source per questo è Orizzonte temporale.

La scala cronologica è un tipo di quello che viene chiamato un database di “serie temporali”. È diverso da un database tradizionale in quel momento è l’asse principale di preoccupazione e l’analisi e la visualizzazione di enormi set di dati è una priorità assoluta. I database delle serie storiche raramente vedono un cambiamento nei dati esistenti; un esempio sono le letture della temperatura inviate da un sensore in una serra: nuovi dati continuano ad accumularsi ogni secondo, il che è interessante per l’analisi e il reporting.

Perché non utilizzare solo un database tradizionale con un campo timestamp, quindi? Bene, ci sono due ragioni principali per questo:

  • I database per scopi generici non sono ottimizzati per funzionare con dati basati sul tempo. Per le stesse quantità di dati, un database generico sarà molto più lento.
  • Il database deve gestire enormi quantità di dati mentre i nuovi dati continuano a fluire e rimuovere i dati o modificare lo schema; più tardi, non è un’opzione.

Caratteristiche uniche

Timescale DB ha alcune interessanti funzionalità che lo distinguono da altri database nella stessa categoria:

  • È basato su PostgreSQL, probabilmente il miglior database relazionale open source disponibile. Se il tuo progetto sta già eseguendo PostgreSQL, Timescale si inserirà direttamente.
  • Le query vengono eseguite tramite la familiare sintassi SQL, riducendo la curva di apprendimento.
  • Velocità di scrittura ridicolmente elevate: milioni di inserti al secondo non sono inauditi.
  • Miliardi di righe o petabyte di dati: non è un grosso problema per Timescale.
  • Vera flessibilità con lo schema: scegli tra relazione o schema secondo le tue esigenze.

Non ha molto senso parlare di quando usare o meno Timescale DB. Se l’IoT è il tuo dominio o cerchi caratteristiche del database simili, vale la pena dare un’occhiata a Timescale.

CouchDB

CouchDB è una piccola soluzione ordinata di database che si trova silenziosamente in un angolo e ha un seguito piccolo ma dedicato. È stato creato per affrontare i problemi di una perdita di rete e l’eventuale risoluzione dei dati, che risulta essere un problema così disordinato che gli sviluppatori dovrebbero invece cambiare lavoro piuttosto che occuparsene.

In sostanza, puoi pensare a un cluster CouchDB come una raccolta distribuita di nodi grandi e piccoli, alcuni dei quali dovrebbero essere offline. Non appena un nodo viene online, invia i dati al cluster, che viene digerito lentamente e con attenzione, diventando infine disponibile per l’intero cluster.

Caratteristiche uniche

CouchDB è una specie di razza unica quando si tratta di database.

  • Funzionalità di sincronizzazione dei dati offline-first
  • Versioni specializzate per browser mobili e Web (PouchDB, CouchDB Lite, ecc.)
  • Affidabilità resistente agli urti, testata in battaglia
  • Clustering semplice con archiviazione dati ridondante

Quando usare CouchDB

CouchDB è stato creato per la tolleranza offline e non ha eguali in questo senso. Un caso d’uso tipico sono le app mobili in cui una parte dei tuoi dati risiede su un’istanza di CouchDB sul telefono dell’utente (perché è lì che è stata generata). La cosa interessante è che non puoi fare affidamento sul dispositivo dell’utente da connettere continuamente, il che significa che il database deve essere opportunistico ed essere pronto a risolvere gli aggiornamenti in conflitto in un secondo momento. Questo si ottiene utilizzando l’impressionante Couch Replication Protocol.

Quando non usare CouchDB

Cercare di utilizzare CouchDB al di fuori del caso d’uso previsto porterà a un disastro. Utilizza molta più memoria rispetto a qualsiasi altra cosa là fuori, semplicemente perché ha bisogno di conservare copie ridondanti di dati e risultati di risoluzione dei conflitti. Di conseguenza, anche le velocità di scrittura sono dolorosamente lente. Infine, CouchDB non è adatto come motore di schema per scopi generici, in quanto non gioca bene con le modifiche dello schema.

Conclusione

Ho dovuto tralasciare molti candidati interessanti come Riak, quindi questa lista deve essere presa come una guida piuttosto che un comandamento. Spero di essere riuscito a raggiungere il mio obiettivo con questo articolo: presentare non solo una raccolta di raccomandazioni sul database, ma anche discutere brevemente su dove e come devono essere utilizzati (ed evitati!).

Se sei curioso di imparare il database, dai un’occhiata Udemy per alcuni dei brillanti corsi online.

TAGS:

  • Banca dati

  • Open Source

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map