Optimizing Database

I have an application that's allows user input, and is translating it by
stripping out the html tags and also doing some code translations. The user
is able to later edit their input. However it's unfeasible to reverse
translate it back as the logic would be too complicated, and there are
instances where it won't be possible.

So, what I'm thinking to do to speed up performance is to duplicate the user
data, one for native data, and the other for the translated data. When user
edits their input, the native data is shown. When the application is
showing the data in a page, the translated data is shown.

My question is, would it make a performance difference if I store the native
data and the translated data in the same table, or would it be better to
store the cached data in another table?"Shabam" <blislecp@.hotmail.com> wrote in message
news:mcydnQLoHJrXdPvcRVn-tQ@.adelphia.com...
>I have an application that's allows user input, and is translating it by
> stripping out the html tags and also doing some code translations. The
> user
> is able to later edit their input. However it's unfeasible to reverse
> translate it back as the logic would be too complicated, and there are
> instances where it won't be possible.
> So, what I'm thinking to do to speed up performance is to duplicate the
> user
> data, one for native data, and the other for the translated data. When
> user
> edits their input, the native data is shown. When the application is
> showing the data in a page, the translated data is shown.
> My question is, would it make a performance difference if I store the
> native
> data and the translated data in the same table, or would it be better to
> store the cached data in another table?

It's not easy to say, without any information about the table structure,
data types, indexes, number of rows, query patterns etc. Splitting the table
is unlikely to have any impact by itself, unless perhaps you put the new
tables on different filegroups on different physical disks.

If you have performance issues, are you sure that I/O is the limiting
factor? Have you reviewed the query plans and used Profiler to look for
bottlenecks? You might also want to feed a Profiler trace into the Index
Tuning Wizard to see if it recommends an alternative indexing strategy.

Simon