Posted by Arjen on 01/29/07 14:59

> 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 :)

Most seach engines I know by structure (smaller ones; I dont presume to
know anything about google yahoo etc) flatten their tables. No joins
whatsoever to increase performance as a trade-of for table size.

I had to do the same thing for a project im working on. Worst case I had
to join 10+ tables on the fly with more then 10k entries. Performance
was terrible so I join the data overnight and dig in the large pool of
data with a simple select :-)

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

[Back to original message]