Re: Question about a data structure


"Arjen" <dont@xxxxxxx> wrote in message
news:45bdef60$0$81840$dbd4d001@xxxxxxxxxxxxxxxxxx
Larry in Honolulu schreef:
I'm helping a friend with a website (aren't we all) that will have a long
questionnaire. There will be about 150 data items, all of which will be
chosen from radio buttons with four choices each. I'll store the
resulting data in a MySQL data table, and I'm thinking I don't want 150
fields there. Since all the responses can be coded as 1-4 (or 0-3), I'm
thinking of storing them in groups, with the values just strung together,
and later decoded. i.e. 12132 24331 31142 etc. That would reduce the
number of fields to a more manageable size.

What I'm really wondering is, where's the tradeoff? If I store it as a
string, it could just be a simgle 150 character string. If stored as
numeric (seems more efficient) then I'd have to keep the max values in
line with the numeric type.


....an aside.... what a pity that PHP doesn't enforce *strict* type
declarations... ho hum...


The data will eventually be used as numbers, but php can pretty easily
convert between so that doesn't seem to me to be an issue?

Any suggestions?

I once had a lot of trouwble storing floats as a varchar (it had it's
reasons -> preexisting structure and not much time). I had to strip them
digit by digit and then add them up again for php to recognize them as
floats. Declaring them as float had no effect whatsoever.

Why dont u save yourself lotsa trouble and do it right (and keep ur script
flexible). If you have 150 awnsers store them in 150 fields. If you have
an unkown amount of awnsers per user store them in a relative database.




or table?




Only if performance is a big issue you might want to reconsider.

--
Arjen
http://www.hondenpage.com



I agree with Arjen, for what it's worth...

Frankly, it's not worth the candle.... store 150 fields... it's easier,
quicker and probably execution-faster than messing about with
packing/unpacking strings and arrays. Better programmers than me (and
probably you) have already solved the execution-speed problem in MySQL code
IMHO. And, I suspect, the SQL for retrieving the results is most likely
easier and less error-prone than messing about with unpacking strings into
arrays etc.

Exact data structure will depend on what you want to do with the data, of
course. A more flexible data structure will entail a table of individual
responses (like one record per response). Unless your traffic is *very* high
(like constant), personally, I'd avoid 'stringing' together responses. Even
then, you'd have to test the execution-speed results, comparing 'stringing'
responses with the 150 fields approach. I'd bet the 150 fields would be
faster execution-wise :).

Happy to see results contrary to this, naturally :)

You might also like to check out the mySQL docos regarding upper limits on
database, table and field sizes.....



.