The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

Strings Vs Table Size

Hi,

I am trying to decide on which is best. I have approximately 10,000 users whom make approxmiately 40 entries each into my database table would it be better to have each of the 40 entries in individual rows or as a string in one cell of a row? I really want to know the pros and cons for adding and referencing the data.

Also, at what stage does a database table have too many rows or become unweildy?

It is not unheard-of for tables to contain a hundred or two columns. A table 40 columns wide is perfectly acceptible, IMO.

HOWEVER.. Consider the following hypothetical situation:
You have a web site that surveys its users. Your survey application is standalone, and the surveys vary, but you decide to backup the querystring data (one big string..) in a table. -Then yes, one col for querystring, one for date, and one for surveyid/userid or something. To read the data, you simply read the name-value-pairs from the qstring field, do a split(), and you can then reference responses to surveys of any design structure.

I have a client table, clients can choose to optin for email alerts for specific events on specific dates.

I was tring to decided whether to place a sting with a list of id's for each of the alerts in the client table or reference the client table to another tbale with a list of clientIDs and event alert ID's.

I think I've now decided to opt for the later option.
Thanks for you help.