|
|
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
Не силен в SQL. Помогите пож. решить задачку, если есть у кого время. Есть две таблички: 1. rTrans - таблица движений: r1: Integer; - код товара s: Decimal - кво товара tp: char(1); - '+' - приход, '-' - расход d: Date - дата движения 2. rTotal - таблица итогов: r1: Integer; s: Decimal d: Date - дата итогов, всегда первое число месяца, для которого эти итоги являются начальными Первая таблица хранит движения (приходы/расходы) товара за месяц. Вторая - остатки товара на складе на конец месяца. Задача: получить отчет об остатках на складе в произвольный день месяца. Проблемы: - на конец месяца товара может не быть, а на произвольный день - есть. - обортов по товару может и не быть, но нач. и кон. остатки есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 12:24 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
Вероятно лучше написать ХП. DateItog - дата, на которую получаем итоги по идее еще должен быть справочник товаров Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Не претендую на хорошую скорость, потому как можно сильно поправить процедуру в сторону улучшения! ------------------------ С уважением, Denis Uskov ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 13:49 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
К сожалению это не подойдет. Структура таблиц - упрощенная. rTrans и rTotal содержат еще Id склада и Id валюты. Мне виделся такой подход: создать временную таблицу rVew, в которую переместить rTotal. Дальше ХП проходить по rTrans и изменять/добавлять значения в rVew. После этого обычный запрос по rVew вернет нужную информацию. Но создавать / удалять в IB временные таблицы нерекомендуется. Может есть какая-то другая замена? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 14:08 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
Какая была инфа, по той и сделал. Если "Структура таблиц - упрощенная" , а в реале намного сложнее, то как раз ХП будет более легкий и гибкий вариант, чем доп. таблицы и т.д. Просто добавляй в where и group by что тебе нужно. Когда получишь окончательный результат, проанализируй все планы запросов и логику, может другой вариант будет более удачным! ------------------------ С уважением, Denis Uskov ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2004, 08:56 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
А возникнут ли какие-нибудь проблемы, если програмно создавать/удалять View? С помощью View мне видится такое решение задачи (проблему с датой остатка не рассматриваем для простоты): CREATE VIEW v11 (r1,s,tpTable) AS SELECT r1, SUM(s),'l' FROM rTotal GROUP BY r1 UNION SELECT r1, SUM(s*CAST(tp||'1' AS INT)),'r' FROM rTrans GROUP BY r1 WHERE d<EndDate //s*CAST(tp||'1' AS INT) даст сумму приходы минус расходы. //поле tpTable для того, чтобы одинаковые строки при объединении запросов //не игнорировались Запрос по View даст результат: SELECT r1, SUM(s) FROM v11 GROUP BY r1 А после - удалить View. Проблема - обеспечить уникальность имени View. Использовать, например, в имени время создания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2004, 10:44 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Для процедур уникальность проверяется так Viewы.. Используй если хочется, но они вообще никак не работают с параметрами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2004, 13:04 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
>А возникнут ли какие-нибудь проблемы, если програмно создавать/удалять View? Если пару раз, то нет :) но вот лучше этого не делать. Есть такое понятие как счетчик изменений метаданных, так вот когда он достигнет 255, то базе надо будет делать backup/restore иначе к ней не доступишься :( ------------------------ С уважением, Denis Uskov ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2004, 14:05 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
Делал проверку: создавал и удалял View 2 раза по 1000 раз подряд. Каждая 1000 созданий/удалений увеличивала объем базы где-то на 140кб. Никаких жалоб сервер не выдал. Пробовал на Firebird embedded 1.5 RC 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 10:29 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
авторно вот лучше этого не делать. Есть такое понятие как счетчик изменений метаданных, так вот когда он достигнет 255, то базе надо будет делать backup/restore иначе к ней не доступишься :( Тааак)) И для каких версий ИБ это справедливо? Можно ли в ИБЕхперте посмотреть этот счетчик? Мой текущий отчетик каждый раз создает, а в конце работы дропает процедуру, пускался он уже несколько десятков раз - никаких проблем с базой пока нет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 13:26 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
>hyh Было такое ограничение. Только если я правильно помню, 255 изменений какой-либо таблицы, а не на базу в целом. И, если не ошибаюсь, в Интребейзе <=6.х. Т.е. это ограничение зависит от версии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 14:28 |
|
||
|
Помогите составить запрос.
|
|||
|---|---|---|---|
|
#18+
Да уж, что-то я перегнул :) Выдержка из Release Notes для FB (1.0) Alter Trigger no longer increments the change count on table When the count of metadata changes on any single table reaches the maximum of 255, the database becomes unavailable. Backup and restore are required in order to reset the change count and make the database once again available. The intention of this feature is to enforce a database cleanup when table structures have undergone a lot of changes, not to inhibit useful capabilities in the engine. (1.0) это версия сервера! ------------------------ С уважением, Denis Uskov ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 10:11 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32391824&tid=1579307]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
152ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 456ms |

| 0 / 0 |
