Table size best practice

[Mondeo]

I have an SQL 2005 table which contains 200 columns, they are mostly money type.

 

Shouild I be concerned about performance with this many fields, would it make sense to split the table up, or is 200 okay in one table?

 

There will be about 20,000 rows.

 

Thanks

[amir100]

If it's normalized then I don't see any other reason to split your table. If we're talking about performance then there's more to simply splitting tables. :D

 

CMIIW.

[Eduardo Lorenzo]

as amir mentioned, if the tables are normalized, you should not worry.

 

Most performance hits with data-driven applications, other that poor DB architecture come from poor/unoptimized stored procedures or SQL Statements, bandwith.. etc.

[amir100]

A "Select * ..." from that table would require a generally large resource from your database server engine. :p

 

Careful.

[Eduardo Lorenzo]

and anyways, I believe tables (when created) in SQL Server has a fixed file size regardless of the number of rows. With this I mean, when a table is created and you assign it 10mb, it is 10mb whether it has a minimum or maximum number of rows. Maximum being 10mb.

 

in addition to being careful with Select *, also do be careful with using nulls. as a general rule, we should avoid having nullable columns.

[Nerseus]

Offhand, 200 sounds like a LOT of columns - just a general purpose bad smell.

 

As far as limits, SQL Server has an 8k limit. Meaning, any one row of data in a table cannot exceed 8192 bytes, give or take. 200 fields at 8 bytes each is only 1600 bytes so you're ok there.

 

-ner