views:

1358

answers:

8

I have a table with say 20 rows each with a number for display order (1-20).

SELECT * FROM `mytable` ORDER BY `display_order` DESC;

From an admin area you can drag the rows around or type a new number manually for each row.

Surely it's not good to loop over an UPDATE query for every row, what's an alternative in one or very few queries suitable for updating one cell in 20 rows or even more, 50-200+?


Edit: A lot of good responses and ideas. I might expand on the ideas I've considered so far:

One array string: I could have the order in a string listing the unique row IDs in the order I want - eg rows 1,9,2,6,23. When the order is updated, a hidden field updates with JavaScript and adds that to the database or a text file when complete:

UPDATE `my_dispaly_order_table` SET `display_order`='1,9,2,6,23';

Update each row individually: This is what I was trying to avoid but it would only be changed very infrequently so 20-30 calls in one hit once a week or month might not be a problem so simply calling UPDATE on each row is what I usually do:

UPDATE `mytable` SET `display_order`='1' WHERE `rowId` = 1;
UPDATE `mytable` SET `display_order`='2' WHERE `rowId` = 9;
UPDATE `mytable` SET `display_order`='3' WHERE `rowId` = 2;
UPDATE `mytable` SET `display_order`='4' WHERE `rowId` = 6;
UPDATE `mytable` SET `display_order`='5' WHERE `rowId` = 23;
A: 

You could create a temporary table and populate with the primary key of the rows you want to change, and the new values of display_order for those rows, then use the multi-table version of UPDATE to update the table in one go. I wouldn't assume that this is faster, however, not without testing both approaches.

Matt Kane
A: 

Add an id (or other key) to the table, and update where id (or key) = id (or key) of changed row.

Of course, you'll have to make sure that either there are no duplicate display_order values, or that you're OK with ties in display_order displaying in any order, or you'll introduce a second, tie-breaker to the order by list.

tpdi
+1  A: 

You could try to wrap it into a few statements, I don't think it's possible in a single one. So for example, let's say you are going to update the 10th row. You want every record after 10 to be bumped up.

UPDATE table SET col=col+1 WHERE col > 10
UPDATE table SET col=10 WHERE id = X
...

But it's really tough to roll in all logic required. Because some records maybe need a decrement, etc.. You want to avoid duplicates, etc..

Think about this in terms of developer time vs. gain.

Because even if someone sorts this once per day, the overhead is minimal, compared to fixing it in a stored procedure, or pseudo-optimizing this feature so you don't run 20 queries. If this doesn't run 100 times a day, 20 queries are perfectly fine.

Till
A: 

You could delete an re-insert all the rows - that would do the whole operation in just two queries (or three if you need to select all the data). I wouldn't count on it being faster, and you'd have to do it inside a transaction or you'll be heading for your backups before too long. It could also lead to table fragmentation.

A better option might be to record each change as a history then do something like this:

Example, position 10 is moved down two to 12th

UPDATE table SET display_order = display_order -1 WHERE display_order BETWEEN 10 AND 12
UPDATE table SET display_order = 12 WHERE row_id = [id of what was row 10]
Greg
+3  A: 

You should first ensure that the column has no UNIQUE index, otherwise mysql will tell you that the constraint is broken during the query. After that you can do things like:

-- Move #10 down (i.e. swap #10 and #11)
UPDATE mytable SET display_order =
  CASE display_order
    WHEN 10 THEN 11
    WHEN 11 THEN 10
  END CASE
WHERE display_order BETWEEN 10 AND 11;

-- Move #4 to #10
UPDATE mytable SET display_order
  CASE display_order
    WHEN 4 THEN 10
    ELSE display_order - 1
  END CASE
WHERE display_order BETWEEN 4 AND 10;

But you should actually ensure that you do things in single steps. swapping in two steps will result in broken numbering if not using ids. i.e.:

-- Swap in two steps will not work as demostrated here:

