[davidmathers]

it seems like you’re looking for realistically structured data, not data twisted to fit a formula convenient for mathematicians.

The appropriate words here are "logical" and "physical" not "real" and "unreal". A relation is a logical data structure. Hash tables, trees, and graphs are all physical data structures.

Another accurate thing to say is that hash tables, trees and graphs are all "pointer-based databases" and relational databases are "pointer-free databases".

The second one will be confusing to people accustomed to putting pointers into relations (like what rails does) and turning the relational database into an ad-hoc graph database.

[prodigal_erik]

Surrogate keys are very common in real-world relational databases. If an order has a CUSTOMER_ID which was generated mechanically, appears in exactly one tuple of the CUSTOMERS relation, and has no other assigned meaning, isn't it just a pointer to that tuple?

[davidmathers]

What you describe is a pointer, but not a surrogate key.

http://en.wikipedia.org/wiki/Surrogate_key

"For example, table Staff may contain two rows for "John Smith", one row when he was employed between 1990 and 1999, another row when he was employed between 2001 and 2006. The surrogate key is identical (non-unique) in both rows however the primary key will be unique."

[scott_s]

I think "graph database" is probably the best term I've heard so far.