which is the best database design for mysql - mysql

Question

I am new in database, I am going to share with you 2 database tables design here,I just want to know which one is best design and why?
First one i have create a user table, subject table and user_subject table.
In user table i am saving user information and in subject i have saved subject. IN user_subject I have saved user id and subject id.
CREATE TABLE IF NOT EXISTS `subjects` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
-- --------------------------------------------------------
--
-- Table structure for table `users`
--
CREATE TABLE IF NOT EXISTS `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
-- --------------------------------------------------------
--
-- Table structure for table `user_subjects`
--
CREATE TABLE IF NOT EXISTS `user_subjects` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`subject_id` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
2 one>
CREATE TABLE IF NOT EXISTS `subjects` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
CREATE TABLE IF NOT EXISTS `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`subject_name` varchar(2000) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
I have save user and it's subjects in user table with coma (,) sprat and not create another table to save user and subject id.
I thing 2 one is best because we are not need to save data in thrid table. Please tell me which one is best and long lasting for future.

Answer 1

The first version is much, much better. Here are some reasons why you do not want to use comma delimited strings:
SQL does not have particularly good string functions -- the basics, but not much more.
When you store values in a delimited string, the database cannot validate the data. With a separate table you can use foreign key constraints.
Queries on comma-delimited columns cannot make use of standard indexes (although it might be possible to use full text indexes).
With a comma-delimited string, the database cannot validate that the subjects are unique.
The first method uses a junction table and it is the better way to implement this logic in a relational database.

Answer 2

It's ok to use second way IF:
1) subjects have only one value of importance (name)
2) that value uniquely identifies subjects (i.e. no two subjects have the same name), OR there is no need to make distinction between two subjects with same name
Generally speaking first way is better because if you suddenly decide to give a new value to the subjects (for example age) you don't have to redo your whole table structure.

Answer 3

The second solution is not very good anyway, since you can not use joins or index.
Which solution would be the best, depends on the kind of relationship between users and subjects.
If each subject belongs to exactly one user and each user may have an arbitrary number of subjects, which means you have a one-to-many relationship, than you should add user_id to the table subject.
If any subject can belong to more than one user and each user can have many subjects you should use your first solution with a third mapping table (that would be a many-to-many-relationship).
In both cases you can express following queries very easily and cleanly in sql using a simple join:
which subjects belong to a given user
which users have subjects with a name containing a certain expression
which is the user (are the users in second case) of a given subject