Re:Now that people are considering NOSQL will more people co...
by jcromartie on Wednesday August 31, 2011 @05:23PM
(#2947617)
It's not hard, no, but it usually doesn't happen in the average application. That's the issue: it's not built in, it's not standardized, and every SQL database is fully mutabile by default.
If your system operates in this journaled/event-sourcing way at the most basic level then you have the ultimate future-proof storage layer. You could decide to completely change the way the data is stored and represented (in-memory or otherwise) at any time, as long as you have that raw history.
Re:Now that people are considering NOSQL will more people co...
by kfool on Wednesday August 31, 2011 @09:34PM
(#2948301)
That's one of the things ChronicDB does. It makes historical values available in the average application.
Re:Now that people are considering NOSQL will more people co...
by artsrc on Wednesday August 31, 2011 @09:27PM
(#2948285)
You loose some features of SQL when you have historical values.
For example if you only want customers to create orders you can set a foreign key between customer and order. If you don't delete orders and customers, then the database will allow you to insert new orders against old customers, unless you apply a more complex constraint.
FTFY...
It's not hard to build history into a SQL table design. You can even store events in a...wait for it... SQL database. I have built numerous systems backed by SQL databases that have complete history retention. Answering questions like 'who had id 'X' on this date 3 years ago' are easily solvable with basic standard sql.
I certainly don't believe SQL databases are perfect or the tool for every job, but in many cases they work just fine until you get into very large datasets. Admittedly, I only deal with databases in the 100s of GB range so I have yet to personally run into the scaling problems that a Google or Facebook have and the SQL backed systems I have built work just fine.