Sql Query join suggestions

I was wondering when having a parent table and a child table with foreign key like:

users
id | username | password |

开发者_如何学Cusers_blog
id | id_user | blog_title

is it ok to use id as auto increment also on join table (users_blog) or will i have problems of query speed?

also i would like to know which fields to add as PRIMARY and which as INDEX in users_blog table?

hope question is clear, sorry for my bad english :P

I don't think you actually need the id column in the users_blog table. I would make the id_user the primary index on that table unless you have another reason for doing so (perhaps the users_blog table actually has more columns and you are just not showing it to us?).

As far as performance, having the id column in the users_blog table shouldn't affect performance by itself but your queries will never use this index since it's very unlikely that you'll ever select data based on that column. Having the id_user column as the primary index will actually be of benefit for you and will speed up your joins and selects.

What's the cardinality between the user and user_blog? If it's 1:1, why do you need an id field in the user_blog table?

is it ok to use id as auto increment also on join table (users_blog) or will i have problems of query speed?

Whether a field is auto-increment or not has no impact on how quickly you can retrieve data that is already in the database.

also i would like to know which fields to add as PRIMARY and which as INDEX in users_blog table?

The purpose of PRIMARY KEY (and other constraints) is to enforce the correctness of data. Indexes are "just" for performance.

So what fields will be in PRIMARY KEY depends on what you wish to express with your data model:

• If a users_blog row is identified with the id alone (i.e. there is a "non-identifying" relationship between these two tables), put id alone in the PRIMARY KEY.
• If it is identified by a combination of id_user and id (aka. "identifying" relationship) then you'll have these two fields together in your PK.

As of indexes, that depends on how you are going to access your data. For example, if you do many JOINs you may consider an index on id_user.

A good tutorial on index performance can be found at:

http://use-the-index-luke.com

I don't see any problem with having an auto increment id column on users_blog.

The primary key can be id_user, id. As for indexing, this heavily depends on your usage.

I doubt you will be having any database related performance issue with a blog engine though, so indexing or not doesn't make much of a difference.

You dont have to use id column in users_blog table you can join the id_user with users table. also auto increment is not a problem to performance

• It is a good idea to have an identifier column that is auto increment - this guarantees a way of uniquely identifying the row (in case all other columns are the same for two rows)
• id is a good name for all table keys and it's the standard
• <table>_id is the standard name for foreign keys - in your case use user_id (not id_user as you have)
• mysql automatically creates indexes for columns defined as primary or foreign keys - there is no need to do anything here
• IMHO, table names should be singular - ie user not users

You SQL should look something like:

create table user (
    id int not null auto_increment primary key,
    ...
);

create table user_blog (
    id int not null auto_increment primary key,
    id_user int not null references user,
    ...
);