relational models  vF
contribute · other topics
10 August 07 from Matthew 1
I'm don't think we disagree. I mean, even tables aren't tables all the way down, you've got b-trees or whatever underneath, and a file system under that, and magnetic disk under that ... the question is whether relational databases are the best thing at their current level of abstraction, or if there might be something better.  

But if I'm missing something important here, feel free to let me know.  

(BTW, thanks for the link, I got a good chuckle looking at the ITA site. An airfare software company that uses lots of three-letter abbreviations is either brilliantly ironic or utterly clueless.)
9 August 07 from glenn mcdonald 2
Well, I'd argue that the point of abstraction, in this context, is to layer the elegant version on top of the powerful version. I'm not convinced tables-all-the-way-down is the most powerful version. But then, if I knew the better answer, my group at work wouldn't have posted this job opening.
9 August 07 from Matthew 1
from Death to False (Metal): "Subliminating the one/many distinction allows us to talk about ... so I'm also probably arguing for the better abstraction to not merely be layered on top of the bad one."  

That would be the interesting thing, if someone could figure out a way to *store* the data differently.  

Basically, every object-oriented program with a relational back end puts a layer of pretty objects on top of ugly tables, making it easier to ask questions like, "which objects have this property?" (Rails's activerecord is an attempt to do this at the framework level.) And based on my understanding of computing history, I'm pretty sure that layering the prettier abstraction on top of the bad one is the point of abstraction, and the way to go. But if someone could find a way to store the data that made this abstraction unnecessary, and that produced datastores with performance comparable to that of relational databases ... yeah, that would be cool.
vF software copyright © 2005-6, glenn mcdonald ·