UPDATE mytable SET display_order = 10 WHERE display_order = 11;
-- Now you have two entries with display_order = 10

UPDATE mytable SET display_order = 11 WHERE display_order = 10;
-- Now you have two entries with display_order = 11 (both have been changed)

And here is a reference to the CASE statement of mysql.

soulmerge
A: 

Collect the new order in a temporary variable and put a "save this order" button to the admin area. Then save the order for the rows with one round.

You'll get better response times, undoable changes, fewer modified rows (because in low level in the dbms, practically no updates used to be possible, but save a new instance of the whole row and delete the old one).

After all, it would be a lower cost solution for a whole reordering and would save some coding on the update optimization.

Csaba Kétszeri
+1  A: 

I'm thinking about this problem, and the solution I came up is having a decimal number as order and change the number of the item change for a number between the next and the previous item

Order    Item
-----    ----
1        Original Item 1
2        Original Item 2
3        Original Item 3
4        Original Item 4
5        Original Item 5

If you change the item 4 to the 2nd position, you get:

Order    Item
-----    ----
1        Original Item 1
1.5      Original Item 4
2        Original Item 2
3        Original Item 3
5        Original Item 5

If you change the item 3 to the 3rd position, you get:

Order    Item
-----    ----
1        Original Item 1
1.5      Original Item 4
1.75     Original Item 3
2        Original Item 2
5        Original Item 5

Theoretically there is always a decimal between two decimals, but you could face some storage limits.

This way you only have to update the row being re-ordered.

Eduardo Molteni
I guess two issues with this is you still may need to update a few fields but at least not all... it might get a little hairy after time! I had a similar concept but started in units of 100 so it at least had ints instead of decimals but not too different... I'd say you'd still want to update the order every now and then to be normal consistent numbers. Thanks for the contribution.
Peter
It may not work so well for frequent sorting so you keep adding or shifting items to the top (news items for example) so you'd end up with 0.1, 0.0001 - but then I guess it can go into the thousands... although it seems a slightly left-field idea I'm actually leaning towards this solution...
Peter
I agree that it can get a little hairy after time, but I'm not sure if the user will re-order that much (I guess it depends on the site type, etc.) and you can run a "normalize" query every month or so to keep things more clean.
Eduardo Molteni
+1  A: 

If you need to drag you rows, this is a good implementation for a linked list.

Having your rows ordered with a linked list means that you will update at most 3 rows at a time -- even if you move the whole block (as long as it's contiguous).

Create a table of your rows like this:

CREATE TABLE t_list (
        id INT NOT NULL PRIMARY KEY,
        parent INT NOT NULL,
        value VARCHAR(50) NOT NULL,
        /* Don't forget to create an index on PARENT */
        KEY ix_list_parent ON (parent)
)

id   parent  value

1    0       Value1
2    3       Value2
3    4       Value3
4    1       Value4

and use this MySQL query to select the rows in order:

SELECT  @r := (
        SELECT  id
        FROM    t_list
        WHERE   parent = @r
        ) AS id
FROM    (
        SELECT  @r := 0
        ) vars,
        t_list

This will traverse your linked list and return the ordered items:

id   parent  value

1    0       Value1
4    1       Value4
3    4       Value3
2    3       Value2

To move a row, you'll need to update the parent of the row, the parent of its current child, and the parent of the row you're inserting before.

See this series of articles in my blog on how to do it efficiently in MySQL:

There are lots of articles because there are some issues with row locking which should be handled slightly differently for each case.

Quassnoi
This seems very complicated... my main thought is it's adding more work instead of updating the order of one item it updates 3 fields for every order change...
Peter
3 fields instead of 1 isn't a problem in 2009 :) If you will have more than 1,000 rows and frequent updates, the linked list it the best decision, as it's always 3 fields no matter what. Other solutions will require either updating all fields or a binary sort which is likely to run out of values.
Quassnoi