I need to create a database table in which I have the following three fields mainly:
ID(default auto incrementing).
User_id( starting from 1000 ,auto incrementing)
Email
So, I want to set Email to be unique ,not null( Primary key ),but also I want to make sure that User_id remains unique ( that can be solved by setting unique key ) and I also want it to never be set as null. So, how I can achieve this? I am using MySQL BTW.
PS: I am not much good to this schema building for the current time. So, ignore any silly mistakes.
I would go for something like this
CREATE TABLE USERS
(
ID INT PRIMARY KEY AUTO_INCREMENT,
User_Id INT AUTO_INCREMENT = 1000,
Email VARCHAR(250) NOT NULL
)
And then
ALTER TABLE USERS ADD UNIQUE (Email)
Or if you intend to search on the Email field
CREATE UNIQUE INDEX inx_users_email ON USERS (Email)
You are better of using the Id field as your primary key. The PK is not meant to change and is used to identify the record. What happens if your user changes email address?
Auto_INCREMENT ensures column has unique values and can never be null.
Related
I have a table with the following structure
CREATE TABLE Products (
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(30) NOT NULL,
code VARCHAR(30) NOT NULL UNIQUE,
warranty TINYINT(1) NOT NULL,
producing_country VARCHAR(50),
)
Each product in my table has a unique code and This products is also known in stock as this codes
Codes are something like this: (AR-X22 , RF-3654, ...)
My question is can i remove the ID cloumn in this table? Because it has no special application
And does it hurt if I want to use the code column instead of id in join ?
Its good practice to have a table with an id INT AUTO_INCREMENT and PRIMARY KEY.
It makes sure each row is unique. If other programmers come and look at your table they will expect to see an id column.
Having a VARCHAR as a unique row key is is asking for trouble. There are all sorts of encoding troubles and things that can make strings as identifiers unreliable.
For example: "ABX-112" and "ABX -112" (space hidden in there)
If you just don't want to see ID column do like ravioli states below and just make a new view and not show it.
Good luck.
Your id column is specified as your PK, which means it's used to uniquely identify that row in your table. It looks like it's an identity-type field, which should take care of the uniqueness requirement.
If you want to use code as your new "id" field, that should be fine as long as you make sure it's a unique value when you add rows. It shouldn't have any effect on joins as long as you update your other tables to use the new code field.
I don't know how easy it is to fiddle with PK's on a table that already has data. Your best bet is to create a new table without the id field and populate it using the data in your current table.
If it's just a matter of not wanting to see / deal with an id field you never use, you can always create a view and exclude that field from being returned.
As per my understanding, You want to remove Id from the table and want to use Product code at that place.
A table relationship is based on the primary and foreign key constraints and it is not necessary that every time you have to Id column as primary key.
If you have product code and which will always be unique and not null
then you can use Code as the primary key for the table rather then
unnecessary Id column.
It will also work if you do not create a column wither primary.
Thanks.
Is it possible to create auto-increment based on a specific field? For example i have UserId and Status fields, so for each row with same UserId i need to auto-increment its Status, not global.
There is three thing that come to mind when I read your question. One was an auto incrementing field which acts as your ID number. Updating a table with data that has no unique ID number. Searching for fields with the same Userid to Status
Mt First example is of a creating a table and your AUTO_INCREMENTing number ID:
CREATE TABLE tableNameHere
(
UniqueID int NOT NULL AUTO_INCREMENT,
FirstName varchar(255) NOT NULL,
StatusOrYourColumn int(100) NOT NULL,
PRIMARY KEY (UniqueUD)
)
More on auto incrementation.
You may have already built your table and now want to 'add' additional and or modify your fields using ALTER:
ALTER TABLE tableNameHere StatusOrYourColumn INT AUTO_INCREMENT PRIMARY KEY
But be careful, you don't want to overwrite your settings that you have already set.
Another Thing that came to my mind when reading was where you said Status and Userid where the same. You can find these using the WHERE clause like so:
SELECT * FROM tableName WHERE tableName.Userid = anotherTableOrTableName.Status
Using these queries you can update, remake, alter and query your database table.
Let's say I have a table with the following fields:
primaryEmail | secondaryEmail
I know how to create a UNIQUE constraint on one of the fields, and I know how to create a UNIQUE constraint that combines both fields, but is there a way to ensure that no value exists twice, ACROSS both columns? For example, if there's a value of joe#example.com in the primaryEmail field, I don't want it to be able to appear again in either the primaryEmail field OR the secondaryEmail field.
You might consider revising your data model and pulling the email address to another table and then relating the new and old tables together. Off the top of my head, something like this should work
create table master (
id int not null primary key,
name varchar(64)
);
create table email (
id int not null primary key,
address varchar(128) not null unique,
parent_id int not null,
type enum('prim', 'secd'),
foreign key (parent_id) references master(id)
on delete cascade,
unique (parent_id, type)
);
I don't love this design - I'm not a fan of the enum, for example - but it would solve your uniqueness constraint.
In my opinion, you would want to put two separate constraints on that field if that is really what you are trying to accomplish. What you are actually trying to do are two different things (make sure that column is unique within the record, and make sure that column within that row is also unique for the whole table).
I was told by a friend:
What unique key do you use? I hope you
are not saving the entire user name
--- this will use up too much table space! Assign an unique userID to each
(unique) userNAME and save this userID
(should be INTEGER UNSIGNED
auto_increment or BIGINT UNSIGNED
auto_increment). Don't forget to
create a reference
FOREIGN KEY (userID) REFERENCES
usertable (userID) in all tables
using the userID.
Is the above statement correct? Why or why not?
I think he is right ( for the wrong reason) because primary key cannot change, but username can change. So you should use userid because it wouldn't change.
He is right for the wrong reasons. The table space is secondary to the fact that your app might later mandate that usernames can be changed or even stop being unique (you could envision an application where unique usernames are not required, like Stack Overflow) and thus your app would need major refactoring and data migration instead of a light change in the other (integer PK) case.
I am using MySQL for my database. I have a requirement to store a list of users in the system. The user will have both first name and last name.
I cannot have the first name and second name as the primary key. So I need a indexing key. But I do not want to enter the index value every time to add a new row.
I want the system to handle this with auto increment of previous value every time I try to add a new user. Please let me know how to do this.
Also I am supposed to do a search operation on the list of user with the first name. Please let me know the efficient way to do the search as the number of records could be more than a million.
create table users (
id int primary key auto_increment,
name varchar(64),
...
)
See here for more info
Add an INT() id column with auto_increment set. This way, the id column value will be incremented automatically on each INSERT.
To get a unique key without having to specify it, you need an auto_increment field:
create table people (
person_id int primary key auto_increment,
first_name varchar(50),
: : :
);
For efficiently searching first names, you just need an index on the first-name column. A couple of million rows is not a big table, so this should be reasonably efficient.
create index person_index using btree on people (first_name);