Actually, I am pretty certain you'll find it both less complicated and better performing --
I didn't know about this "xpath" or whatever you are using to determine which XML attribute is which during your query but I can't imagine how a table based approach would perform worse -- plus, it should be a lot simpler to build and to maintain. should be -- Anyway, I guess with this xpath technology, you don't need to worry - but I wonder what it does underneath to do the same thing? I would guess--- it loads up any rows that could be a potential hit, then parses the XML, then decides what attributes are what and -- finally sends the correct object down the pike, it just seems that's a lot of in-memory processing that could be handled by the database only returning objects you'll be needing. The more I think, the more I'd be certain that you've made clear and scientific performance and maintenance tests before moving ahead with that approach. On Jan 15, 2013, at 12:11 PM, Chuck Hill <[email protected]> wrote: > What database are you using that allows xpath in a select? > > > On 2013-01-15, at 7:33 AM, Flavio Donadio wrote: > >> Jesse, >> >> >> Yes, I get it. It's a nice idea, but it's also kind of complicated, at least >> i my case. >> >> I'll have several ProductCategories, each with very distinct specifications, >> like "bar code scanners", "thermal printers" and "wireless LAN >> infrastructure". All Products in a ProductCategory are similar to each >> other, but can be completely different from the other ProductCategories. >> >> So, if one of my customers needs to find, for example, a barcode scanner >> with laser technology, the query would be like: >> >> SELECT * FROM Product WHERE ProductCategory=? AND xpath('specifications', >> 'engine/technology/text()') = 'laser'; >> >> This is a simple example, but you can imagine if we add more "filters" to >> this search... >> >> Besides generating the HTML form for Product creation and modification, I >> can also use the XML template (stored in the ProductCategory) to generate >> these search forms on the website. I can create product comparison tables >> easily with this XML structure... >> >> >> Best regards, >> Flavio >> >> On Jan 15, 2013, at 8:33 AM, Jesse Tayler <[email protected]> wrote: >> >>> not to throw a wrench, >>> >>> but I would NOT store XML data but rather, >>> >>> I would use a key-table design where you can simply add arbitrary keys to >>> things like this using queries and relationships. >>> >>> I once did a system for restaurant menus that had to understand the type of >>> object (salad) would have a choice of dressing, but a caesar would not and >>> a potato would have a choice of other things or whatever else. There were >>> structures, but also an exception to every rule really. Kind of a challenge. >>> >>> basically, I'd watch out for putting structured data into the database and >>> would suggest considering a flat table structure instead. >>> >>> you'd likely still want custom components to handle your UI because it >>> sounds important, but I would just consider how a database can store data >>> that is unformatted and unstructured and I'd add the xml structures to it >>> at another layer. >>> >>> hope that helps! >>> >>> >>> On Jan 15, 2013, at 7:18 AM, Flavio Donadio <[email protected]> wrote: >>> >>>> >>>> On 13/01/2013, at 07:12, Paul Hoadley wrote: >>>> >>>>> I suppose it depends how frequently you expect the template XML to >>>>> change, if at all, and whether you envisage changing it on the fly, or if >>>>> you could just restart the application to pick it up from properties or a >>>>> text file. Never changes? You could use text files (in Resources, or >>>>> downloadable from somewhere, say S3) that are picked up during >>>>> application initialisation. Changes frequently and is user-editable? >>>>> Store it in the database—perhaps an XMLTemplate entity, one for each >>>>> template type. So many options. >>>> >>>> Yea, Paul. I am inclined to store the template XML in the database. Since >>>> the template is the same for every product in a given category, I am going >>>> to store the template in a property of the ProductCategory entity. >>>> >>>> The template will change from time to time, especially when new products >>>> bring different features that need to be included in it. >>>> >>>> But my question is: how do you guys recommend that I do to: >>>> >>>> 1. Generate the HTML form; and >>>> >>>> 2. Insert/update data in the XML so I can store it in the entity. >>>> >>>> I am almost certain that I will need a custom component for this. >>>> >>>> >>>> Regards, >>>> Flavio >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >> >> This email sent to [email protected] > > -- > Chuck Hill Senior Consultant / VP Development > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/gvc/practical_webobjects > > Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing > Companies in B.C! > Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of > Canada’s Fastest-Growing Companies by PROFIT Magazine! > > > > > > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
