Live data from Hacker News

The Functional Database [video]

infoq.com

31–37 of 37 posts

Re: The Functional Database [video]

#31
post #16

Earlier quoted context omitted.

Okay, so it's a database with version control. I was actually looking for a feature like this a while back in normal databases.

In the database world, we call it temporal databases, because it introduces the concept of time as a first-class part of the conceptual/logical model. Every production database I've ever seen goes through some version of the same evolutionary lifecycle: 1. "We only need the current state". The database acts as a snapshot of the current world. Updates cause the loss of historical data. The database is like a state mac…

I spent years making all kinds of databases, and I approve your message.

I recently noticed that CouchDB with its notion of map-reduce views can be used as a temporal database - make each change a "document", then make a map-reduce job to roll up the changes to the present state (or "as of" state", if you need it). Nice side effect is that you get free multi-master replication with automatic conflict resolution.

Do you have any other suggestions for a temporal database?

Re: The Functional Database [video]

#32
post #9

Earlier quoted context omitted.

Is three ok? Using my limited experience playing with Datomic: A functional DB replaces a "row" that only holds the current state of the world with a list of timestamped "facts" that can represent either the present or any point in the past. Instead of simply recording "Bob's favorite food is pizza," we record that "'Bob's favorite food is pizza' was added at Time X." If Bob decides his favorite food is now ice cream…

> A functional DB replaces a "row" that only holds the current state of the world with a list of timestamped "facts" that can represent either the present or any point in the past. ... which isn't 'functional' in any sense. It seems that Hickey just reinvented time series and tries to sell those as database.

Not quite. A time series' purpose is to record the change in value of some quantity over time, while this ties with the notion of persistent data structures and Hickey's philosophy of value and state which is at the heart of Clojure.

The purpose is not to follow a changing quantity, but to formalize state and value. The idea is that any entity's state, at any given moment in time, is an immutable value. You can query the state at time t0, get a value, and examine it or process it for as long as you like. You can then query it again at time t1, and get another, immutable value.

I guess this is a dual way of looking at time series data, with a different emphasis. The time series is intended to help with processing change, while a persistent data structure is intended to help working with a snapshot of the world as it existed in a specific instant.

Re: The Functional Database [video]

#33
post #31

Earlier quoted context omitted.

In the database world, we call it temporal databases, because it introduces the concept of time as a first-class part of the conceptual/logical model. Every production database I've ever seen goes through some version of the same evolutionary lifecycle: 1. "We only need the current state". The database acts as a snapshot of the current world. Updates cause the loss of historical data. The database is like a state mac…

I spent years making all kinds of databases, and I approve your message. I recently noticed that CouchDB with its notion of map-reduce views can be used as a temporal database - make each change a "document", then make a map-reduce job to roll up the changes to the present state (or "as of" state", if you need it). Nice side effect is that you get free multi-master replication with automatic conflict resolution. Do y…

To my very great shame I am aware that there is an entire literature on the topic and I have barely even skimmed the surface of it.

Snodgrass, a leading researcher on temporal databases, wrote a book in 90s about it which is available for free from his website[1].

It's good because it was written before some temporal extensions were added in SQL:2003 (I think). The problem is that almost nobody has implemented those extensions (I believe some versions of DB2 have them), so you are left with doing things by hand. The Snodgrass book goes into amazing detail as to why you'd do such a thing and how to do it.

[1] http://www.cs.arizona.edu/~rts/tdbbook.pdf

Re: The Functional Database [video]

#35

Such a shame about InfoQ. Seems like they've got lots of interesting content, but the user experience is abysmal to the point where I now avoid the site. Would it be so bad to just let us flick through the slides?

if you create an account on infoq, you're able to download the slides.

Re: The Functional Database [video]

#36

Earlier quoted context omitted.

Temporal databases and immutability are independent concepts. A 'time series database' only solves the simple temporal database problems. When validity comes into play things become really hard (something was entered yesterday but will be valid from tomorrow).

Temporal databases rely on the immutability of each record (whether by convention or as a system guarantee). Changes are no longer expressed with updates on a given row; instead you add new rows to represent the change.

> Temporal databases rely on the immutability of each record

Some maybe, certainly not all! What you mean are 'historical' databases, a.k.a. time series.

Re: The Functional Database [video]

#37
post #16
post #9

Earlier quoted context omitted.

Is three ok? Using my limited experience playing with Datomic: A functional DB replaces a "row" that only holds the current state of the world with a list of timestamped "facts" that can represent either the present or any point in the past. Instead of simply recording "Bob's favorite food is pizza," we record that "'Bob's favorite food is pizza' was added at Time X." If Bob decides his favorite food is now ice cream…

Okay, so it's a database with version control. I was actually looking for a feature like this a while back in normal databases.

It's more than that. It's actually a lot like distributed version control (a la git). When you ask the connection for the current value of the database, you get back a real value that will never change out from under you. This is very much akin to making a clone of a repository in git. This gives you the enormous power of speculation and experimentation within your application. You can do whatever you want with this database value and it will never affect anyone else nor be affected by anyone else.
Post reply on HN