I have a table with some rows, each row has a unique key. When a row is deleted from the table, all rows that are below this row should be 'moved up'. Is there some built in function in MySQL that does this or should I just do it with PHP or perhaps UPDATE table SET id=id-1 WHERE id > deletedid?
Using the last one seems a bit messy.
What would be the best way to do this?
Why do you want to do this? I know it's ugly to have holes in your unique ID sequence, but the downside of invalidating any references to IDs from outside the database is normally very much greater. The normal thing is to just accept the sequence won't be contiguous. If these represent a sequence, consider just sorting by the order rather than expecting the N'th value to have value N (any sort of iteration should provide its own index somewhere for this use).
If the value is one you set yourself, and you definitely want to keep it as having values from 1 to N (N="number of rows"), and you want to keep the sequence of values even if they're not in the order the rows were inserted, then "UPDATE table SET id=id-1 WHERE id > deletedid" is probably the best answer.
If the value is an auto_increment field, and you don't care which numbers go with with rows as long as each row has a number from 1 to N, you can alternatively do ALTER TABLE DROP COLUMN 'columnname' and then ALTER TABLE again to add the column again, and the database will regenerate the ids from 0. (Not necessarily in the same order, though it often is.)
There may be a way to renumber only the rows after that point, but (according to a quick google) it doesn't look like there's anything easier than what you're already planning.
First you have to ensure that the column is not a foreign-key for any other table.
Then you can try this (I am not 100% positive it will work):
DELETE FROM
MyTable
WHERE
id = deletedid;
UPDATE
table
SET
id=id-1
WHERE
id > deletedid
ORDER BY
id
As stated in mysql docs:
If the ORDER BY clause is specified,
the rows are updated in the order that
is specified.
and in this way you ensure uniqueness of the field.
Related
I have a table with around 10k rows which I've imported. The ID is a significant column to my application, and it has to be ordered. Currently, I got something like: 1,2,3,4,5....5789,9275,9276.....
It jumped from 5789 to 9275. Is there any way I can reset the Auto Increment but also make it apply to the table? which means, now it will start giving them IDS all over again from 1 to 10k
Thanks!
ALTER TABLE <tablename> AUTO_INCREMENT=<new_value>;
Of course you need to fix the high IDs and all references to them manually.
However, why do you care? Does it really matter if there's a hole in the IDs? If yes, you might want to use a separate column that's always set to MAX(col) + 1 instead of an AUTO_INCREMENT column.
You can certainly reset the auto_increment value to be whatever you want by simply issuing this query:
ALTER TABLE <tbl> AUTO_INCREMENT = <n>;
where tbl is your table name and n is the value to start it at. However, if you have existing IDs in that table already, I believe it will simply set the next inserted items ID to be max(id) + 1 of the ID column
I've got a mysql table where each row has its own sequence number in a "sequence" column. However, when a row gets deleted, it leaves a gap. So...
1
2
3
4
...becomes...
1
2
4
Is there a neat way to "reset" the sequencing, so it becomes consecutive again in one SQL query?
Incidentally, I'm sure there is a technical term for this process. Anyone?
UPDATED: The "sequence" column is not a primary key. It is only used for determining the order that records are displayed within the app.
If the field is your primary key...
...then, as stated elsewhere on this question, you shouldn't be changing IDs. The IDs are already unique and you neither need nor want to re-use them.
Now, that said...
Otherwise...
It's quite possible that you have a different field (that is, as well as the PK) for some application-defined ordering. As long as this ordering isn't inherent in some other field (e.g. if it's user-defined), then there is nothing wrong with this.
You could recreate the table using a (temporary) auto_increment field and then remove the auto_increment afterwards.
I'd be tempted to UPDATE in ascending order and apply an incrementing variable.
SET #i = 0;
UPDATE `table`
SET `myOrderCol` = #i:=#i+1
ORDER BY `myOrderCol` ASC;
(Query not tested.)
It does seem quite wasteful to do this every time you delete items, but unfortunately with this manual ordering approach there's not a whole lot you can do about that if you want to maintain the integrity of the column.
You could possibly reduce the load, such that after deleting the entry with myOrderCol equal to, say, 5:
SET #i = 5;
UPDATE `table`
SET `myOrderCol` = #i:=#i+1
WHERE `myOrderCol` > 5
ORDER BY `myOrderCol` ASC;
(Query not tested.)
This will "shuffle" all the following values down by one.
I'd say don't bother. Reassigning sequential values is a relatively expensive operation and if the column value is for ordering purpose only there is no good reason to do that. The only concern you might have is if for example your column is UNSIGNED INT and you suspect that in the lifetime of your application you might have more than 4,294,967,296 rows (including deleted rows) and go out of range, even if that is your concern you can do the reassigning as a one time task 10 years later when that happens.
This is a question that often I read here and in other forums. As already written by zerkms this is a false problem. Moreover if your table is related with other ones you'll lose relations.
Just for learning purpose a simple way is to store your data in a temporary table, truncate the original one (this reset auto_increment) and than repopulate it.
Silly example:
create table seq (
id int not null auto_increment primary key,
col char(1)
) engine = myisam;
insert into seq (col) values ('a'),('b'),('c'),('d');
delete from seq where id = 3;
create temporary table tmp select col from seq order by id;
truncate seq;
insert into seq (col) select * from tmp;
but it's totally useless. ;)
If this is your PK then you shouldn't change it. PKs should be (mostly) unchanging columns. If you were to change them then not only would you need to change it in that table but also in any foreign keys where is exists.
If you do need a sequential sequence then ask yourself why. In a table there is no inherent or guaranteed order (even in the PK, although it may turn out that way because of how most RDBMSs store and retrieve the data). That's why we have the ORDER BY clause in SQL. If you want to be able to generate sequential numbers based on something else (time added into the database, etc.) then consider generating that either in your query or with your front end.
Assuming that this is an ID field, you can do this when you insert:
INSERT INTO yourTable (ID)
SELECT MIN(ID)
FROM yourTable
WHERE ID > 1
As others have mentioned I don't recommend doing this. It will hold a table lock while the next ID is evaluated.
I have two tables, each one has a primary ID column as key. I want the two tables to share one increasing key counter.
For example, when the two tables are empty, and counter = 1. When record A is about to be inserted to table 1, its ID will be 1 and the counter will be increased to 2. When record B is about to be inserted to table 2, its ID will be 2 and the counter will be increased to 3. When record C is about to be inserted to table 1 again, its ID will be 3 and so on.
I am using PHP as the outside language. Now I have two options:
Keep the counter in the database as a single-row-single-column table. But every time I add things to table A or B, I need to update this counter table.
I can keep the counter as a global variable in PHP. But then I need to initialize the counter from the maximum key of the two tables at the start of apache, which I have no idea how to do.
Any suggestion for this?
The background is, I want to display a mix of records from the two tables in either ASC or DESC order of the creation time of the records. Furthermore, the records will be displayed in page-style, say, 50 records per page. Records are only added to the database rather than being removed. Following my above implementation, I can just perform a "select ... where key between 1 and 50" from two tables and merge the select datasets together, sort the 50 records according to IDs and display them.
Is there any other idea of implementing this requirement?
Thank you very much
Well, you will gain next to nothing with this setup; if you just keep the datetime of the insert you can easily do
SELECT * FROM
(
SELECT columnA, columnB, inserttime
FROM table1
UNION ALL
SELECT columnA, columnB, inserttime
FROM table2
)
ORDER BY inserttime
LIMIT 1, 50
And it will perform decently.
Alternatively (if chasing last drop of preformance), if you are merging the results it can be an indicator to merge the tables (why have two tables anyway if you are merging the results).
Or do it as SQL subclass (then you can have one table maintain IDs and other common attributes, and the other two reference the common ID sequence as foreign key).
if you need creatin time wont it be easier to add a timestamp field to your db and sort them according to that field?
i believe using ids as a refrence of creation is bad practice.
If you really must do this, there is a way. Create a one-row, one-column table to hold the last-used row number, and set it to zero. On each of your two data tables, create an AFTER INSERT trigger to read that table, increment it, and set the newly-inserted row number to that value. I can't remember the exact syntax because I haven't created a trigger for years; see here http://dev.mysql.com/doc/refman/5.0/en/triggers.html
I have an application which collects data into a mysql table. The table has no unique id column, so I can't reference a specific row by id.
I want to write a dump application which every day dumps the new rows added to the table to upload them elsewhere. I could do it by adding a unique id field and storing the last id dumped, but I don't want to add an id column just for that to the table.
So I thought I store the number of rows in the table at every dump and use that number as an offset next time the table is dumped (select * from table limit verylargenumber offset x). Of course, it works only if there is a guarantee new rows always inserted at the end of the table, so all new rows will be after the offset.
I assume I can rely on that. Am I right?
No this isn't the case. The database will move stuff around to optimize and make queries faster. You would have to add an order by clause to your query to ensure any sort of order. You should definitely consider adding a unique id to your table.
No, you aren't. There is no surety as to the order in which the engine will return the rows. A table without a unique ID is generally not such a godo idea anyways. In this case, you definitely have reason enough to use one.
Similar to a file system, unless the table is optimized or defragmented, deleted data will free up a "slot" where new data will be inserted. It isn't always appended to the end of the table.
So say you have 3 rows: A, B, C
If you delete B, then your table will essentially look like A, [free space], C
So if you insert D into your table, it will now look like: A, D, C
Your best bet is to use a unique auto incrementing key. This will also speed up queries.
I have a MySQL table with an auto incremement id field. When I delete a row and then insert a new row, The id of the row I deleted is skipped and the new gets an id of one greater than the previous row. Is there any way I can prevent this? I would like the new row to just replace the old one. Is there an important reason why this happens that I am missing?
The MySQL auto-increment function NEVER goes backward unless you force it to. And for a good reason. What if there was stray references to the missing records (logs, tables, etc...)?
You can force it by using this command:
ALTER TABLE tbl AUTO_INCREMENT = 1000;
Or, if you need to do it as part of the query:
LOCK TABLES tbl WRITE;
SELECT #id := MAX(id) FROM tbl;
INSERT INTO tbl SET id=#id, ...;
UNLOCK TABLES;
If you are using InnoDB, you could do this in a transaction instead...
Better to leave it be, however.
The definition of an autoincrement field is that every new row inserted is guaranteed to get a unique value. If you want to keep the old value then you must UPDATE the row instead of replacing it. If your design requires that autoincrement column values be contiguous then you will have to manage that yourself.
I'm sorry but I don't know the exact reason.
AFAIK you can't avoid that behavior unless you TRUNCATE the table or explicitly specify the id.