Size of RecordSet

[christrinder]

Hello,

I'm producing a system at work which allows uses to store various inputs. The number of these inputs, which includes a handful of memo fields, is growing at quite a rate. Is there any 'best practice' surrounding the size of a RecordSet? Should I break the input down so they do it in a series of stages? Is there in fact any problem with processing such a large recordset? If it helps, I think the RS will contain approx 180 fields?

Thanks for any help.
Chris

[Mhtml]

180 fields! :eek: OMG that is a lot!

I don't know about any best practices on this sort of thing but I suggest making some code to write the query out! That is if you haven't already done it..

[alexk13]

Do you mean 180 fields or 180 records.:confused:

To me, 180 fields would mean that each record within your recordset contains 180 different dataparts(fields), 180 records would be 180 individual entries in your DB each with possibly 5, 10, 20 etc dataparts(fields)

If you can post some code, or even a DB struture, we might be able to help you better.

[christrinder]

Thanks for your input guys. Unfortunately, Yes, I did mean 180 fields, not 180 records. I have now coded it and it seems to work OK, although I'd be interested to hear your thoughts on the best practice of such situations and any tricks, hints for making life easier in similar situations in the future. The query statement took flipping ages to write!

[miranda]

I have to ask this, Is there no commonalities involved in these fields that could put them into another table? for example are you storing customer info as well as order info and shipping info and product info all in this one table? 180 datafields seems extreme to me.

[christrinder]

Hi,

Yes 180 is extreme... my DB and sites aren't normally so biazzare. It was actually a system for use at work. The businesses (we have about 140 throughout the UK) provide a monthly report including figures and narratives on their business performance. There is about 10 sections, each with a narrative and between 12 and 18 data pieces, i.e. turnover, current month, previous month, units sold new, sold used etc... I can't think of another way of storing it all, there's simply lots of info, each requiring a separate field. I'd be interested to hear any comments though... I am obviously still learning!

Cheers,
Chris

[miranda]

why not break down each of the 10 sections into their own table?

[Roy Sinclair]

If those "sections" are repetitions of the same basic fields then they are ripe for breaking them out of the main table and making a separate table where each "section" is a different record in the new table. That gives you the additional flexability to easily increase the number of "sections" should you require more of them later.

Look at this (http://www.devshed.com/Server_Side/MySQL/Normal/Normal1/page3.html) article on normalizing databases for more detailed information.