Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
История данных - нужен совет
|
|||
|---|---|---|---|
|
#18+
Привет всем. Вот, очухались клиенты от новогодних праздников и поставили задачку. Исходные данные: SQL7; база промышленных аггрегатов/их частей/параметров/условий эксплуатации/данных для их расчетов - всего 80 таблиц, в среднем 15000 записей; структура редизайну не подлежит, может только наращиваться (т.е. никаких drop column). Базу редактируют пользователи. 2-я база - копия первой - стоит на сайте в интернете. При наступлении времени "Ч", отмеченные изменения скопом садятся из 1-й во 2-ю базу. Задача: создать во 2-й базе структуру поддержки истории изменений. Т.е. если "Ч"=31.01.2002 происходит репликация, нужно иметь возможность получить снимок до и после 31.01.2002. Вся история должна сохраняться, т.е. нет срока давности (или очень большой). Частота обновлений - несколько раз в месяц, возможно чаще. Основное требование - скорость получения данных критична. Если кто сталкивался с подобными задачами, или имеет идеи эффективного решения, поделитесь плиз. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2002, 09:37 |
|
||
|
История данных - нужен совет
|
|||
|---|---|---|---|
|
#18+
Я делаю так: Не удаляю данные из таблицы а добавляю 2 служебных поля 1 дата открытия, 2 дата закрытия. если стоит дата закрытия то запись "удалена" чтобы обработать данные за какой то период - просто выбираешь по этим полям записи и работаешь с ними... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2002, 16:32 |
|
||
|
История данных - нужен совет
|
|||
|---|---|---|---|
|
#18+
Собственно с датой закрытия и открытия это правильно. В принципе, так как база у тебя не большая, то можно попробовать завести одну таблицу типа SystemRoot ------------- ID parentID - может пригодится dateOpen dateClose и отнаследовать все таблицы от этой. есть правла и недостатки такого решения. 1. Замедление работы на вставке. нужно вставить запись в SystemRoot а потом в дочернюю. 2. ну и подвязка дополнительной таблицы при выборке. но есть и плюсы как по мне очень привлекательны я как то делал такой тест. Root и 200 дочерних таблиц в каждую положили 5000 записей в руте получилось 1 млн запрос по срезу (период) отрабатывал без задержек. Но лучше конечно проверять на реальных данных в ообщем смотрите... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2002, 20:51 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32021974&tid=1824007]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
84ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 445ms |

| 0 / 0 |
