Normalizing a table with less than 500 rows

[Evan Escently]

Hi,

I've laid out a _very_ simple database that tracks my artwork the
table 'works' looks like:

+---------+----------+------------+------------+-------------+
| work_id | title | media | category | year | etc....
+---------+----------+------------+------------+-------------+
| 1 | One | oil | painting | 2002 |
+---------+----------+------------+------------+-------------+
| 2 | Two | stone | sculpture | 2003 |
+---------+----------+------------+------------+-------------+

and so on...

My question is, if I KNOW that I'll never have more than 500 rows in
the table (I don't make that much work per year) do I need to
normalize the table?

Right now I have alot of repeating data (say I make 10 "oil" piecesper
year) and from what I gather about normalizing the media row should be
a media_id row, with intergers pointing to a media table that indexes
each media:

works:
+---------+----------+------------+------------+-------------+
| work_id | title | media_id | cat_id | year | etc....
+---------+----------+------------+------------+-------------+
| 1 | One | 1 | 1 | 2002 |
+---------+----------+------------+------------+-------------+
| 2 | Two | 2 | 2 | 2003 |
+---------+----------+------------+------------+-------------+

media:
+----------+----------+
| media_id | media |
+----------+----------+
| 1 | oil |
+----------+----------+
| 2 | stone |
+----------+----------+

but my question is, in a small table, one with at most 500 rows, am I
a loon to use the table at top, full of VARCHAR columns?

Most of the articles I've read about normalization talk about table
becoming very large, e.g. "I'm trying to SELECT 1,500,000 rows..." but
what I'm wondering is if you're making a table that has far less rows,
outside of "doing the right thing" by normalizing, is there a benefit
to spliting one large table into many small tables?

- Evan

[Randell D.]

"Evan Escently" <ev**********@yahoo.com> wrote in message
news:18*************************@posting.google.co m...

Hi,

I've laid out a _very_ simple database that tracks my artwork the
table 'works' looks like:

+---------+----------+------------+------------+-------------+
| work_id | title | media | category | year | etc....
+---------+----------+------------+------------+-------------+
| 1 | One | oil | painting | 2002 |
+---------+----------+------------+------------+-------------+
| 2 | Two | stone | sculpture | 2003 |
+---------+----------+------------+------------+-------------+

and so on...

My question is, if I KNOW that I'll never have more than 500 rows in
the table (I don't make that much work per year) do I need to
normalize the table?

Right now I have alot of repeating data (say I make 10 "oil" piecesper
year) and from what I gather about normalizing the media row should be
a media_id row, with intergers pointing to a media table that indexes
each media:

works:
+---------+----------+------------+------------+-------------+
| work_id | title | media_id | cat_id | year | etc....
+---------+----------+------------+------------+-------------+
| 1 | One | 1 | 1 | 2002 |
+---------+----------+------------+------------+-------------+
| 2 | Two | 2 | 2 | 2003 |
+---------+----------+------------+------------+-------------+

media:
+----------+----------+
| media_id | media |
+----------+----------+
| 1 | oil |
+----------+----------+
| 2 | stone |
+----------+----------+

but my question is, in a small table, one with at most 500 rows, am I
a loon to use the table at top, full of VARCHAR columns?

Most of the articles I've read about normalization talk about table
becoming very large, e.g. "I'm trying to SELECT 1,500,000 rows..." but
what I'm wondering is if you're making a table that has far less rows,
outside of "doing the right thing" by normalizing, is there a benefit
to spliting one large table into many small tables?

- Evan

Einstein once said that its easy to make things complicated - and
complicated to make things easy...

My guess is the benefit will be so insignificant as not even worrying
about - even if your database was to grow five or ten times your expected
size... I think you're making something easy, complicated - I'm sure there
would be a saving if you were talking about tens of thousands of records...
but nothing visable for something weighing in at a few hundred.... somebody
else here though might prove me wrong though...

randelld
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?

[BDR]

The one basic rule to follow when creating your columns is, if you don't
know what to use and you can get away with 255 characters or less, then
use varchar.

Probably the ONLY time you'll ever need to be concerned is if this
server was an old 386 running at 16 mhz... lol.

I've run numerous configurations (including old pentium 266 processors)
with mysql and even with several hundred rows, and no indexes, virtually
no select statement has ever required more than 1 second, including
those with multiple table joins.

You've really got nothing to worry about, Your driving a Mercedes 500
and the only thing you're pulling is a unicycle with nobody on it.

Just my 2 cents anyway...

Evan Escently wrote:

Hi,

I've laid out a _very_ simple database that tracks my artwork the
table 'works' looks like:

.... snip...

[Randell D.]

"Evan Escently" <ev**********@yahoo.com> wrote in message
news:18*************************@posting.google.co m...

Hi,

I've laid out a _very_ simple database that tracks my artwork the
table 'works' looks like:

+---------+----------+------------+------------+-------------+
| work_id | title | media | category | year | etc....
+---------+----------+------------+------------+-------------+
| 1 | One | oil | painting | 2002 |
+---------+----------+------------+------------+-------------+
| 2 | Two | stone | sculpture | 2003 |
+---------+----------+------------+------------+-------------+

and so on...

My question is, if I KNOW that I'll never have more than 500 rows in
the table (I don't make that much work per year) do I need to
normalize the table?

Right now I have alot of repeating data (say I make 10 "oil" piecesper
year) and from what I gather about normalizing the media row should be
a media_id row, with intergers pointing to a media table that indexes
each media:

works:
+---------+----------+------------+------------+-------------+
| work_id | title | media_id | cat_id | year | etc....
+---------+----------+------------+------------+-------------+
| 1 | One | 1 | 1 | 2002 |
+---------+----------+------------+------------+-------------+
| 2 | Two | 2 | 2 | 2003 |
+---------+----------+------------+------------+-------------+

media:
+----------+----------+
| media_id | media |
+----------+----------+
| 1 | oil |
+----------+----------+
| 2 | stone |
+----------+----------+

but my question is, in a small table, one with at most 500 rows, am I
a loon to use the table at top, full of VARCHAR columns?

Most of the articles I've read about normalization talk about table
becoming very large, e.g. "I'm trying to SELECT 1,500,000 rows..." but
what I'm wondering is if you're making a table that has far less rows,
outside of "doing the right thing" by normalizing, is there a benefit
to spliting one large table into many small tables?

- Evan

Einstein once said that its easy to make things complicated - and
complicated to make things easy...

My guess is the benefit will be so insignificant as not even worrying
about - even if your database was to grow five or ten times your expected
size... I think you're making something easy, complicated - I'm sure there
would be a saving if you were talking about tens of thousands of records...
but nothing visable for something weighing in at a few hundred.... somebody
else here though might prove me wrong though...

randelld
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?

[BDR]

The one basic rule to follow when creating your columns is, if you don't
know what to use and you can get away with 255 characters or less, then
use varchar.

Probably the ONLY time you'll ever need to be concerned is if this
server was an old 386 running at 16 mhz... lol.

I've run numerous configurations (including old pentium 266 processors)
with mysql and even with several hundred rows, and no indexes, virtually
no select statement has ever required more than 1 second, including
those with multiple table joins.

You've really got nothing to worry about, Your driving a Mercedes 500
and the only thing you're pulling is a unicycle with nobody on it.

Just my 2 cents anyway...

Evan Escently wrote:

Hi,

I've laid out a _very_ simple database that tracks my artwork the
table 'works' looks like:

.... snip...