|
|
|
обновление предыдущего значения
|
|||
|---|---|---|---|
|
#18+
Добрый день! [заранее простите за возможную лажовость вопроса, но оч нужно, и поискав по форуму решения не увидел, (хотя может смотрел криво %))] Внимание вопрос: Допустим, есть таблица вида ID, KPI, Period, Value, ValidAfter, ValidBefore например: 1, Выручка, Август2008, 100, 10SEP2008, 31DEC2999 нужно добавить обновленные данные по Выручке чтобы получилось так: 1, Выручка, Август2008, 100, 10SEP2008, 15SEP2008 2, Выручка, Август2008, 101, 15SEP2008, 31DEC2999 как правильно обновить предыдущую запись при добавлении новой записи, и как будет меньше тормозов при бОльших объемах таблицы и добавляемых данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 18:06 |
|
||
|
обновление предыдущего значения
|
|||
|---|---|---|---|
|
#18+
ну да, и добавлю что сейчас сделано так: 1) обновляется предыдущее ValidBefore: update baseDS as B set ValidBefore = (select ValidAfter from newDS as N where B.KPI=N.KPI and B.Period=N.Period) where B.ValidBefore = "31DEC2999" and exists (select * from newDS as N where B.KPI=N.KPI and B.Period=N.Period); 2) содержимое newDS добавляется к baseDS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 18:28 |
|
||
|
обновление предыдущего значения
|
|||
|---|---|---|---|
|
#18+
imoenДопустим, есть таблица вида ID, KPI, Period, Value, ValidAfter, ValidBefore например: 1, Выручка, Август2008, 100, 10SEP2008, 31DEC2999 нужно добавить обновленные данные по Выручке чтобы получилось так: 1, Выручка, Август2008, 100, 10SEP2008, 15SEP2008 2, Выручка, Август2008, 101, 15SEP2008, 31DEC2999 как правильно обновить предыдущую запись при добавлении новой записи, и как будет меньше тормозов при бОльших объемах таблицы и добавляемых данных imoenну да, и добавлю что сейчас сделано так:1) обновляется предыдущее ValidBefore: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Есть пару комментариев: 1. При организации хранения периодических величин необходимо, чтобы точка (дата+время) начала нового значения была больше точки окончания старого значения. В приведенном примере это нарушается. Пример проблемы : выполним запрос для поиска значения на точку (дата+время) Код: plaintext 2. Непонятно зачем организована таблица newDS? В ней нет никакой потребности - используйте параметризованные SQL DML операторы. В рамках одной транзакции вначале делаете обновление baseDS, а потом делаете туда вставку: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 18:58 |
|
||
|
обновление предыдущего значения
|
|||
|---|---|---|---|
|
#18+
imoen Допустим, есть таблица вида ID, KPI, Period, Value, ValidAfter, ValidBefore например: 1, Выручка, Август2008, 100, 10SEP2008, 31DEC2999 нужно добавить обновленные данные по Выручке чтобы получилось так: 1, Выручка, Август2008, 100, 10SEP2008, 15SEP2008 2, Выручка, Август2008, 101, 15SEP2008, 31DEC2999 как правильно обновить предыдущую запись при добавлении новой записи, и как будет меньше тормозов при бОльших объемах таблицы и добавляемых данных Кстати, есть еще одно архитектурное решение, в котором исключим VALIDBEFORE: T (ID, AXIS, ..., VALUE, DT) Тогда датой окончания действия значения будет дата начала действия следующего значения: 1, Выручка, Август2008, 100, 10SEP2008 2, Выручка, Август2008, 101, 15SEP2008 Выборка: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 20:03 |
|
||
|
обновление предыдущего значения
|
|||
|---|---|---|---|
|
#18+
&VALUE _VVP_ 1. При организации хранения периодических величин необходимо, чтобы точка (дата+время) начала нового значения была больше точки окончания старого значения. В приведенном примере это нарушается. Пример проблемы : выполним запрос для поиска значения на точку (дата+время) Код: plaintext 2. Непонятно зачем организована таблица newDS? В ней нет никакой потребности - используйте параметризованные SQL DML операторы. В рамках одной транзакции вначале делаете обновление baseDS, а потом делаете туда вставку: Код: plaintext 1. 1. По поводу точки начала нового значения, данные добавляются последовательно, то есть, новая запись будет по любому иметь более поздний ValidAfter, ну если конечно на сервере время назад не откатят ) Для отбора какого-то предыдущего значения можно же брать [ValidAfter, ValidBefore), но на самом деле в этом фактически надобности нет, нужно будет отбирать лишь актуальное, то есть у которого ValidBefore = "31DEC2999" 2. По поводу newDS. Вообще это Код: plaintext 1. 2. 3. 4. 5. 6. 7. Обновление ValidBefore реализовано sql запросом, а добавление новых записей делается SAS-ом Второй вариант с исключением ValidBefore был изначально, но сортировка больших таблиц по 2 гига и более при получения актульного значения для публикации занимала тоже очень немало времени. Отбирать данные с ValidBefore ="31DEC2999" существенно быстрее. А если учесть что публикация данных из промежуточного хранилища должна быть ежедневной, а добавление больших объемов происходит гораздо реже, то потому было решено иметь два поля ValidAfter и ValidBefore Вопрос возник потому, что при объемах newDS порядка 50000 записей и поболее, и baseDS в пару миллионов записей, обновление поля ValidBefore длится, ну эээээ, ну очень долго. Когда добавляются до 1000 записей, еще терпимо, и на время всей выгрузки не сильно влияет. Но бывает необходимость добавить большой объем данных. Есть ли какой метод который позволит сделать обновление ValidBefore не таким долгим. Или что другое можете посоветовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 11:55 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=98&tid=1543661]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
51ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
87ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 373ms |

| 0 / 0 |
