As a follow up: I tried the situation on MS SQL Server 2000, where I got
an Object simply named article, and a table with article properties like
title, body. In total I had 20 properties.
The lookup query approach used much more CPU power, and needed 135ms to
complete. The one in all query approa
Different opinions about these sort of approaches exist, some people
keep telling others that this is the right approach because you won't
mix different types of objects.. , my opinion out of personal experience
.. don't do this.
I have code reviewed many applications, and this approach of gettin
how big ias this property table and how much does it grow? Caching
might work but if it doesn't grow/change much why not just query it
once and make a simple lookup structure in the application scope.
Adam Haskell
On Mon, 17 Jan 2005 15:53:20 -0500, sonicDivx <[EMAIL PROTECTED]> wrote:
> I have
If your method is only going to get called a hundred times per day, I
wouldn't worry about caching too much, it's not going to have much
efffect if your lookup queries are simple (which they should be).
If you want to optimize, a better route would probably to read the
lookup table once when you i
4 matches
Mail list logo
