4 ms·

One thing that I wish more people realized, especially ones developing native apps, is this: unless you really need an specific file format for your application

One thing that I wish more people realized, especially ones developing native apps, is this: unless you really need an specific file format for your application, don't design your own. Just use SQLite. You get so much out of it (including features like undo), as well as a huge toolkit.

combatentropy 7y ago
"SQLite does not compete with client/server databases. SQLite competes with fopen()." --- https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html
jimis 7y ago
> (including features like undo) Can you please elaborate on this?
- g82918 7y ago
  Transaction rollback is probably what he meant. If that is a familiar topic to you the relation to undo should make sense and his point should be clear. If that doesn't make sense, look up ACID, Transactions, and Migrations in the context of a database.
  - deleted 7y ago
    [deleted]
- hinkley 7y ago
  I had a different interpretation. It's not uncommon in commercial code to use a sort of copy-on-write behavior where every edit creates a new row and marks the other one as dead (for instance, filling in or blanking out a column to mark it defunct). You leave an audit trail behind. Which, with a little bit of work, can be used to revert to earlier versions.
kalleboo 7y ago
Even Apple, home of not-invented-here, built their "Core Data" object storage API (which is extremely prevalent throughout iOS and macOS apps) using SQLite as a backing store.
flukus 7y ago
And you lose the ability to quickly change settings in a text editor, to have multiple settings files, to have tiered (system, local, project) settings files, to version them in source control, etc. Instead of learning ini, josn and xml you'll have to learn whatever schema project x uses and there will be more schemas than file formats. Plus SQLite might be fast, but it's still a lot more overhead than parsing an ini file.
- imtringued 7y ago
  Why are you comparing schemas to file formats? Those configuration files still have their own user defined schemas.
- gwbas1c 7y ago
  > unless you really need an specific file format for your application It's all about choosing the right tool for the job. There's great reasons to use xml files over SQLite, but that mostly comes down to needing a file to be human readable versus file size. In the product that I work on, I moved very small tables out to xml files because it's easier to inspect them in a text editor instead of expecting non-developers to figure out a database. These files are also small enough and are written infrequently enough that any performance difference between xml and SQLite is negligible. The vast majority of data is in SQLite. An older version of the product would always write out a giant xml file, but when the xml got big, performance suffered. In this case, SQLite is the correct choice because it can make a small change to the database without needing to rewrite the entire file.
- ric2b 7y ago
  > And you lose the ability to quickly change settings in a text editor There are plenty of SQL CLI/GUI clients that support SQLite. But if you need end users to be able to change some configurations sure, move those to standalone files and parse them.
- int_19h 7y ago
  You don't lose the ability to have multiple or tiered settings files - there's nothing preventing you from using as many SQLite database files as you want. The other points are valid, but not everything can be shoehorned into JSON or XML. Sometimes the data size is too large for the read-everything-into-memory approach. Sometimes you need to deal with a lot of binary blobs. And so on.

combatentropy 7y ago

"SQLite does not compete with client/server databases. SQLite competes with fopen()." --- https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html

jimis 7y ago

> (including features like undo) Can you please elaborate on this?

g82918 7y ago
Transaction rollback is probably what he meant. If that is a familiar topic to you the relation to undo should make sense and his point should be clear. If that doesn't make sense, look up ACID, Transactions, and Migrations in the context of a database.
- deleted 7y ago
  [deleted]
hinkley 7y ago
I had a different interpretation. It's not uncommon in commercial code to use a sort of copy-on-write behavior where every edit creates a new row and marks the other one as dead (for instance, filling in or blanking out a column to mark it defunct). You leave an audit trail behind. Which, with a little bit of work, can be used to revert to earlier versions.

kalleboo 7y ago

Even Apple, home of not-invented-here, built their "Core Data" object storage API (which is extremely prevalent throughout iOS and macOS apps) using SQLite as a backing store.

flukus 7y ago

And you lose the ability to quickly change settings in a text editor, to have multiple settings files, to have tiered (system, local, project) settings files, to version them in source control, etc. Instead of learning ini, josn and xml you'll have to learn whatever schema project x uses and there will be more schemas than file formats. Plus SQLite might be fast, but it's still a lot more overhead than parsing an ini file.

imtringued 7y ago
Why are you comparing schemas to file formats? Those configuration files still have their own user defined schemas.
gwbas1c 7y ago
> unless you really need an specific file format for your application It's all about choosing the right tool for the job. There's great reasons to use xml files over SQLite, but that mostly comes down to needing a file to be human readable versus file size. In the product that I work on, I moved very small tables out to xml files because it's easier to inspect them in a text editor instead of expecting non-developers to figure out a database. These files are also small enough and are written infrequently enough that any performance difference between xml and SQLite is negligible. The vast majority of data is in SQLite. An older version of the product would always write out a giant xml file, but when the xml got big, performance suffered. In this case, SQLite is the correct choice because it can make a small change to the database without needing to rewrite the entire file.
ric2b 7y ago
> And you lose the ability to quickly change settings in a text editor There are plenty of SQL CLI/GUI clients that support SQLite. But if you need end users to be able to change some configurations sure, move those to standalone files and parse them.
int_19h 7y ago
You don't lose the ability to have multiple or tiered settings files - there's nothing preventing you from using as many SQLite database files as you want. The other points are valid, but not everything can be shoehorned into JSON or XML. Sometimes the data size is too large for the read-everything-into-memory approach. Sometimes you need to deal with a lot of binary blobs. And so on.