Here's a radical (and possibly useless response)!

It SOUNDS like the data you are trying to manage and display is highly relational. That can be a signal that it is not appropriate for storing in the Spectra CODB.

IMHO, the Spectra CODB is great at managing content but it is less valuable and adept at handling highly relational data.

It is NOT necessary to put all data managed by Spectra into the CODB, nor is it advisable. I would not try to move data into the CODB on which users need to make many relational type of joins because that is not what the CODB is good at.

How about storing your data in a regular, normalized database structure and use Spectra as a front end to get to it or present it?

You could use a Spectra object as the means for accessing it by storing a Product ID in the object and then use a method to access a stored procedure that actually gets the data. That way you offload the database-heavy type of work to the proper place but get the advantages of security, personalization and easy programming that come from using Spectra objects.

Wrap the code in a cfa_generatedcontentcache and you get the advantages of Spectra caching -- if your application allows you to cache data, i.e. it doesn't have to be real time dynamic each time the page is hit.

In addition to Product information, your site probably has what would more usually be considered "content" -- articles, press releases, etc. Store those in the CODB and access them using methods as usual.

This gives you one paradigm for accessing data -- Spectra methods -- and the data lives where it can be most efficiently accessed and manipulated.

I'm obviously missing lots of data about your exact situation, but I do think it is a common mistake to try to shoe-horn everything into Spectra when it doesn't need to be. (At least I like to think it's a common mistake since I made it! :-) )

David

-----Original Message----- From: Vaughan Evans [mailto:vaughan.evans@sai.com.au] Sent: Wednesday, December 27, 2000 1:33 AM To: Spectra-Talk Subject: too many database hits...

Hi all,

because of reasons I have not been able to control I have had to strip all shared embedded objects from my object model instead opting for the reference id option. The problem is that I have about 60 types. There is one 'master' type called Product and everything else is in some way related to it, by fully embedded or reference ids.

Because my data for each Product is spread across so many objects I'm now being forced to do loads and loads of cfa_contentObjectGet's per page. On a page where I used to have only one trip to the database I now have to do about 10 and this only provides about 7 summary pieces of info about the Product.

Also since its taking 10-ish (possibly more for larger Products) trips to the database for each product summary I'm concerned that if a search returns 20 products and this summary info is used as a search result (which it is going to be) then I'm up for 200 trips to the database!! I'm I hearing alarm bells?

Admittedly these objects are very large but I'm thinking that 10 quick trips per product must surely be a lot slower than 1 large-ish one.

I've thought of duplicating the properties that I need to display within the product object as well as a reference id so that if I only need basic info then I don't need all DB trips. This of course causes issues when objects are getting updated later on. eg. I'll have to keep the properties of my Product in synch with the object that's reference id is also part of that product. If someone updates one of the referenced objects how do I then synchronise that update with all the 'simplifyed' versions of it I have in my Product's?

Hmm this is all hurting my brain a bit!

Can anyone suggest any resolution to my problem? Are there any design/coding changes I can make to speed things up a bit? Any help on this will be greatly appreciated.

Thanks for your help as always, Vaughan

p.s. hope you're all having a great festive season ~~~~~~~~~~~~~ Paid Sponsorship ~~~~~~~~~~~~~ Get Your Own Dedicated Win2K Server! Instant Activation for $99/month w/Free Setup from SoloServer PIII600 / 128 MB RAM / 20 GB HD / 24/7/365 Tech Support Visit SoloServer, https://secure.irides.com/clientsetup.cfm. ------------------------------------------------------------------------------ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a message to spectra-talk-request@houseoffusion.com with 'unsubscribe' in the body.