> Ideally - a database, would be 1 large, compressed XML document, and the > database engine, would be aware of values, vs elements, etc.
In other words it would be an XQL/XPATH/Whatever engine. Actually that makes it VERY much like most OODBMS products. The problem with them is that they don't have good ways to INDEX things. Think of an OODBMS as basically like a tied SDBM file, but where you can store refs and if you store an array or a hash ref it, that following the ref gives you that item (so you could think of the entire DB as a "tree" of perl variables stored in hashes/arrays etc. but where those variables can automagically persist on disk. Goods does EXACTLY this. Here's the problem, suppose you want to store 50 "message" objects in this database. How do you index them? If they are perl hashes they can only be indexed on one index (hash key). If you want to have 2 indexes things get much uglier, and pretty soon you have basically reinvented SQL. The same problem happens with XPATH. So now you need an Object-Relational database, and those are both expensive and a royal pain in the behind to use. In the long run its probably best to just map your fairly simple object schema to SQL. > > Best regards, > > Melvyn Sopacua > WebMaster IDG.nl > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > If it applies, where it applies - this email is a personal > contribution and does not reflect the views of my employer > IDG.nl. > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
