131–140 of 152 posts
http://ff-extractor.sourceforge.net/
The Flat File Extractor command line utility has saved my bacon a few times in my career. If I'm dealing with legacy code, data migrations, needing to quickly perform some surgical extraction or munging into another format - ffe is the tool for me.
EDIT: looks like someone's forked and update the tool. https://github.com/igitur/ffe
Many top posts in the past weeks were all about using SQLite for usecases it wasnt originally designed to do, using it as a distributed database, even.
Now, here's a post which misses the EXACT usecase sqlite was built for, and its barely even mentioned.
SQLite is quite literally the best solution here. Its a file, you open it, and boom you got a database. You can explore it with sqlite3 cli or datagrip or anything you want.
This is like saying "lets use png for animated images" and then searching for "a format to handle uncompressed images with transparency" and not mentioning png.
Is sqlite a flat file disqualifier?
HN, are you feeling okay? Many top posts in the past weeks were all about using SQLite for usecases it wasnt originally designed to do, using it as a distributed database, even. Now, here's a post which misses the EXACT usecase sqlite was built for, and its barely even mentioned. SQLite is quite literally the best solution here. Its a file, you open it, and boom you got a database. You can explore it with sqlite3 cli…
Boom! What is the program to open (understand) it? Even my elixir's core lib cannot understand it.
Earlier 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-…
ACID comes with costs, those guys may be smart but they're not magicians. As a rule of thumb, if you never handle a transaction failure or deadlock with something that is not retrying or failing, you shouldn't be using an ACID-based system since you're not getting any benefit from it. And if you e.g. have multiple dataflow paths with different priorities then you also probably shouldn't be using a DBMS, because they'…
Could you expand? Does this mean you wouldn't use an ACID database for CRUD?
If I did the work today I'd probably store the metadata in an SQLite database running on the frontend, but I'd keep the poem copy in their own files in the folder.
Earlier quoted context omitted.
Still, it is a consideration, and it all factors in. Copying your WonderCMS files to another host, great… oops, it doesn’t have PHP mbstring extension, sorry, won’t run. (And if you’re trying to use “free” hosting, you probably don’t have privs to install the missing requirements.)
What I mean is that being able to host anywhere is a constraint you're adding, not one that's in the original article. If you have zero control over your environment and no ability to inspect it, then I agree that static files are probably the way to go.
>> “… means being able to start your website by dumping everything into a folder and you're pretty much done (1 step installs).”
>> “Dumping everything into a folder and it just works (1 step installs) makes it easy for even beginners to get a website running, but also it makes your website, blog, forum, journal, or whatever, portable. Very easily portable. You need to put your website on a thumb drive and/or move it to a different domain? Done. Easy. It's just like backing up any folder.”
Earlier quoted context omitted.
This opinion is quite popular nowadays but IMHO it is caused by misunderstanding what a database and database management system is and what it is for. DBMS (and in particular) RDBMS is not a merely persistence medium for an application - DBMS main role is to _share_ data between applications.
I don’t understand this as distinction with file systems. Networked file systems exist and I have a lot of production code that shares data as files in either some networked file/blob system. Often databases even just store a reference to a file path for stuff like images/other large artifacts that are shared from some file system.
Earlier quoted context omitted.
> 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. That is not exactly what proprietary means. Though I feel the same - plain text can be versioned and managed by various tools and that is great!
I was not aware I gave a definition for it. I didn't mean it as an antonym for 'readable', if that's what you mean. Plaintext could be in a proprietary format but that's far better than proprietary compressed database that's a job to work out what even made it (if that wasn't proprietary itself!). Proprietary plaintext might even be better than open standard blobby format, depending on what you want to do with it. (B…
If your code is Free and Open Source, then its file-format is presumably not proprietary, whether or not it makes use of an existing standard format (like JSON) or solution (like SQLite).