Devo usare un database di testo semplice o SQLite? [chiuso]

7

Sto creando un sistema di punti vendita per un piccolo negozio. Sono particolarmente interessato a trovare i pattern di tutti gli articoli acquistati, che accederò nella loro interezza. Sto pensando persino di fare domande su cose come la temperatura alle vendite di specifiche categorie di prodotti.

Devo usare un database basato su testo semplice come CSV o andare su SQLite?

Quali sono alcuni esempi di situazioni in cui viene spesso utilizzato un database di testo semplice?

    
posta infinite-etcetera 31.05.2016 - 00:17
fonte

2 risposte

8

making queries on things like temperature to sales of specific categories of products

Questo (Query) è progettato per i database relazionali di un'area. Stai meglio con un database con supporto SQL.

    
risposta data 31.05.2016 - 01:49
fonte
5

Ho fatto la stessa domanda anni fa e ho effettivamente creato l'app in entrambi i modi. La versione del database build-my-own era molto divertente, ma era un giocattolo. L'utilizzo di un vero database ha permesso di ottenere un prodotto commerciale che si comporta bene sotto stress.

Database SQL

  • SQL ti consente di scrivere one-liners per la maggior parte dei tipi di rapporti di cui parli - one-liner che altri programmatori riconosceranno.
  • Esistono tutti i tipi di strumenti scritti per i database: backup, sharding, replica, contenitori di finestra mobile pre-costruiti ...
  • Puoi facilmente migrare verso un database diverso (PostgreSQL, MySQL, ecc.) se cambi idea.
  • La maggior parte dei database ha Transazioni in modo che quando qualcuno acquista un articolo e aggiusta sia il denaro nel proprio account che lo stock dell'articolo, il database prende entrambi gli aggiustamenti o nessuno dei due. Semplicemente non è possibile memorizzare metà della transazione e lasciarti con dati non funzionanti.
  • Gli altri programmatori riconosceranno immediatamente ciò che stai facendo
  • Per ottenere le stesse prestazioni da file di testo o da un formato binario inventato, dovrai implementare alcune strutture di dati serie. Se non sai cos'è un B-Tree o vuoi spendere settimane a ottimizzarlo, non sarai mai in concorrenza con la velocità di un database.
  • Qualcun altro sta sviluppando il database, quindi anche quando non lavori su di esso, quando applichi gli aggiornamenti, ottieni il vantaggio del loro lavoro.
  • Non hai detto quale lingua, ma ci sono gli ORM scritti per ogni database. Ho usato Hibernate, ma la curva di apprendimento è ripida e ultimamente ho avuto fortuna con eBean. Sottotitolo: se si dispone di loop nella struttura dati che si sta salvando (gli utenti sono aggiornati l'ultima volta da altri utenti), l'ORM si preoccupa di non andare in coda per ri-salvare gli oggetti in loop.
  • La maggior parte dei database consente vincoli di qualche tipo per impedire l'inserimento di dati non validi. Puoi impostarlo su errore di qualcuno che cerca di inserire un cliente senza un cognome, o un ordine senza un importo, o se l'utente non è associato a una società.

Database generato internamente

  • Probabilmente non hai bisogno di imparare l'ORM (Object-Relational Mapping Software) di qualcun altro
  • Imparerai molto sugli algoritmi alla base dei database e sulle difficoltà di implementazione.

Eseguo mysql-backup quotidianamente sulla produzione e alcune volte nel corso degli anni. Ho dovuto fare alcuni ripristini. I dati non vengono mai stampati a metà tra un aggiornamento e l'altro. Il nostro provider di hosting esegue automaticamente questi backup senza alcun costo aggiuntivo.

Infine, i database SQL oggi sono in gran parte prodotti di base. Puoi fare le stesse cose di base con PostgreSQL, MySQL, SQLite, SQL-Server e Oracle. Certo, ognuno ha qualcosa di speciale che l'altro non fa, ma in generale, non hai bisogno di quella cosa. Hanno raggiunto quel punto perché così tante persone li hanno usati in così tanti modi diversi per 40 anni.

Altre opzioni

Database No-SQL

Prodotti come CouchDB sono ideali per blog, wiki, e-mail e software di chat, in cui l'unità base dell'app è un documento di qualche tipo. I database SQL sono più adatti per piccoli pezzi di dati che hanno molte relazioni, come prodotti, ordini e inventario.

Negozi di valori-chiave

Prodotti come Redis.io sono grandiosi quando la relazione tra gli articoli è più importante degli oggetti stessi. È come un grande dizionario in cui si apre una parola e si ottiene una definizione.

Datomic

Ha alcuni aspetti di un archivio di chiavi / valori e parte di un database SQL (generalmente utilizza un database SQL sul back-end). Questo è in gran parte in concorrenza con un database SQL, ma scegli Datomic quando tenere una cronologia è quasi più importante di conservare i dati stessi.

File flat

Immagini, video e file audio non appartengono a un database SQL (si pensava che potessero trovarsi in un archivio non-SQL-documento). Alcuni altri tipi di file o dati (come HTML) generalmente non lo fanno neanche. Conserva queste cose in una cartella o in cartelle e quando qualcosa nel database si relaziona con loro, memorizza il nome del file nel database.

    
risposta data 31.05.2016 - 13:08
fonte

Leggi altre domande sui tag