Автор Тема: Очередная нумерация  (Прочитано 7019 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Макс

  • vir magni ingenii
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 3534
  • +0/-0
  • 2
    • Просмотр профиля
Очередная нумерация
« Ответ #15 : 24 Августа 2004, 17:36:12 »
SET @sort := 0;
UPDATE tab SET sort = @sort := @sort + 1 ORDER BY date;
First learn computer science and all the theory. Next develop a programming style. Then forget all that and just hack. ( George Carrette )

Оффлайн APL

  • Фанат форума
  • Старожил
  • ****
  • Сообщений: 344
  • +0/-0
  • 0
    • Просмотр профиля
    • http://www.aerozone.ru
Очередная нумерация
« Ответ #16 : 24 Августа 2004, 17:49:30 »
Чего накинулись на человека? :) Может из спортивного интереса...

Оффлайн CGVictor

  • теперь местный
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2511
  • +0/-0
  • 2
    • Просмотр профиля
    • http://cg.net.ru
Очередная нумерация
« Ответ #17 : 24 Августа 2004, 18:41:31 »
Цитировать
Croaker:
Зачем?

У меня задача - написать интеграцию с very, very hemmoroidal database... Не я это придумывал изначально.
Макс
Спасибо! Попробую!
LJ: Backslashed life (rss)

Оффлайн Croaker

  • Модератор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 927
  • +0/-0
  • 0
    • Просмотр профиля
    • http://alex-files.ru
Очередная нумерация
« Ответ #18 : 24 Августа 2004, 18:54:29 »
CGVictor

Тем не менее. Опиши конкретную задачу, для которой тебе понадобилось так оптимизировать базу.
Не все коту матрица.

Оффлайн Phoinix

  • RW
  • Ветеран
  • *****
  • Сообщений: 1097
  • +0/-0
  • 2
    • Просмотр профиля
    • http://phoinix.ucoz.ru
Очередная нумерация
« Ответ #19 : 24 Августа 2004, 20:45:19 »
Croaker

Цитировать
Опиши конкретную задачу, для которой тебе понадобилось так оптимизировать базу


Позволю себе описать:

Есть таблица где хранится дерево каталогов, в нем сортировка своя, и трогать её не будем, а есть вторая таблица записи которой относатся к разным узлам дерева. Причем к узлу может относится разное количество записей. Как производить их сортировку?

Создаем дополнительно поле sort в котором мы указываем свой(!) порядок для каждого узла:

id | title | category | sort
1 | title1 | 1 | 1
2 | title2 | 1 | 2
3 | title3 | 1 | 3
4 | title4 | 2 | 1
5 | title5 | 2 | 2
6 | title6 | 2 | 3
7 | title7 | 2 | 4
8 | title8 | 3 | 1
9 | title9 | 3 | 2
10 | title10 | 4 | 1
...

Добавляя дополнительные записи в узел, мы просто бепем максимальное значение поля sort для данного узла и устанавливаем на 1 большую

Перемещение порядка скажем на 1 пункт вверх (вниз) происходит учень просто: в одной записе sort уменьшеем на 1 в другой увеличиваем...
Все работает прекрасно до того момента пока мы не начнем удалять записи, тогда у нас между некоторыми записями разница sort будет больше чем еденица, и соответсвенно наш замечательный запрос перемещения записи работать не будет. мало того, испортит весь порядок...
Когда запись удаляется одна, проблем особых нет: просто уменьшаем поле sort последующих записей группы на 1. А если записией удаляется сразу несколько, причем не подряд, а выборочно из определенного узла? Тогда просто проводим подобие индексации поля sort на восстановление порядка.

Вообщем-то вся трабла возникает из-за запроса перемещения +-1 поля sort. Да еще если мы перемещаем запись на несколько пунктов вверх (вниз)...

К id судя по всему, я надеюсь, в данном вопросе это поле не имеет никакого значения...

Оффлайн CGVictor

  • теперь местный
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2511
  • +0/-0
  • 2
    • Просмотр профиля
    • http://cg.net.ru
Очередная нумерация
« Ответ #20 : 25 Августа 2004, 10:47:17 »
Phoinix
Спасибо!
У меня тот же случай, но все это уже реализовано very-very кривыми руками в корпоративной базе. И надо с этим работать.
А в чистом виде задача выглядит именно так, как ты описал.
LJ: Backslashed life (rss)

Гость

  • Гость
Очередная нумерация
« Ответ #21 : 24 Сентября 2004, 02:12:38 »
попробуй новый столбец создать id2, который будет как раз пронумерован.
 И связи никакие не рвутся.

В вообще когда встречаешься с такими задачами не стоит проверять sql на прочность. попробуй сделать по-другому....
всегда есть backdoor.

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28