In almost each code example by creating mysql joinUs table, there is the code like this:
CREATE TABLE `members` (
`id` int(10) unsigned NOT NULL auto_increment,
`username` text, //unique
`email` text, //unique
`pass` text,
PRIMARY KEY (`id`)
So, if username and/or email is set as unique, what is then the purpose of id field?
Can I simply set username as primary key and exclude the id from the table?
Id is a nice convention because it will never change. That lets other tables reference users via their id, and enables you to let users change their usernames and emails. Having said that, yes, you could use username as a primary key.
Related
CREATE TABLE `table1` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`email` varchar(128) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `email` (`email`)
)
-
CREATE TABLE `table2` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY,
`email` varchar(128) DEFAULT NULL UNIQUE,
)
Questions:
When created, is there any difference between table1 and table2?
(I assume no, but better to ask than live in blissful ignorance;)
if (yes) what is it?; if (no) why do we have different syntax?
in larger tables show create table tbl_name displays UNIQUE KEY email_2 (email) or some other _num. Why? What does tlb_name_num mean and what is it used for?
What syntax is preferable and why?
show create table tbnm always displays sql in table1 form, even if table is created by table2 sql syntax. Why?
UNIQUE KEY (email) also works. but it's transformed to UNIQUE KEY email (email) on show create table. Why does it work, why is it transformed, etc?
There will be no difference between the two tables.
there are different syntaxes to declare everything first and then add primary key, unique ... Or if some people like to do it immeadiately they also have the possibility
No idea, edit this if found
they both do the same thing, use what you prefer.
No idea, edit this if found
No idea, edit this if found
I am having a very strange problem.
This is what i have, in my structure the "email" field is clearly set to unique. However when i try to register with a duplicate email, instead of giving me a fat error it lets it slide. My database is having two rows with the same email..
The problem isnt just for email, even though i have them all set to unique it allows any and every field to have duplicates..
Any suggestions as to why this may happen? The field is not set to allow null.
MYSQLi/PHP allowing duplicate entry on UNIQUE?
Nope.
It is some mistake with your code or data.
Your current table structure is
I can't see any unique key defined in the table that's why it is possible to have duplicate email, try this:
CREATE TABLE UserList
(
ID INT AUTO_INCREMENT PRIMARY KEY NOT NULL,
username VARCHAR(50) NOT NULL,
email VARCHAR(50) NOT NULL,
igname VARCHAR(50) NOT NULL,
password VARCHAR(100) NOT NULL,
verified VARCHAR(5) NOT NULL,
CONSTRAINT email_uq UNIQUE (email)
);
I want to creating a website where users can sign up in website and upload 20 images to their account. (planning to allow users to upload unlimited images in future)
I have two tables in database.
One for keeping user data
Table name - members
Fields- userid, username, password, email.
Other for saving image path
Table name- images
Fields - userid, imagepath
So I can display images of a user in his page searching image path from table 'images'
Things are working fine. But if the number of users grow this will become slower.
For example - If there is 50000 users I should check all the rows to find images uploaded by a single user
ie;
50000 userid * 20 images/user = 1000000 scans for table rows
This will make the system slow and make overload.
What I should do to avoid this?
create a Schema like this,
CREATE TABLE dataTable
(
`userid` INT NOT NULL,
`username` VARCHAR(50) NOT NULL,
`password` VARCHAR(50) NOT NULL,
`email` VARCHAR(50) NOT NULL
CONSTRAINT tb_pk PRIMARY (`userID`),
CONSTRAINT tb1_uq UNIQUE (`username`)
);
CREATE TABLE pathTable
(
`userid` INT NOT NULL,
`imagepath` VARCHAR(50) NOT NULL,
CONSTRAINT tb_fk FOREIGN KEY (`userID`) REFERENCES dataTable(`userid`)
);
specify that userid of pathTable as a foreign key that references to the certain table's (dataTable) primary key and the server automatically indexed it which will make it faster searching.
Create index on userid field in second table.
Syntax:
http://dev.mysql.com/doc/refman/5.0/en/create-index.html
What are the biggest benefits of using INDEXES in mysql?
I am not sure how to phrase the question so I'll illustrate the tables and the explain what I want to achieve.
-- static table of the entity classes supported by the application
create table entity_type (
id integer not null auto_increment,
name varchar(30) not null,
primary key(id)
);
-- static table of statuses supported by the application
create table entity_status (
id integer not null auto_increment,
name varchar(30) not null,
primary key(id)
);
-- table of valid combinations
create table entity_type_entity_status_link (
entity_type_id integer not null,
entity_status_id integer not null,
unique key(entity_type_id, entity_status_id),
foreign key(entity_type_id) references entity_type(id),
foreign key(entity_status_id) references entity_status(id),
);
-- The tables where user types and statuses are defined
create table user_type (
id integer not null auto_increment,
name varchar(30) not null,
entity_type_id integer not null,
primary key(id),
foreign key(entity_type_id) references entity_type(id)
);
create table user_status (
id integer not null auto_increment,
name varchar(30) not null,
entity_status_id integer not null,
primary key(id),
foreign key(entity_status_id) references entity_status(id)
);
-- table of valid pairs
create table user_type_user_status_link (
user_type_id integer not null,
user_status_id integer not null,
unique key(user_type_id, user_status_id),
foreign key(user_type_id) references user_type(id),
foreign key(user_status_id) references user_status(id),
);
The basic premise behind these tables is that the system supports core types and statuses and the user is able to create their own user types and statues that derive from these.
The question I have is that I cannot see a way of creating any database constraints on the user_type_user_status_link table to ensure that the you cannot insert a file_type - file_status pair where the parent entity_type - entity_status is itself not valid. Or is this something that would have to be done with triggers.
The basic premise behind these tables is that the system supports core
types and statuses and the user is able to create their own user types
and statues that derive from these.
Although that sounds like a laudable goal on the surface, the effect is to delegate database design to your users. Database design, because the effect of your desire to set foreign key references to a subset of the rows in entity_type_entity_status_link means each of those subsets is a defacto, unnamed table.
This approach never ends well.
What you've developed is the "One True Lookup Table". Google that for a host of reasons why OTLT is an anti-pattern.
The best solution is to model real things in your tables. (Entity isn't a real thing. It's an abstraction of a real thing.) Something along the lines of either
create table file_status (
file_status varchar(30) primary key
);
or
create table file_status (
file_status_id integer primary key,
file_status varchar(30) not null unique
);
would work well for file statuses.
In the case of the second one, you can set a foreign key reference to either the id number (saves space, requires an additional join) or to the status text (takes more space, eliminates a join). Note that you need the unique constraint on the status text; your original design allows the user to enter the same text multiple times. (You could end up with 30 rows where entity_type.name is 'File'.
You should use triggers for that.
MySQL does not support constraints of the form that will prevent what you want.
At the moment I'm developing a web application. For that, I need to create a database for user authentication.
I have something like the following in mind:
create table users
(
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
username VARCHAR(100) NOT NULL,
password VARCHAR(60) NOT NULL,
PRIMARY_KEY(id),
UNIQUE(username)
);
create table roles
(
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
role VARCHAR(100) NOT NULL,
PRIMARY_KEY(id),
UNIQUE(role)
);
create table user_roles
(
user_id SMALLINT UNSIGNED NOT NULL,
role_id SMALLINT UNSIGNED NOT NULL,
PRIMARY_KEY(user_id)
UNIQUE (user_id, role_id),
);
Passwords are fixed size but I use varchar because I've read somewhere that in a table where you have both char and varchar columns, the char columns get converted to varchar.
Also, would it be beneficial to use FOREIGN KEY CONSTRAINTS?
Don't use SMALLINTs for IDs. Seriously. Why would anybody do that!? Use a larger integer type.
The primary key on user_roles isn't going to work. Make (user_id, role_id) the primary key and put separate (non-unique) indexes on the fields you will be querying on.
You could add foreign keys that link user_roles to the other tables. If you use ON DELETE CASCADE, it'll even delete the stale links if you ever delete a user or a role.