I'm writing a little application that keeps all its data in memory. Modifications are done through an XML/HTTP API. When a modification happens, I change the in-memory structures and save the record to the DB.
What do I lose if I just serialize my in-memory objects directly to individual files with their name? Say "myconfig/users/1", "myconfig/accounts/1"? I save out on having to use an OR mapper to get things into RAM as well as having to specify the exact schema up front.
Name:
Anonymous2008-11-08 0:27
Oh, I should add: When the app starts up, it reads all the rows in the database and constructs the in-memory representation.
Name:
Anonymous2008-11-08 0:33
I dunno, but this whole affair seems pretty ENTERPRISE to me.
Name:
Anonymous2008-11-08 0:46
Transactions. Complex queries with little effort. Consistency enforced via schema definitions.
Of course MySQL, being a toy, has none of these implemented properly.
Name:
Anonymous2008-11-08 1:14
Good point on transactions and queries, but since I have to keep everything live in memory anyways...
>>5
Concurrency without locking being a pain in the ass doesn't convince you? Well, your queries must be simple then. For now.
A RDBMS lets you expand your schema and use-cases far more easily than an in-memory setup would. Also if the application process crashes, state is recoverable from no later than the last time a transaction was committed.
Though for a non-networked desktop application, relational databases are WAY OVERKILL. Don't be the guy that writes an application and depends on a relational database for the app's config file.
Name:
Anonymous2008-11-08 3:52
The one thing I never understood about these Enterprise Database Weenies
Name:
Anonymous2008-11-08 4:34
>>7 Also if the application process crashes, state is recoverable from no later than the last time a transaction was committed.
Note that OP commits a DB change after every in-memory change, so there's still the risk of partial failure with cascading changes since he's a dumbfuck.