4 ms·

I don't understand why SQLite would be used instead of writing a data structure. To me going through SQL (& ORMs) is a hindrance. Why use a database if you onl

by rb808 8y ago

I don't understand why SQLite would be used instead of writing a data structure. To me going through SQL (& ORMs) is a hindrance. Why use a database if you only have one process?

grzm 8y ago
Comparable questions are why use a library when you can just write the code yourself, or why use a high level language when you can write it in assembly. SQLite gives you a lot of power, having already solved a lot of the problems and with a lot more testing, that you then don't have to. The price you pay for that is using their API, which, in this case, is SQL. Using an ORM is a separate choice. You may choose differently than others on these decisions, but using SQLite is certainly a reasonable decision that many people find compelling. It's also useful to point out that SQLite can have many reader processes. The single-process limit is only on writes.
api 8y ago
That's fine when you don't need complex queries or your data is small. As complexity increases you will eventually end up with a buggy slow relational database.
- Drdrdrq 8y ago
  And even then it's better to use a standard solution that other people will know too, if nothing else, to make maintenance easier.
oconnor663 8y ago
Transactions. It's relatively easy to atomically edit random data in a file on disk, if you're willing to overwrite the entire file with your new version. But as soon as you need to edit files that are too big for that approach, the problem becomes exceptionally complicated. Indexing any columns you want in one line of code is also very nice.
beefhash 8y ago
To add to the arguments already made: You don't have to figure out serialization. In particular, writing out structs in C and C++ can break even between compiler versions if padding changes.
pjc50 8y ago
SQLite is a data structure. The process of finding things on disk and atomically updating them is not as simple as it sounds and is about 90% of the work of a database.

by rb808 8y ago

I don't understand why SQLite would be used instead of writing a data structure. To me going through SQL (& ORMs) is a hindrance. Why use a database if you only have one process?

grzm 8y ago

Comparable questions are why use a library when you can just write the code yourself, or why use a high level language when you can write it in assembly. SQLite gives you a lot of power, having already solved a lot of the problems and with a lot more testing, that you then don't have to. The price you pay for that is using their API, which, in this case, is SQL. Using an ORM is a separate choice. You may choose differently than others on these decisions, but using SQLite is certainly a reasonable decision that many people find compelling. It's also useful to point out that SQLite can have many reader processes. The single-process limit is only on writes.

api 8y ago

That's fine when you don't need complex queries or your data is small. As complexity increases you will eventually end up with a buggy slow relational database.

Drdrdrq 8y ago
And even then it's better to use a standard solution that other people will know too, if nothing else, to make maintenance easier.

oconnor663 8y ago

Transactions. It's relatively easy to atomically edit random data in a file on disk, if you're willing to overwrite the entire file with your new version. But as soon as you need to edit files that are too big for that approach, the problem becomes exceptionally complicated. Indexing any columns you want in one line of code is also very nice.

beefhash 8y ago

To add to the arguments already made: You don't have to figure out serialization. In particular, writing out structs in C and C++ can break even between compiler versions if padding changes.

pjc50 8y ago

SQLite is a data structure. The process of finding things on disk and atomically updating them is not as simple as it sounds and is about 90% of the work of a database.