|
|
|
Архивирование vs денорамализация
|
|||
|---|---|---|---|
|
#18+
Уважаемые! Имеется базейка из нескольких таблиц, связанных друг с другом. Например. Таблицы: Complexes // Комплексы CompID int, // Идентификатор комплекса (первичный ключ) WorkingNow int // Работает комплекс (1) или не работает(0) Buildings // Здания: BiuldingID int, // Идентификатор здания (первичный ключ) CompID int // Внешний ключ на таблицу Complexes (к какому комплексу относится здание) CheckPoints // Проходные зданий ChPointID int // Идентификатор проходной (первичный ключ) BuildingID int // Внешний ключ на таблицу Buildings Entrance // Вход через проходную EntranceID int // Идентификатор операции входа (первичный ключ) ChPointID int // Внешний ключ на таблицу CheckPoints Count int // Количество людей вошедших на протяжении операции .....прочие характеристики входа Leaving // Выход через проходную LeavingID int // Идентификатор операции выхода(первичный ключ) ChPointID int // Внешний ключ на таблицу CheckPoints Count int // Количество людей вышедших на протяжении операции .....прочие характеристики выхода (сильно отличаются от характеристик входа) Для получения статистической информации используются весьма сложные запросы, скорость выполнения которых естественно зависит от количества записей в таблицах. С целью повышения производительности решено было не выводить информацию о комплексах, не работающих в данный момент (вероятность того что данный комплекс опять заработает крайне низка, но информацию о нём обязательно хранить нужно). Основные запросы производятся к представлениям (view), построенным на нижних таблицах иерархии, поэтому уже в этих таблицах нужно знать, работает комплекс или нет. В голову приходят две идеи - архивирование информации о неработающих комплексах (продублировать все таблицы с добавлением к имени Archive и добавлять в них записи одновременно с их удалением из основных), либо денормализовать базу по полю WorkingNow (добавить это поле во все таблицы) и обеспечить синхронность изменений. Какой и этих вариантов лучше? Какие выходы из подобных ситуаций можно предложить ещё? Заранее благодарен за помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2006, 14:58 |
|
||
|
Архивирование vs денорамализация
|
|||
|---|---|---|---|
|
#18+
авторДля получения статистической информации используются весьма сложные запросы, разбить на две БД - оперативная БД (в 3NF) - БД для принятия решения и анализа (не в 3NF) PS. OLTP / OLAP ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2006, 15:22 |
|
||
|
Архивирование vs денорамализация
|
|||
|---|---|---|---|
|
#18+
Sir Pri Entrance // Вход через проходную Leaving // Выход через проходную Я бы наверное слил в одну таблицу, а вот характеристики возможно вынес в разные (если уж там на самом деле такие разные) как 1:1 Sir Pri Основные запросы производятся к представлениям (view), построенным на нижних таблицах иерархии Вот тут ИМХО и рождаются тормоза. А вообще подобные вопросы сначала решаются с помощью изучения планов выполнения запросов. Надо выявить причину тормоза. Я не думаю, что у вас в справочной таблице комплексов жуткое количество записей. Наверняка немного. Посему и ограничивать выборки из нее смысла немного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 13:50 |
|
||
|
Архивирование vs денорамализация
|
|||
|---|---|---|---|
|
#18+
имхо, архивирование и денормализация здесь не катят (лишний геморрой) 1) нужно в таблицы Complexes, Entrance и Leaving добавить (если нет) дату и время 2) поля Count - лишние (нужно следить за их актуальностью). Если они обновляются через триггеры, то можно оставить 3) для решения проблем с производительностью нужно копать в сторону правильно составленных запросов во вьюшках Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2006, 17:31 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1545205]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
11ms |
get first new msg: |
6ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
2ms |
| others: | 207ms |
| total: | 362ms |

| 0 / 0 |
