Populating a database

2007-05-31 Thread Officelink
Hi everyone,

I've just created the structure of a database and am deciding the best way
to insert the data. The database includes a number of tables that have
foreign keys referencing primary keys in other tables. The application I'm
building will make use of the data in one of the following ways (haven't
decided yet):

1) The data will be used in a Flash movie and will have an accompanying CMS
associated with it, or
2) The data will be used in a Flash movie but won't have a CMS

If I decide on a CMS, should I build this first and use the PHP and MySQL to
create an interface whereby I can enter the data and have the foreign keys
entered in the correct place automatically?

Or if I don't go with a CMS and just need to populate the database for use
in Flash, what's the most efficient way of doing this? I mean I'm aware I
can populate it with a .csv file but this wouldn't take care of inserting
the correct foreign key values against the appropriate records. I wouldn't
have to manually enter these foreign keys, would I?

So does the way you populate a database depend on whether you're using a CMS
or not? Have I got the right idea?

Any help much appreciated.




Re: Database design

2007-05-28 Thread Officelink
 DEFAULT CHARSET=latin1;


CREATE TABLE `garment_to_description` (
  `garment_id` smallint(5) unsigned NOT NULL,
  `desc_id` smallint(5) unsigned NOT NULL,
  PRIMARY KEY  (`garment_id`,`desc_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


CREATE TABLE `garment_to_size` (
  `garment_id` smallint(5) unsigned NOT NULL,
  `size_id` smallint(5) unsigned NOT NULL,
  PRIMARY KEY  (`garment_id`,`size_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


CREATE TABLE `garment_to_title` (
  `garment_id` smallint(5) unsigned NOT NULL,
  `title_id` smallint(5) unsigned NOT NULL,
  PRIMARY KEY  (`garment_id`,`title_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


CREATE TABLE `garment_type` (
  `type_id` smallint(5) unsigned NOT NULL auto_increment,
  `supplier_id` smallint(5) unsigned NOT NULL,
  `type` varchar(30) NOT NULL,
  PRIMARY KEY  (`type_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;



CREATE TABLE `sizes` (
  `size_id` smallint(5) unsigned NOT NULL auto_increment,
  `supplier_id` smallint(5) unsigned NOT NULL,
  `type_id` smallint(5) unsigned NOT NULL,
  `size` varchar(15) NOT NULL,
  PRIMARY KEY  (`size_id`),
  UNIQUE KEY `size` (`size`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;


CREATE TABLE `suppliers` (
  `supplier_id` smallint(5) unsigned NOT NULL auto_increment,
  `supplier` varchar(30) NOT NULL,
  PRIMARY KEY  (`supplier_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;


CREATE TABLE `title` (
  `title_id` smallint(5) unsigned NOT NULL auto_increment,
  `title` varchar(60) NOT NULL,
  PRIMARY KEY  (`title_id`),
  UNIQUE KEY `title` (`title`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;


Thanks for any continued support.


 From: John Meyer [EMAIL PROTECTED]
 Date: Wed, 23 May 2007 07:28:23 -0600
 To: mysql@lists.mysql.com
 Subject: Re: Database design
 
 Officelink wrote:
 Hi everyone,
 
 I¹m trying to set up a database with information that will be used in a
 garment slideshow in flash.
 
 The information to be included as part of the slideshow would be:
 code, optional title, description, colours, sizes, garment image, fabric
 swatch image
 
 Each clothing item to be included in the slideshow will belong to one of
 eleven or so categories. Each of the categories will belong to one of two
 category types.
 
 I also planned to set up a simple CMS that would allow the information to be
 added, edited and deleted from the database.
 
 With the above goals in mind, I came up with two tables as follows:
 
 GARMENTS TABLE
 garment_id, int(11), not null, auto_increment, primary key
 cat_id, int(10), unsigned, not null, default 0
 garment_code, varchar(30), not null
 garment_title, varchar(40), null
 garment_desc, varchar(255), not null
 garment_image, varchar(50), not null
 garment_colour, varchar(50), not null
 garment_swatch, varchar(50), null
 garment_sizes, varchar(100), not null
  
 CATEGORIES TABLE
 cat_id, int(10), not null, auto_increment, primary key
 cat_name, varchar(40), not null
 cat_type, tinyint(4), not null, default 1
 
 I was worried about repeating data in some of the columns, for example the
 garment_desc column would have information about sleeve length, cuff type,
 fabric, fabric composition etc. and I thought that all these areas could
 possibly be broken up into separate tables, but I wasn¹t sure if it was
 necessary. Also the colour and size columns would have a lot of repetitive
 data.
   
 
 While normalization does have the goal of eliminating repetition, there
 are other reasons.  Most notably, you don't want to introduce errors or
 even differences into your database.
 A person who accidentally types eRd, for instance.  You might, and I
 emphasize the word might, consider breaking color and size into two
 different tables based upon the following:
 1.  The possible set of valid answers.
 2.  Whether that element will be used in any sort of grouping or
 searching level (are you able to search by color, for instance)

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Database design

2007-05-23 Thread Officelink
Hi everyone,

I¹m trying to set up a database with information that will be used in a
garment slideshow in flash.

The information to be included as part of the slideshow would be:
code, optional title, description, colours, sizes, garment image, fabric
swatch image

Each clothing item to be included in the slideshow will belong to one of
eleven or so categories. Each of the categories will belong to one of two
category types.

I also planned to set up a simple CMS that would allow the information to be
added, edited and deleted from the database.

With the above goals in mind, I came up with two tables as follows:

GARMENTS TABLE
garment_id, int(11), not null, auto_increment, primary key
cat_id, int(10), unsigned, not null, default 0
garment_code, varchar(30), not null
garment_title, varchar(40), null
garment_desc, varchar(255), not null
garment_image, varchar(50), not null
garment_colour, varchar(50), not null
garment_swatch, varchar(50), null
garment_sizes, varchar(100), not null
 
CATEGORIES TABLE
cat_id, int(10), not null, auto_increment, primary key
cat_name, varchar(40), not null
cat_type, tinyint(4), not null, default 1

I was worried about repeating data in some of the columns, for example the
garment_desc column would have information about sleeve length, cuff type,
fabric, fabric composition etc. and I thought that all these areas could
possibly be broken up into separate tables, but I wasn¹t sure if it was
necessary. Also the colour and size columns would have a lot of repetitive
data.

Someone indicated that normalization is not about eliminating repetition,
it¹s about ensuring that the non-key attributes are functionally dependent
on the entire primary key, but then I read somewhere that you¹re supposed to
break down the information as far as possible to avoid redundancy so I¹m a
bit confused. Or does it depend on the situation and what¹s required of the
database. I mean say the CMS needed to have more functionality than what I
indicated above ­ I mean say the client wanted to be able to generate
reports based on style information such as fabric composition or sleeve
style etc. - would this change the setup?

I wondered if someone could comment on the setup to see if I¹m on the right
track here?

Appreciate any help.