Tripp Lilley <[EMAIL PROTECTED]> wrote: > >On 1 Mar 2002, Jason Hildebrand wrote: > >> Performance-wise, MiddleKit may be a bit slower (in terms of the number >> of queries) than doing your own SQL, but it gives you the data in >> ready-to-use objects, and saves a lot of development time. > >My anecdotal experience is that MiddleKit is currently wicked slow, >because it's largely unoptimized, and does not internally make much use of >the database engine's available performance.
The focus of my short-span attention most recently has been an "XML instance to relational database" mapping engine, although being able to store instances and then retrieve them probably doesn't approach MiddleKit's sophistication or usefulness. The mechanism employed does permit independence at the application level from the underlying store, and it gives the developer the ability to describe the database tables which are actually being used; indeed, it's necessary to describe the tables, but it would also be possible to generate such descriptions if that were desired - personally, I don't believe too strongly in machine-generated database schema. One of the "easy but actually hard" things in writing these kinds of mapping engines is how to take advantage of SQL features so that access to the database remains somewhat optimal while the decoding of the results by the engine remains straightforward. In my more naive days, I once wrote some libraries in Java which attempted to implement a multivalued data store in a "normal" relational database (which isn't *so* hard), but it also had to provide support for the proprietary multivalued database query language - it's not hard to imagine how the above tradeoff posed significant problems. [...] >Anyway, back to the original point... What Jason said about the nature of >the clauses you would typically pass to the fetchObject methods is >dead-on. They're generic, and you really shouldn't find yourself using >sub-selects and the like too often, as long as you're normally querying >based on the state of the objects you're fetching, not "related" objects. For related material, I would suggest looking at the Enterprise JavaBeans 2.0 specification, particularly the variant of SQL that they use to describe "finders". Myself, I'll hopefully get round to thinking more seriously about how querying that is more sophisticated than "primary key lookup" can be done in my XML-centric view of the world - I wonder if any of the XML querying specifications are relevant. Jim Kraai <[EMAIL PROTECTED]> wrote: > >Has there been any discussion of using the DB-SIG's DB-API spec as a basis >for abstracting support for new databases? There was a fair amount of discussion about this in the last few months, and recently someone announced the "open sourcing" of some libraries to help with portability issues (including an SQL parser, I believe). Paul -- Get your firstname@lastname email at http://Nameplanet.com/?su _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
