|
|
|
Соединение таблицы с последними значениями другой таблицы
|
|||
|---|---|---|---|
|
#18+
Ситуация следующая: Есть две таблицы movements(движения товаров): -------------------------------------------------- | period | shop_id | good_id | quantity | -------------------------------------------------- prices(цены товаров): --------------------------------------------- | period | shop_id | good_id | price | --------------------------------------------- Связь таблиц соответственно по полям shop_id и good_id. Поле period - это дата либо движения, либо установки цены. Необходимо получить запрос дающий следующий результат: | period | shop_id | good_id | quantity | price | где соответственно цена - это цена товара, ближайшая к дате движения. Проблема в том что у меня не получатся получить цену товара на дату движения, во всяком случае чтобы это было быстро. Пробовал сделать так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Как это можно сделать по другому? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 11:01:52 |
|
||
|
Соединение таблицы с последними значениями другой таблицы
|
|||
|---|---|---|---|
|
#18+
ну если заменить LEFT на INNER то будет быстрее, цены-то на все товары по-идее есть? ;) индексы проверить не помешало бы - что EXPLAIN говорит? Ну а так чтоб совсем быстро - кэшировать текущие цены надо ;) -- Dmitry ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 19:48:41 |
|
||
|
Соединение таблицы с последними значениями другой таблицы
|
|||
|---|---|---|---|
|
#18+
Dinkyну если заменить LEFT на INNER то будет быстрее, цены-то на все товары по-идее есть? ;) индексы проверить не помешало бы - что EXPLAIN говорит? Ну а так чтоб совсем быстро - кэшировать текущие цены надо ;) Не все так просто :)) Цены может не быть, хотя это и редкость... Explain: id | select_type |table | type | key | ref 1|PRIMARY |m |ref |docs_id |const 1|PRIMARY |p |ref |good_id |m.good_id 2|DEPENDENT SUBQUE |pr |ref |good_id |p.good_id Вроде как все в порядке... А вот с кешированием - это как? если движение хранятся за большой период и отчет естественно надо тоже за большой период - цены меняются, нужно получать каждый раз ее значение.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 09:31:23 |
|
||
|
Соединение таблицы с последними значениями другой таблицы
|
|||
|---|---|---|---|
|
#18+
в порядке или нет - будет видно на много записей-много запросов ;) ну не кэшировать в данном случае, а скорее слегка денормализовать - почему бы не положить цену прямо в movements? -- Dmitry ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 18:54:12 |
|
||
|
Соединение таблицы с последними значениями другой таблицы
|
|||
|---|---|---|---|
|
#18+
По-моему что-то с реализацией задачи, почему движение отделено от цен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2006, 18:57:43 |
|
||
|
Соединение таблицы с последними значениями другой таблицы
|
|||
|---|---|---|---|
|
#18+
Валентин КПо-моему что-то с реализацией задачи, почему движение отделено от цен? Потому что цены назначаются независимо, от движений. В данном случае пример - списание товара, при списании цена не указывается, т.к. списывается по себестоимости, а нужен отчет в определенном типе цен. Как-то так.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2006, 09:44:25 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=33490333&tid=1853147]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
231ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 526ms |

| 0 / 0 |
