don't look now, but it's likely my smtp configuration. I hear you about this, and maybe that's why these xml datatypes exist.
I wonder though, if you could make a "Fat" table with mostly all the typical attribute one might search for -- A to-many table would contain only those attributes that were truly unusual or otherwise lent themselves to it. Finally, a to-many fetch finds the right item. So, you're right that who would want to use that UI for adding attributes, but the same goes for the other data storage technique. Either way, you'll want a nice, natural and easy UI for the user and that's going to require you writing something for it. Sounds like work, but it sounds like a really cool project too! keep us posted about your results -- On Jan 17, 2013, at 8:16 AM, Flavio Donadio <[email protected]> wrote: > Jesse, > > > I think I am missing some messages. This is the second time in this thread > that I don't get a message. I took this from Paul Hoadley's reply. Thanks, > Paul! > > On 16/01/2013, at 5:00 AM, Jesse Tayler <[email protected]> wrote: > >> 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 -- > > > Well, my problem with the table-based approach is the number of queries that > would be executed just to show a product on a page. With most products having > between 50 and 70 items in their spec sheets, I can see the database being > hit with more queries than necessary. This would be negligible on current > hardware, though... > > One other problem that I see: how can I specify which spec items belong to a > product category and how it should be organized and ordered? I don't want my > users having to add each item from a EditRelationshipEmbedded* when inserting > products, because item order and consistency is important to me. > > I see that, no matter which of the techniques I use, I will have a LOT of > work... > > >> 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? > > Well, I don't know about the internals, but it works. As Paul noted, XPath is > a W3C recommendation and it's a nice way to manipulate an XML document. Since > PostgreSQL does some sanity-checks on XML data, it should make my life easier > too... > > > 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/archive%40mail-archive.com This email sent to [email protected]
