I am trying to add a row in existing table I want to make it unique when I am trying to alter in phpmyadmin it says #1062 - Duplicate entry '0' for key 'mobile'
What code will help me suggest
This indicates that you have two entries which both have '0' in the mobile column. You can't force the column to be UNIQUE because there's non-unique data in their now. The solution is to resolve the conflict, but whether that's a good idea and how exactly to do so depends on your database design. The act of doing it is rather simple (just edit that row and assign a new value for 'mobile'), but depending on your design that could damage some data.
So without knowing the details, I can only caution you to not destroy any data or relations.
If you don't have a primary or unique key in that table, phpMyAdmin doesn't show the '"grid edit" feature, so if that's the case you can either write a little SQL to update the row directly, or temporarily add a new column, make it an autoincrementing primary key, do the edit through the phpMyAdmin interface, then remove the temporary autoincrement column (that's what I'd do; I just tested it and it took me about 30 seconds to add the column and key, edit a row, and delete the temporary column).
Related
During the creation of tables using mysql on phpmyadmin, I always find an issue when it comes to primary keys and their auto-increments. When I insert lines into my table. The auto_increment works perfectly adding a value of 1 to each primary key on each new line. But when I delete a line for example a line where the primary key is 'id = 4' and I add a new line to the table. The primary key in the new line gets a value of 'id = 5' instead of 'id = 4'. It acts like the old line was never deleted.
Here is an example of the SQL statement:
CREATE TABLE employe(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(30) NOT NULL
)
ENGINE = INNODB;
How do I find a solution to this problem ?
Thank you.
I'm pretty sure this is by design. If you had IDs up to 6 in your table and you deleted ID 2, would you want the next input to be an ID of 2? That doesn't seem to follow the ACID properties. Also, if there was a dependence on that data, for example, if it was user data, and the ID determined user IDs, it would invalidate pre-existing information, since if user X was deleted and the same ID was assigned to user Y, that could cause integrity issues in dependent systems.
Also, imagine a table with 50 billion rows. Should the table run an O(n) search for the smallest missing ID every time you're trying to insert a new record? I can see that getting out of hand really quickly.
Some links you might like to read:
Principles of Transaction-Oriented Database Recovery (1983)
How can we re-use the deleted id from any MySQL-DB table?
Why do you care?
Primary keys are internal row identifiers that are not supposed to be sexy or good looking. As long as they are able identify each row uniquely, they serve their purpose.
Now, if you care about its value, then you probably want to expose the primary key value somewhere, and that's a big red flag. If you need an external, visible identifier, you can create a secondary column with any formatting sequence and values you want.
As a side note, the term AUTO_INCREMENT is a bit misleading. It doesn't really mean they increase one by one all the time. It just mean it will try to produce sequential numbers, as long as it is possible. In multi-threaded apps that's usually not possible since batches or numbers are reserved per thread so the row insertion sequence may end actually not following the natural numbering. Row deletions have a similar effect, as well as INSERT with roll backs.
Primary keys are meant to be used for joining tables together and
indexing, they are not meant to be used for human usage. Reordering
primary key columns could orphan data and wreck havoc to your queries.
Tips: Add another column to your table and reorder that column to your will if needed (show that column to your user instead of the primary key).
I would like to add an AutoNumber field in an Access table but ID is already type Autonumber and is used for the index in the table. You can't have more than one Autonumber field in a table apparently.
The use case is: Existing database of Clients with existing Client_Number record. I want the ability to enter an 'old' client from this database and set their Client_Number to what it is in the existing database (eg Access Autonumbers it as 405 but I'll overtype that with 3245). But I also want to add NEW clients and have the system assign a number automatically (beginning at 4001) if possible.
Can anyone help me or is it impossible? I have googled for a solution but nothing is forthcoming.
you'll have to remove the auto-increment index from the original column and add it to a new one column (it might require to temporarily remove table/field dependencies, especially when they are cascaded updates/deletes), then you can key in the new values without any risk to loose the index. once the new index has been built up, reset it's auto-increment value to 4000 - and the next new record will get 4001. as long as one keeps the old index, one still can use it to update dependent tables with the new IDs - and then add the dependencies towards the recently introduced column - and remove the old index column.
I can see that there are similar questions and answers on SO regarding this problem.
I need to create a unique constraint on 7 columns together.
alter table ga_data_model add constraint uq_1234596 unique (portal_id,date,dimension,country,os,os_version,theme);
there has been various answers to use prefix keys to solve this issue. However, because of the nature of my data, simply using the first one or two character to create the index is dangerous as this might result in having duplicate results. So such a solution won't work for me:
alter table ga_data_model add constraint uq_1234596 unique (portal_id,date(2),dimension(2),country(1),os(2),os_version(1),theme(2));
I was thinking of creating a new column in my table that contains the calculated hash of these columns and I create my constraint on this one. But this means that every time I want to insert something into db, I need to first do a select for this column, calculated the hash for the new values, compare them and save/or not save. I think this is a bit too expensive, considering that I will be having a lot of write operations.
Has anyone had the same problem and have a better solution as I explained above?
Thanks!
I want to insert something into db, I need to first do a select for this column, calculated the hash for the new values, compare them and save/or not save
No - you save it, and if you get a unique key violation then you already have the data. Also, implement the hash calculation as a table trigger - that way there's no backdoor for amending the data.
How to rearrange primary key column values after deleting some rows from a table in MySQL?
Foe example; a table with 4 row of data with primary key values 1,2,3,4. When delete 2nd and 3rd rows, then the key value of 4th row change to 2.
Please help me to find solution.
Why do this? You don't need to rearrange your key since it's only number, identifier for record. It has no actual meaning - so let DBMS handle that. This is a very common mistake - trying to take DBMS role.
However, I'll answer your question for common case. In MySQL you can rearrange column with:
update t cross join (select #cur:=0) as init set t.col=#cur:=#cur+1
-this, however, can't be used with column under UNIQUE (so primary key as well) restriction since during update you'll possibly get duplicate records. You should drop restriction first before do that (and create it again after update).
One method is THIS ONE.
Other then that, you can simply drop the table which is primary and then again create it. This will do the job
Why do you want to change primary keys for your data? In general this is bad idea to do that, especially when integrity contstraints comes into the game. If you need to do such thing, I would say you have bad DB desing and you should take closer look on that aspect.
I am very new to database concepts and currently learning how to design a database. I have a table with below columns...
this is in mysql:
1. Names - text - unique but might change in future
2. Result - varchar - not unique
3. issues_id - int - not unique
4. comments - text - not unique
5. level - varchar - not unique
6. functionality - varchar - not unique
I cannot choose any of the above columns as primary keys as they might change in future. So i created a Auto-Increment id as names_id. I also have a GUI( a JTable) that shows this table and user updates Result,issues_id and comments based on the Names.Names here is a big text column. I cannot display names_id in the GUI as it does not make any sense in the GUI. Now when the user updates the database after giving inputs for column2,3,4 in the GUI i used the below query to update the database, i couldnt use names_id in where clause as the Jtable's row_id does not match with the names_id because not all the rows are loaded onto JTable.
update <tablename> set Result=<value>,issues_id=<value>,comments=<value>
where Names=<value>;
I could get the database updated but i want to know if its ok to update the database without even using the PK. how efficient is this? what purpose does the surrogate key serve here?
It is perfectly acceptable to update the database using a where condition that doesn't reference the primary key.
You may want to learn about indexes and constraints, though. You query could end up updating more than one row, if multiple rows have the same name. If you want to ensure that they are unique, then you can create a unique constraint on the column.
A primary key always creates an index on that column. This index makes access fast. If there is no index on name, then the update will need to scan the entire table to look at all names. You can make this faster by building an index on the field.