Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…
> There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. A database has a whole engine, which I'd argue is a pretty fundamental difference. I think I get what you were trying to say, though: there's no fundamental difference between database tables and flat files, and there's no fundamental difference between a database and a filesystem.
Smaller is better – The rise, fall, and rise of flat file software
71–80 of 152 posts
Re: Smaller is better – The rise, fall, and rise of flat file software
#72Re: Smaller is better – The rise, fall, and rise of flat file software
#73Re: Smaller is better – The rise, fall, and rise of flat file software
#74Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…
> There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. A database has a whole engine, which I'd argue is a pretty fundamental difference. I think I get what you were trying to say, though: there's no fundamental difference between database tables and flat files, and there's no fundamental difference between a database and a filesystem.
But "flat" essentially means "one table that doesn't reference (and isn't referenced by) other tables in a reliable way." It's a way of saying 2 dimensions (flat) versus 3+ dimensions (relational). The moment you start having multiple plain text files where columns act as primary and foreign keys, the system is no longer flat, despite using plain text files.
It seems to me that TFA and most comments here are really just talking about using a DBMS vs using plain text files, not using flat vs using relations.
Re: Smaller is better – The rise, fall, and rise of flat file software
#75Earlier quoted context omitted.
A database can be relational, it can make some guarantees, it can pass Acid. With a file you are responsible for performance, reliability, integrity and security of the data. Do you believe that you can do a better job than those tens of guys who contributed to a DBMS? Go ahead. Do you not need reliability, integrity, security, performance? Go ahead. So use a file to store data instead of database but know the trade-…
Portability to other systems.
Re: Smaller is better – The rise, fall, and rise of flat file software
#76I can recommend HTMLy and automad. HTMLy can easily work with 20.000 posts, without any noteworthy slowdown.
Re: Smaller is better – The rise, fall, and rise of flat file software
#77Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…
DBMS (and in particular) RDBMS is not a merely persistence medium for an application - DBMS main role is to _share_ data between applications.
Re: Smaller is better – The rise, fall, and rise of flat file software
#78Maybe it is just a reflection on the state of filesystems vs databases. There is no fundamental difference between a database and a flat file, it is all bytes on a disk/memory in the end. So it is mostly a question of balancing the roles of the hardware, OS, and application software. For example, if the reason you are using a database is that it does a particularly good job at limiting disk IO, then it may not be nec…
For me it's about proprietary vs. readable - unless it's obviously necessary for performance I think I'd still prefer 'flat file' to sqlite, but basically I just want something that isn't an incomprehensible blob, that I can use with other tools etc. Bonus points for some open standard, but some kind of understandable format even if proprietary is miles ahead of proprietary and cryptic. I wish Fusion360 for example h…
There are two standards for this common to CAD, called IGES and STEP. They are both plaintext, though their gittability is questionable.
Re: Smaller is better – The rise, fall, and rise of flat file software
#79I built many of my (project) websites with it,
https://www.humangodinterfaces.com
https://www.perspectives-in-play.com
it‘s blazingly fast (performance-wise and in terms of building your site), super easy to customize and I never missed my database.
Re: Smaller is better – The rise, fall, and rise of flat file software
#80If there is any possible need to integrate into a larger overall system in ways that have yet to be fully imagined or defined, a DBMS might be a better option.