Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Indexing solution for native XML database
 On 11/30/05, Michael Kay <mike@s...> wrote: > > > Celko often writes about this approach to prove that it can > > be done, but it > > > just goes to convince me that it shouldn't be done. > > > > > > > Ok, I'll bite: care to explain? Is it just the simple forms of > > adjacency list you don't like or all nested set approaches? > > Relational databases work well when rows in tables correspond to objects in > the real world. If you need to design your own data structures to represent > graphs, lists, trees and the like, then it's interesting to know that it's > feasible to map such structures onto bags/sets of tuples, but this doesn't > make it my preferred implementation technique. I don't see what I gain by > having to model all my data using this very limited set of structures. Celko > is showing how you can do multiplication using a system that only supports > addition, and thereby convinces me that I'm better off using a system that > can do multiplication. Wow. Now you've got me somewhat confused. Does the same line of thought extend to using joining tables to reduce many to many relationships to 3rd normal form? Celko after all is just adding tables and columns to normalize out relationships, something you do for any properly designed RDB schema of any complexity. Surely you're not saying that you are opposed to using RDB's for any real world problems requiring extensive normalization? Or maybe you're saying that if you've got to do extensive normalization you prefer other forms of databases? Personally, having had to slice and dice normalization problems along many different dimensions one of the things I like about RDB's is that you can reduce any problem to the same set of primitives and know exactly what the rules are for manipulating those primitives in relationship to each other. It's not that the system doesn't support multiplication, it's that the system allows me to specify how the multiplication should be done if need be. More precisely; if need be, it allows me to find an isomorphisim to map any new group to a known group. Given that any closed boolean algebra forms a group sooner or later you're going to end up doing this if you do any large amount of data manipulation. Knowing that you are doing this up front, and knowing what the rules are, helps to avoid a lot of bad designs and programming errors. Now, I'd agree that it might be nice to have one single self tuning universal database model that didn't require you to think about how to perform normalization or other optimizations, but given that generalized universal graph traversal is known to be a NP complete problem I'm not holding my breath... I know you don't restrict yourself to only Java language primitives and will create new composite data structures, and code multiple classes and methods quite freely in Java (I've studied some of your code :-) so why is SQL so different? -- Peter Hunsberger 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
