|
|
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
Никак не могу написать запрос. В таблице истории состояний заказов три поля: id (это id заказа из другой таблицы - таблицы заказов) status - принимает значения 1,2,3.. time - UNIX-метка - время, когда данный заказ изменил своё состояние на status Нужно выбрать id тех заказов, ТЕКУЩЕЕ состояние которых x (только без подзапросов - стоит 4.0.xx). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 15:14:38 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 15:24:42 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
Может просто Код: plaintext Где history_status - таблица истории состояний, и х - одно из нужных значений 1,2 или 3... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 15:28:27 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
Да нет, RFT, такой запрос выдаст все те id, статус которых вообще когда-то был x, а мне нужно что бы x был именно ПОСЛЕДНИМ (текущим) статусом этого id. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 15:33:13 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
А состояние по мере изменения всегда последовательно увеличивается? Если так, то ИМХО несколько неверно реализована база... Надо тогда чтобы записи со статусом не добавлялись, а обновлялись. А то что было на ранних этапах - нетрудно было бы понять: если есть 2, то был и 1, если есть три, то были и 1 и 2. Возможности это поменять уже нет? Если есть, то работка упростится по самый неболуй. Ну это ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 16:54:39 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
RFT, в том то и фишка, что нужно хранить именно ИСТОРИЮ состояний, а не просто текущее состояние. То есть нужно чтобы всегда можно было посмотреть - ага, вот такой-то заказ изменил своё состояние с 1 на 2 тогда-то, с 2 на 3 - тогда то... И вовсе не обязательно состояния будут последовательно увеличиваться. Например, возможна такая история: 1->2->3->2 .... Собственно, выход известен - можно, помимо таблицы истории, хранить текущее состояние в таблице самих заказов. Но это есть дублирование информации: чую, что некое изящное решение всё же есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 17:04:04 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
Тогда наверное временные таблицы использовать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 17:17:17 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
Изящное решение всегда есть, но оно, как правило, не сопоставимо с быстродействием. Я предложил бы хранить дополнительно текущее состояние в таблице заказов. А при необходимости истории обращаться уже к с другим, более долгим и сложным запросом в базе к таблице с историей изменения статусов... Вариант "изящного решения" обсуждался здесь на форуме, пока я его найти не могу, но поверь при всем своем изяществе он не будет работать шустро! Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2005, 17:20:00 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
обычный select к этой таблице. группируешь по id заказа, по timestamp берешь max(), на status накладываешь условие having. Но выше тебе правильно сказали - неправильно спроектирована база. Я бы добавил в таблицу заказа еще одно поле - обратную ссылку на актуальную строку состояния заказа. Дальнейшее построение запросов очевидно, не так ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2005, 12:36:40 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
ap99apЯ бы добавил в таблицу заказа еще одно поле - обратную ссылку на актуальную строку состояния заказа. Дальнейшее построение запросов очевидно, не так ли?Да, я так сейчас и делаю. И всё же, ap99apобычный select к этой таблице. группируешь по id заказа, по timestamp берешь max(), на status накладываешь условие having.я с этим как раз поначалу и мучался, он мне выдавал по времени MAX, но в таблице результата статус не соответствовал этому времени в исходной таблице истории. Может, напишешь запрос на языке SQL, а не на русском? :-) Очень охота протестировать быстродействие. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2005, 09:35:05 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
Greendrake ap99apобычный select к этой таблице. группируешь по id заказа, по timestamp берешь max(), на status накладываешь условие having.я с этим как раз поначалу и мучался, он мне выдавал по времени MAX, но в таблице результата статус не соответствовал этому времени в исходной таблице истории. Может, напишешь запрос на языке SQL, а не на русском? :-) Очень охота протестировать быстродействие. Спасибо. select id, right(max(concat(t,status)),1) from tbl group by id having status = 2; этот фокус не будет особо быстрым, но что ж ты хочешь в такой ситуации.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2005, 13:05:34 |
|
||
|
Запрос строк с определённым текущим состоянием из таблицы истории состояний
|
|||
|---|---|---|---|
|
#18+
ap99ap select id, right(max(concat(t,status)),1) from tbl group by id having status = 2; ну, в смысле, там надо будет вычисляемое поле назвать как-нибудь типа 's' и в having проверять 's = 2', конечно. Главное, идею ты понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2005, 13:08:08 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=33171643&tid=1853830]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
204ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 241ms |
| total: | 538ms |

| 0 / 0 |
