--- David E Jones <[EMAIL PROTECTED]> wrote:
> The main trick is caching. You can always measure > the time it takes > to do a query, but in general doing a cache look up > is generally two > orders of magnitude faster than a db query, and as > you mentioned > below the product information doesn't change as > often so caching > works well. > So, aside from a view-entity not actually being handled by the database by declaring an explicit SQL "CREATE VIEW...", is it possible to cache the results of a complex-alias view entity? If it's cached, is there then a difference whether it's being handled by an entity or a view entity on subsequent requests? > > What would the goal be for this? > Just brainstorming, three goals 1) Creating data warehousing techniques where the proof of concept end result is more applicable to a wider user base than simply the report generation that's generally more implementation specific. 2) Decrease the learning curve by separating the Product entity by the meaning of the data, without having to scrap much of the work that is in the demo installation. 3) Normalization. Decrease the potential of breaking one feature when introducing another (or creating roadblocks from new features being created). > In general this sort of thing is difficult and > costly I don't think it would be difficult as you'd be using a normalized data set to create the denormalized temporary table. Costly, perhaps. And that's where my question is really aimed at. If you had 100,000 products, would it take five, ten, fifteen minutes to run a service to recreate a new temporary table? And even if it did take that long couldn't you avoid the effect on a live system with the following strategy. Product - denormalized product related entity ProductSub1 - normalized portion of Product Entity ProductSub2 - normalized portion of Product Entity ... - more normalied portions of Product Entity ProductSubN - normalized portion of Product Entity Run service that denormalizes portions of ProductSub1, ProductSub2, ... ProductSubN to create ProductNext - denormalized product related entity not in use yet Drop Product, rename ProductNext to Product > and makes > things like real-time effective dated relationships > and other such > things difficult. > Wouldn't the dating of the relations in the normalized entities still be correct even though the denormalized entity is being dropped and recreated? > -David >
