PHP/mySQL Entries...

Limit the number of fields?

[createErrorMsg]

I'm wondering if anyone knows of a compelling reason to limit the number of fields in a mySQL table when the data (all text) will be pulled and used to build dynamic pages.

I have an entry form that currently adds 11 fields for each page entry. I've split the content up this much in order to allow myself precise control over the display of the content, but I'm wonderig if there are any drawbacks to having this many seperate DB fields.

Is there a reason to combine some of those fields (doable but not ideal) and shrink the number, or does it ultimately not make a difference?

Thanks in advance for any responses!

cEM

[StupidScript]

With one relatively minor caveat, I can't see anything wrong with having as many fields as you need.

The caveat is that since each field definition takes up some space, more fields = larger database. As an adjunct, more fields also adds a teensy weensy bit more overhead to queries.

Taken too far (WAY too far, like 100,000 fields per record), the database quickly becomes unwieldy, and everything slows down. But this shouldn't happen in a well-designed database where the developer splits the database up into useful tables.

11 fields per record is definitely fine.

[createErrorMsg]

I take from your comment that as long as the 11-fielded records are the only data stored in that particular table, I'll be fine, and that's actually how I had things laid out, so good.

Thanks. I appreciate the response.

cEM

[StupidScript]

Exccccellent. :)

Think modular:
You'll need these queries for this kind of page ...
you'll need this table and that table for query 1 ...
you'll need this table and that table for query 2 ...
users in one ...
products in another ...
prices in a third ...
etc ...
etc ...

The server's processor and RAM are much faster than the hard drive.

Queries including many specialized tables are faster/leaner/cheaper because the volatile read/write storage stores results, and stores smaller batches of table definition/content data before "reading" the data and deciding what to keep and what to purge.

Queries within larger, more generalized tables need to store more in volatile memory, moving quickly into virtual RAM on the hard drive, as they accomodate big table definitions/content data, "read" the data and make their analysis before deciding what to purge.

Plus, using a well-organized modular approach, you'll build a collection of widgets that you can use in lots of other projects.

(Whew! :)

So: modular. IMHO