I think you'll find your answer in a book about database design. I don't
know much about the book you're getting, but I am sure it will follow you
through some simple examples which should lead you on the right track.
I'm not sure if I am totally getting this right, but I think you'd be
better off by having one table which basically lists each category you
have, and then when assigning something to that category, just make a
reference to the category ID.
something like:
create table categories (
categoryID smallint(4) not null auto_increment,
categoryNAME varchar(40) default '' not null,
primary key( categoryID )
);
(field names are chosen to be destriptive, there are better ways of
assigning names)
and then you can just reference the categoryID in your other tables, hence
saving you space and saving you a lot of trouble. Should you happen to
change the name etc, you'll only have to change it once :)
MySQL doesn't support true relations, but this is one way to sort of fake
it.
Hope this guides you on the right track somehow. btw; I found O'Reillys
book on MySQL (don't remember the exact name right now) really useful in
learning about how to create databases.
Atle
On Tue, 23 Jan 2001, Ashley M. Kirchner wrote:
>
> I'm trying to get a project going which is basically converting a
> price catalog into a database, however, going over the printed catalog,
> basically this is what it looks like:
>
> service_category_1
> description (text)
> service_1
> description (text)
> prices (integers)
> notes (text)
> service_2
> description (text)
> prices (integers)
> notes(text)
> service_3
> etc...
> service_category_2
> description (text)
> service_1
> description (text)
> prices (integers)
> notes (text)
> service_2
> etc...
>
>
> So I'm trying to figure out what is the best type of structure to
> build. Should I make a separate database for each individual category,
> and put the different services under that? Or should I have different
> DBs for each service?
>
> Also, I need to make this in some way that it's easy for others to
> update (although I think this will lean more towards the interface
> programming than the DB itself)
>
> Any suggestions? Or better yet, any book recommendations on DB
> structures and what not? I plan on getting MySQL (
> http://www.amazon.com/exec/obidos/ASIN/0735709211/ref=wl_em_to_i4 ), but
> I'm not sure that's enough as I've never done much with MySQL aside from
> your very (VERY) basic DB setup, and simple tables and queries.
>
> AMK4
>
> --
> W |
> | I haven't lost my mind; it's backed up on tape somewhere.
> |____________________________________________________________________
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ashley M. Kirchner <mailto:[EMAIL PROTECTED]> . 303.442.6410 x130
> SysAdmin / Websmith . 800.441.3873 x130
> Photo Craft Laboratories, Inc. . eFax 248.671.0909
> http://www.pcraft.com . 3550 Arapahoe Ave #6
> .................. . . . . Boulder, CO 80303, USA
>
>
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
