|
|
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
Тут первый раз проектирую хранилище и столкнулся со следующими замечаниями от руководства: 1. убрать уникальные индексы. если где либо будет нужна проверка на уникальность, то будет по окончанию загрузки запущена процедура проверки на уникальностью 2. практически нигде не используются (причем это понятно дело весьма хреново бьется с п.1) суррогатные ключи, а используются составные первичные. соответственно в подчиненных таблицах очень часто из родительской приходят по 3-4 столбца. Понятно, что всё очень сильно зависит от задачи и от софта, в котором лабается хранилище, но интересует, использует ли кто такие подходы и оправданны ли они... Каков, так сказать, мировой опыт в этом деле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2010, 13:31 |
|
||
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
Хрустальный шар подсказывает мне что речь идет об суррогатном ключе подчиненной таблицы типа атрибуты объекта. Для таких таблиц первичный ключ можно определить как masterID,detailID и не индексировать detailID. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2010, 18:11 |
|
||
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
Хранилище под OLAP обычно проектируется денормализованным в целях увеличения производительности. Отсюда и ключи суррогатные. Скорее даже речь не о суррогатных ключах, а о схеме "звезда" вместо "снежинки". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2010, 10:16 |
|
||
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
Ну как раз таки в моем случае они очень даже не суррогатные :( + неясен подход с отложенной проверкой уникальности. Как мне кажется лопатить всю базу программным кодом на проверку уникальности это как-то стрёмно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2010, 11:28 |
|
||
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
может отложенная проверка уникальности требуется из-за необходимости быстрой заливки большого объёма данных? Шайтан ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2010, 13:37 |
|
||
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
Ну в каждой партии заливка по 120000 записей. Пришел к выводу что это надо для того, что там так устроенно, что у некоторых субъектов, которым присвоены коды они должны быть уникальны, а у некоторых нет. Типа как ИНН у банков и их филиалов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2010, 15:23 |
|
||
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
каждая табличка дименшн (измерения) должна иметь свой {чаще всего суррогатный} ключ. Когда делается суммирование и мы строим фактический объект - в ключ этого объекта включены все ключи контролируемых измерений. Уникальность значений действительно обычно не поддерживается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2010, 16:49 |
|
||
|
Подходы к проектированию БД хранилища
|
|||
|---|---|---|---|
|
#18+
ShtockНу как раз таки в моем случае они очень даже не суррогатные :( + неясен подход с отложенной проверкой уникальности. Как мне кажется лопатить всю базу программным кодом на проверку уникальности это как-то стрёмно. ошибся конечно: авторОтсюда и ключи НЕ суррогатные многие СУБД позволяют отключать constrains/triggers на время (например, заливки). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2010, 18:42 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36404070&tid=1542901]: |
0ms |
get settings: |
9ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
86ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 251ms |
| total: | 453ms |

| 0 / 0 |
