Hi,

I am wondering if there is any performance penalty, (or design flaw) in
having more than one text datatype field in a table?
The text datatype fields in my case doesn't hold any excessive amount of
text, up to about 15,000 characters.

Any insigth on this would be appreciated

Thank in advance
Christian

The performance difference of one vs. multiple is mostly going to come out
if you often do SELECT * when you don't need those columns.  Which would
happen also if you store the TEXT values in a different table and join them
in (e.g. by a view or with queries) when they aren't necessary.  If you need
to store TEXT data, you need to store it somewhere.  And if you need to
return it in a query, you're going to pay the penalty regardless of which
table it came from.

As for the business use and design aspect, it really depends on more
context.  Can a row only have one or another populated?  Do they represent
the same kind of thing?  Is the number of TEXT columns fixed, or is it
likely that you will add more?  Can you give more specifics about the nature
of the TEXT columns and how they relate both to each other and to the entity
that is represented by the table?

A common design flaw I see is this:

CREATE TABLE dbo.Products
(
    Description VARCHAR(255),
    Review1 TEXT,
    Review2 TEXT,
    Review3 TEXT
)

Obviously a better design would be a table called Reviews which links back
via ProductCode or ProductID.  This way, you can have 0, or 3, or 12 reviews
and when you hit the 4th review you don't have to change the table design.
You don't have wasted pointers in the main table for products that haven't
been reviewed.  And you don't automatically get that blob data included in
your query plan unless you purposely join the table.

A

extracting data
Trying to match lowercase
too long...
datetime between problem
SQL Join question - getting most recent value in a history table