Well I suppose then maybe I have the wrong idea of what "flat file database" means. To you anyway. I would not actually describe sqlite as a flat file database system... Since the data cannot be read safely directly from the file, using a text editor, or -- since a flat file could be binary data, any arbitrary program that just knows the format. And "flat" implies there is no special data structure involved. I would think that would not be the case for sqlite given how well it performs, it must use some kind of binary tree or clever indexing system of some sort.You must go via the actual sqlite process.
On the other hand maildir, composed of multiple ascii compatible text files, can be read by any email client- provided it follows the protocol for reading and writing of files in the maildir spec.
couchand|11 years ago
jmulho|11 years ago
emp_id emp_fname emp_lname emp_phone1 emp_phone1_type emp_phone2 emp_phone1_type dept_id dept_manager dept_manager_phone1 dept_manager_phone1_type
This approach has all kinds of problems (solved 40+ years ago by Codd and others). Examples: how do you add a third phone for an employee. How do you keep the managers phone from getting out of sync across rows.
I took "flat JSON file database" to mean essentially the same thing. Something like this:
emp_id emp_JSON_object
JSON perhaps solves some issues (e.g. adding a third phone for an employee), but still suffers from most of the issues (e.g. keeping the managers phone from getting out of sync across employees). Plus it suffers from new issues, namely the fact that each JSON object could have its own layout (e.g. one of them could have a third phone) so there is a bunch of parsing overhead compared to say knowing that phone number is at a specific offset on every row.
mappu|11 years ago
Would you consider MySQL to be a flat file database?
xxs|11 years ago
Flat files doesn't mean neither text file, nor human-readable. Text format, human-readable format is a terrible one to store data, esp. numbers.
TheZenPsycho|11 years ago