4 ms·
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
by davidmathers 17y ago
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 17y agoSurrogate 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 17y agoWhat you describe is a pointer, but not a surrogate key. http://en.wikipedia.org/wiki/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 17y agoI think "graph database" is probably the best term I've heard so far.