C
ChUIMonster
Guest
I don't think there should be an "issue" per se but there might be opportunities for some improvement. If the access to the eventual db table uses all 250 fields most of the times that you read it then this design is probably fine. (In my opinion that is unlikely.) OTOH if the fields tend to be used in easily defined sub-groups it might be beneficial to break it into multiple smaller records. Smaller records will be somewhat more efficient on several fronts. Although it is not obvious if that will actually make a noticeable difference from a performance perspective. That would really depend on what your application actually does with the data. (And if you are a client/server app a FIELDS list might be just as effective.) If you do lots of FOR EACH ... NO-LOCK queries that return large result sets of this data over a client server connection then smaller records (or a FIELDS list) can pack a lot more data into a message (especially with large -Mm and the various -prefecth* parameters) and that can be significant. Otherwise? You probably don't care.
Continue reading...
Continue reading...