Hacker News new | ask | show | jobs
by Tuna-Fish 4645 days ago
You seem to not understand the point. SQL databases don't count because these mechanisms are not visible, and the programming model is changing data in place.

No-one really cares how DB's are implemented under the hood, we just care about the programming model. (And speed, CAP, ACID, etc...)

1 comments

I do get the point, in fact I'm building such an app right now, but my statement is still true and I find that quite amusing.
Given the underlying architecture of most relational databases, is it realistically possible to do "point in time queries", without requiring playing back the entire log history into a clean database up to the point in time you want? That's not going to be very efficient.

I've only seen SQL logs presented as solutions to replication and disaster recovery, not point in time functionality.

What I'm getting at, is it even possible in principle to expose part of the inner workings of some relational database systems to get this kind of capability?

Snapshotting and log replay should be fairly straightforward, if you save all sql statements in their entirety. Snapshots would stop the world, which might pose a problem, but I presume this is no different to other event sourcing solutions. Given the concurrency of a db, I'm also not sure that there's a strict ordering of all incoming statements.

Edit: Seems like at least Oracle is already doing this: http://en.wikipedia.org/wiki/Redo_log

Not only is this possible, Oracle has had exactly that feature since 2002:

http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_...