3 ms·
I think your points are valid only for very different data scenarios. 1-2 scenario: many many small files. 3: continuously accessing your data 4: concurrent
by lysium 13y ago
I think your points are valid only for very different data scenarios.
1-2 scenario: many many small files.
3: continuously accessing your data
4: concurrent connections
5: distributed application
6: never-stopping application
7: concurrent writes to mutable data
You may need a DB, if you want several of these to happen. This might be true for many applications, but for many applications this is equally not true.
Most often than youd' expect, using a DB makes understanding an application _harder_ because the data in the application tends to get structured as in the database: only ids, ints, strings and maybe date, no graphs or algebraic data types such as sum types, optional types, etc.
- icebraining 13y agoThere are plenty of databases with support for more complex types, and in any case, it's not like the filesystem understands those either, so if you want to store something to disk, you'll need some kind of translation/serialization anyway.
- lysium 13y agoI'm interested in the databases that support more complex types. Pointers?
- dkersten 13y agoFor graphs, try a graph database like Neo4j, OrientDB, Titan, InfiniteGraph or Dex.
- icebraining 13y agoNothing very specific, I was specifically thinking about graph databases, since you mentioned them. There's also domain-specific datatypes, such as those implemented by PostGIS.
- andrewvc 13y agoThat's a fair point, for many scenarios this stuff doesn't matter, like a video-game. However, most apps fall into either the "serialize a bunch of crap to disk" category, or the "multi-user data changes all the time category". Nearly everything in the second category works best with a proper database.