I have a VERY wide table with approximately 150 fields.  I am adding another
feature and need to add an additional 20 fields to that table.  In concern
for network performance, would it be better to create a separate table to
store these 20 additional fields?

Or, would it be safe to add these fields to the wide table provided I limit
selection to the fields I need via SQL during program operation.  (i.e.
SELECT FIELD1, FIELD2, FIELD3 from TABLE)

Thank you.

Brian Kennedy
DBISAM C/S 4.24 B1

Brian,

<< I have a VERY wide table with approximately 150 fields.  I am adding
another feature and need to add an additional 20 fields to that table.  In
concern for network performance, would it be better to create a separate
table to
store these 20 additional fields? >>

I would try to add the 20 fields first and see how things go in terms of
performance.  You do start to see a performance decrease when record sizes
start reaching 2k or so, simply because a lot of times you're reading so
much data only to inspect a field or two.  So, in essence, the real
determining factor is not the number of fields, but rather the record size.
You can see the total record size by opening the table in the DBSYS utility
and viewing the Structure tab of the open table.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Thanks.  Sorry for the delayed reply.  I have been away for the holiday
season!

Hmmm...record size is currently near 4K already!  So, just to clarify, even
if my SQL is only pulling the fields it needs from the table (i.e. SELECT
Field1, Field2, Field3 from TABLE), performance could be still affected
since the table is so wide?

Thanks Tim.

Brian


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:9E88DC9F-58A9-4EA4-92D7-0CC52E873662@news.elevatesoft.com...
> Brian,
>
> << I have a VERY wide table with approximately 150 fields.  I am adding
> another feature and need to add an additional 20 fields to that table.  In
> concern for network performance, would it be better to create a separate
> table to
> store these 20 additional fields? >>
>
> I would try to add the 20 fields first and see how things go in terms of
> performance.  You do start to see a performance decrease when record sizes
> start reaching 2k or so, simply because a lot of times you're reading so
> much data only to inspect a field or two.  So, in essence, the real
> determining factor is not the number of fields, but rather the record
> size. You can see the total record size by opening the table in the DBSYS
> utility and viewing the Structure tab of the open table.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Brian,

<< Hmmm...record size is currently near 4K already!  So, just to clarify,
even if my SQL is only pulling the fields it needs from the table (i.e.
SELECT Field1, Field2, Field3 from TABLE), performance could be still
affected since the table is so wide? >>

Yes.  This is one of the reasons why it is important to normalize tables as
much as possible given the design/join performance considerations.

--
Tim Young
Elevate Software
www.elevatesoft.com

Okay, thank you Tim.  Not only would it probably be best to have a separate
table for the new fields, I guess it might be a good idea to also break this
table up into separate tables so the record size is smaller.  I could see
the width of the table possibly hindering performance over lower bandwidths.

Brian

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:129F73A2-A96D-4988-8408-996F928DAC48@news.elevatesoft.com...
> Brian,
>
> << Hmmm...record size is currently near 4K already!  So, just to clarify,
> even if my SQL is only pulling the fields it needs from the table (i.e.
> SELECT Field1, Field2, Field3 from TABLE), performance could be still
> affected since the table is so wide? >>
>
> Yes.  This is one of the reasons why it is important to normalize tables
> as much as possible given the design/join performance considerations.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>