che è più costoso da fare in termini di risorse e di efficienza, File operazione di lettura/scrittura o database operazione di lettura/scritturafile di lettura/scrittura vs Database Read/Write
risposta
Inizialmente sono stato per dire database di lettura/scrittura , giù di mano, poiché includerebbe il file richiesto io sopra l'overhead del DB, ma poi si rese conto che non era così semplice. Se hai l'intero DB caricato in memoria, le letture sarebbero quasi istantanee in quanto non è coinvolto alcun file.
Le scritture, in generale, dovrebbero essere anche più veloci, poiché il motore DB non deve attendere il completamento dell'IO di file prima di tornare poiché è possibile adottare un approccio di tipo "lazy write".
Un database mal sintonizzato, d'altro canto, sarà di ordini di grandezza più lento di qualsiasi IO basato su file. La sintonia del DB è importante. Un sacco.
Inoltre, potrebbe essere molto più inefficiente estrarre i dati necessari utilizzando il semplice file-io, senza implementare un motore di database autonomamente, o utilizzando un database che centinaia di persone hanno trascorso anni a sviluppare per trovare rapidamente i dati. – nos
Questa è una sorta di domanda caricata. Di quali file di dimensioni stiamo parlando? Gigabyte? Inoltre, che tipo e dimensione del DB? Io uso spesso una combinazione. Vuoi controllare l'integrità del livello dei dati? In tal caso, potresti volerlo lasciare al DB altrimenti devi controllare tutto ciò a livello di applicazione.
Ci sono tanti fattori per prendere una buona decisione al riguardo. Ad esempio, quando creo dati temporanei che non desidero persistere, utilizzo File, ma se sto utilizzando i dati che desidero persistere o eseguire il backup, allora utilizzo un DB.
Questo accoppiato con l'architettura è importante. Se l'hardware, le licenze o la struttura sono un problema, allora forse non hai bisogno dell'infrastruttura dei server DB, ecc. Ma se hai le risorse allora l'aggiunta di un livello DB potrebbe essere la scelta giusta.
Non c'è una risposta semplice. Con qualsiasi database hai il sovraccarico di averlo sempre in esecuzione. Ma quando accedi a questo è in genere molto più veloce di accedere a un file. Se stai parlando solo di una manciata di accessi, non noterai molta differenza. Ma quando si arriva a centinaia, migliaia e milioni di accessi al minuto, il database sarà molto più veloce. E come notato da Tim in precedenza, un database mal sintonizzato può essere molto più lento dell'accesso a un file flat.
- 1. database vs file flat
- 2. Memoria database vs file system
- 3. Database blob vs File memorizzati su disco
- 4. Un database vs molti database
- 5. Repository vs database vs filesystem
- 6. Database SQL VS. Più file flat (Migliaia di CSV piccoli)
- 7. È presente la chiave dell'API REST ReadOnly in un database MongoLab oppure è sempre ReadWrite
- 8. file di testo sovrascrittura vs accodamento
- 9. MongoDb Database vs Collection
- 10. TimeZoneInfo vs. database Olson
- 11. php: sessioni vs database
- 12. web.Config vs Tabella impostazioni database
- 13. NoSQL vs. Database relazionali vs Ibrido possibile
- 14. IndexedDB - ObjectStores vs più database vs indici?
- 15. dichiarazioni accessor Objective-C (in sola lettura, readwrite, ecc)
- 16. File di database paradosso
- 17. BigTable di Google vs A Relational Database
- 18. Progettazione database - relazioni vs proprietà
- 19. Transaction vs Truncation Database Cleaner
- 20. Funzione database VS Case Statement
- 21. Triple Stores vs Database relazionali
- 22. Django: file di database dinamico
- 23. VS 2010 build database project riceve SQL04151
- 24. Database HTML5 - transazione VS executeSql callbacks
- 25. Xml vs. Database per la configurazione dell'applicazione
- 26. H2 Database vs SQLite su Android
- 27. Progetto database VS 2010 - SQL03006 Errore
- 28. Database vs tablespace, qual è la differenza?
- 29. Qual è la funzione del file DBMDL nel progetto di database VS
- 30. cat ... vs ... <file
@OP, puoi darci un po 'di contesto? –