Doubt the Status Quo!
Today, people automatically use a relational database if they want to build a business application. But:
Databases come from a long time ago in a galaxy far, far away...
In this time,
- RAM was very small and very expensive,
- Computers were pretty slow,
- Programming was something very technnical and abstractions like OO had not been invented yet.
Thus, the database vendors optimized their products on scaling, memory sufficiency, etc. But is that really
needed in a middle sized "as usual" business application? We think: No, Sir. Reasons:
- 8 GB of RAM cost only some bucks.
- Even desktop computers run at several GHz and have multiple cores.
- Software is everywhere and has to change very fast and be very flexible.
- The amount of data in a middle sized business application is usually less then the amount of memory on a well equipped machine.
Object Orientation is awesome and cool and smooth. But as soon as you hit the database,
it becomes not so cool and smooth anymore. We define relational tables, but we want to have hierarchical classes.
We write stored procedures, functions and triggers, but we want to encapsulate our logic in objects with methods, properties and events.
The point is: Even with modern ORMs we have to go through a lot of hassle to connect our application to a database.
What we get for that is a lot of features we don't need. So the question is:
Why should we use a data base at all?
The only thing we need is a store where we can persist our entities and a framework that makes this
aspect as transparent as possible. But what about the "useful" features of a database which are defined by the
ACID criteria, which are basically focused on concurrency?
In a database, we can run transactions, we can roll them back and we have isolation between transactions.
If we want to get rid of our database, we need a framework that handles transactions with rollback and
isolation on our domain model - fine! With ObjectLounge, you can do all these things, too - without a database!