[thelist] DB question

Michael Barrett mbarrett at triad.rr.com
Thu Mar 1 16:04:49 CST 2001

I'm doing some pre-planning for project, and I'm thinking about the
database that will be needed. Being a data-newbie I got to wondering...

Is it generally more efficient to have fewer tables in a database?
I'm thinking of a db that relates images to data.
The images need certain information, size, description, blah blah.

The images are also pictures of product. I will need a product table of
course, with the classic sku#, description, blah blah.

Each image depicts one *or* more individual items, i.e. 1 vase vs a set of 6

Is it advisable to have one big fat image table that holds all the image
data, plus many columns for sku#s with one product table?


A reasonably trim image table with just image data, a separate image/sku
table, which relates image#s to sku#s, and a third product data table?

My gut reaction is that dividing the data up into logical groups, and
separating into tables might be less efficient, but will be easier to code
for, and maintenance later.

<tip type="MYSQL data entry">
Trying to enter data into a MYSQL db, but don't have a handy GUI app, or
can't stand all that typing.?

Build your tables in Excel, or your favorite spreadsheet app. In a duplicate
file (backups save lives), insert columns to hold SQL statements (insert
into table blah blah), any separators or syntax you may need (commas, single
quotes, parentheses, yadda, etc.)

Export the whole mess as a csv file (comma delimited) or a space delimited
text file. Find/Replace any junk in your favorite text editor (ahem BB
edit), save the file as something like "table_dump.txt". Upload the file to
your server. Telnet to your host, from the command line type "mysqldump
databasename < table_dump.txt" and all the data will be dropped into your
db. If there's a goober in your SQL, the command line will give you a
friendly error message, and a line number to point out the problem.

-- Michael

More information about the thelist mailing list