91–100 of 108 posts
Searched for this topic: > and is backwards compatible to its inception in 2004 and which promises to continue to be compatible in decades to come. That is pretty amazing. You could do a lot worse.
Same as .zip, .xml, .json and many others. Doesn't mean that whatever the app stores inside will remain backward compatible which is the harder problem to solve.
Something to consider when using SQLite as a file format is compression (correct me if I'm wrong!). You might end up with a large file unless you consider this, and can't/won't just gz the entire db. Nothing is compressed by default.
It can be compressed, see https://sqlite.org/sqlar.html
> An "SQLite Archive" is a file container similar to a ZIP archive or Tarball but based on an SQLite database.
Your parent comment said that when you're using SQLite as an application format, the content in the database don't get compressed. These two things have nothing to do with each other.
I see no downside in using sqlite as an application file format.
The only "downside" is that the format is an open spec, which allows anyone to modify the contents without going through the specific application. And it's only a downside if you are using the format as an obfuscation to prevent third-party compatibility/reverse engineering, or to lock in customers.
Earlier quoted context omitted.
What problem are you trying to solve with this approach? Unless your document is huge and you need the ability to read or update portions of it, it is better to just read and write JSON.
There's a laundry list of benefits that all add up, not like one specific killer feature. Some applications really do have very complex configuration needs, but it's sorta situation dependent on whether embedding a scripting language or a database is the right solution (for really simple cases I'm more likely to reach for TOML). An incomplete list of benefits of using SQLite: - Runtime config changes for free - type…
Earlier quoted context omitted.
There's a laundry list of benefits that all add up, not like one specific killer feature. Some applications really do have very complex configuration needs, but it's sorta situation dependent on whether embedding a scripting language or a database is the right solution (for really simple cases I'm more likely to reach for TOML). An incomplete list of benefits of using SQLite: - Runtime config changes for free - type…
Type safety as a benefit of SQLite? For me type safety is a negative of SQLite. Being able to store a different type that what the column is declared to store is a bug (not a feature). I also find the lack of DATE and DATETIME/TIMESTAMP to be less than ideal.
Earlier quoted context omitted.
Why would you want to do that?
Convenience? Not cluttering up a directory with a transient file tree?
On a Mac, you'd e.g. use and mount a disk image if you wanted to create a filesystem inside of a file. Windows has virtual hard drives, and you can do that kind of thing on Linux too.
I don't understand why you'd ever want to use a relational database for that. It's a completely different paradigm.
Although I also don't really understand why you're worried about cluttering up a directory. And if it's transient, it's that when temp dirs are for?
Earlier quoted context omitted.
Convenience? Not cluttering up a directory with a transient file tree?
But why would you want to use SQLite for that? On a Mac, you'd e.g. use and mount a disk image if you wanted to create a filesystem inside of a file. Windows has virtual hard drives, and you can do that kind of thing on Linux too. I don't understand why you'd ever want to use a relational database for that. It's a completely different paradigm. Although I also don't really understand why you're worried about clutteri…
Well, it might be a relation DB or else a zipfile. Why couldn't I encapsulate a file tree in a single file ? Maybe it's tens of thousands of quite small files.
Earlier quoted context omitted.
as i said and you ignored, all it does is put people off from having fresh conversations.
You do realize that dang himself frequently aggregates related discussions, and thanks people for doing so. And that the previous discussions of the same URL are readily available at the top of the topic, via the "past" link. So either HN itself is actively discouraging discussions, which seems unlikely, or your perception of this is askew.
Earlier quoted context omitted.
But why would you want to use SQLite for that? On a Mac, you'd e.g. use and mount a disk image if you wanted to create a filesystem inside of a file. Windows has virtual hard drives, and you can do that kind of thing on Linux too. I don't understand why you'd ever want to use a relational database for that. It's a completely different paradigm. Although I also don't really understand why you're worried about clutteri…
> I don't understand why you'd ever want to use a relational database for that. It's a completely different paradigm. Well, it might be a relation DB or else a zipfile. Why couldn't I encapsulate a file tree in a single file ? Maybe it's tens of thousands of quite small files.
So why would you want to use SQLite for that is my question? Mounting a database or a table as a filesystem doesn't make much sense to me. There's a very poor fit between the two paradigms. What does a subdirectory mean in a database? What does a foreign key or set of columns mean in a filesystem?