On Nov 10, 2006, at 9:26 PM, Chris Howe wrote:
How would one best go about testing how expensive a
complex alias is?
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.
Additionally, alongside the discussion on the data
warehousing strategies how feasible do you think it
would be in a real setup to create a "temporary"
Product entity that gets truncated and rebuilt by a
service of normalized entities since most of the live
ecommerce use of the Product entities are retrieval
queries and not create update or delete? This being
rebuilt once a day, once a week, once a product line
change, etc.
What would the goal be for this?
In general this sort of thing is difficult and costly and makes
things like real-time effective dated relationships and other such
things difficult.
-David
--- David E Jones <[EMAIL PROTECTED]>
wrote:
Actually, this may have undesired side effects that
actually slow it
down and/or make caching less efficient...
-David
On Nov 10, 2006, at 4:42 PM, Chris Howe wrote:
I'm curious as to how much of a performance hit it
would be to create a view entity between product
and
each langauge (ie ProductViewEN, ProductViewES,
ProductViewFR, ProductViewIT) using a complex
alias
for this.
This would have the benefit of being able to i18n
more
than just the description and also perhaps jump
start
the normalization of the Product entity that was
discussed a few months back so that you don't have
the
overflow of fields that don't make sense to the
product type (ie the rental fields for sale
products,
the product dimension fields for electronic
products,
etc)
--- Jacques Le Roux <[EMAIL PROTECTED]>
wrote:
David,
Forget it, I was thinking that we may not use
anymore the category description field, but I
guess
it's needed if we want to keep
things fast.
So Si, it seems that if you want to remove the
description field from demo ProductCategory data
it's ok, isn'it ?
Jacques
Jacques,
Sorry, you lost me. What is the "DB description"
field, and what
refactoring and such would this imply?
-David
On Nov 10, 2006, at 1:53 PM, Jacques Le Roux
wrote:
David,
OK, and what about the DB description field
always needed and some
DB refactoring that this (and more eventually)
may imply ?
Jacques
From: "David E Jones"
<[EMAIL PROTECTED]>
For "demo" data, the performance doesn't
matter
as much. Better to
demonstrate and test, at least with one of the
fields.
-David
On Nov 10, 2006, at 1:12 PM, Jacques Le Roux
wrote:
I'm not sure because as David already
explained there are 2 ways
for this.
Quick one : std description field
Longuer one : std description field overidden
by data source
content (this implies a default locale that
seems ok now)
And IIRW David seemed to keep std description
field because it's
quicker.
Actually, if we do according to your
proposition is the DB
description field always needed ?
And if we go in this direction maybe some DB
refactoring have to be
thought about ?
Jacques
From: "Si Chen"
<[EMAIL PROTECTED]>
So should we remove the description field
from these
ProductCategory
in the demo data? I think so, or how would
one be able to see the
alternate locale description?
