|
первичный ключ(Primary Key)
|
|||
---|---|---|---|
#18+
Ennor Tiegael Но, конечно, проектировать БД с расчетом на то, чтобы из нее удобно было DWH делать, и пофиг на все остальное - это я не знаю, кем надо быть. А как насчет "проектировать БД, нисколько не думая о том, чтобы из нее удобно было DWH делать, и пофиг на этот DWH"? Вы же знаете, что руководство, от которого в наибольшей степени зависит ваша зарплата, Для принятия решений пользуется именно сведениями, получаемыми из DWH, а не из оперативных данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2020, 20:32 |
|
первичный ключ(Primary Key)
|
|||
---|---|---|---|
#18+
SQL*Plus, Контора, которая эту систему разрабатывает, сама DWH не пишет. Писать его приходится мне, работая в компании, которая является клиентом сервис-провайдера вендора, с коим у нас договор на услуги тренинга и сертификации сотрудников. Может, конечно, какие-то отчеты они сами и предоставляют, но тот факт, что старая версия DWH живет уже лет 5 минимум, говорит мне о том, что если те отчеты у вендора и есть, то нашим они не подошли. Иначе никто не стал бы заморачиваться с чем, чтобы каждую ночь скачивать у них дамп базы PG, разворачивать его локально, натравлять на него ETL и потом пересчитывать отчетные таблицы. Оверхед, конечно, небольшой - 8 байт на строку таблицы, да и то не для каждой таблицы это является оверхедом. Другое дело, что иногда я наблюдаю изменения этих bigserial-ключей в М:М связках при неизменном натуральном ключе. Т.е. они эту запись удаляют и вставляют заново, зачем - непонятно. Если я буду вязаться к этим Id в моем ETL, получу кучу конфликтов вида "Сара Смит 3 раза прошла курс Hand Hygiene в один и тот же день, с точностью до секунды" (на моей стороне SCD + soft delete). Так что они мне не помогают тут ни разу, только место в базе жрут. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2020, 11:56 |
|
первичный ключ(Primary Key)
|
|||
---|---|---|---|
#18+
Ennor Tiegael Сейчас пилю DWH, где одна из исходных систем (Totara LMS) Респект архитектору этой Тотары ) Одним решением снял кучу вопросов по импорту из нее, а импорт есть в 99% случаев. Ну и заодно тут решается проблема ссылок на эти связочные таблицы, иногда это бывает необходимо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2020, 19:45 |
|
первичный ключ(Primary Key)
|
|||
---|---|---|---|
#18+
fkthat Составные ключи всегдла встречал только либо в таблицах-связках (типа user_roles), либо в подчиненных таблицах (типа order_details) - а на такие таблицы редко кто когда ссылаться будет, мн даже тяжело такой сценарий выдумать. а мне легко: - сначала появляется задача добавить комментарий к связкам - а потом появляется задача связать комментарий еще с чем-то/вывести его где-то ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2020, 19:49 |
|
первичный ключ(Primary Key)
|
|||
---|---|---|---|
#18+
Критик - сначала появляется задача добавить комментарий к связкам Я же уже писал - это тогда уже не связка, а отдельная сущность. Тогда суррогат это именно то, что надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2020, 21:19 |
|
первичный ключ(Primary Key)
|
|||
---|---|---|---|
#18+
fkthat Я же уже писал - это тогда уже не связка, а отдельная сущность Разница больно шаткая Вот например система биллинга Oracle CC&B, вся их V-model, это одна большая мега-связка между Person и зданием ))) Об том то и речь, что сначала была просто связка, потом добавили комментарий, потом еще что-то.... раз и уже получилась "отдельная сущность". Если в таблице был суррогатный ключ - то и ладно, а если не было и уже есть 100500 килобайт кода (да еще и скомпилированного, без исходников), то изменить "архитектуру" уже может быть сильно большая проблема. IMHO ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2020, 16:37 |
|
первичный ключ(Primary Key)
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Об том то и речь, что сначала была просто связка, потом добавили комментарий, потом еще что-то.... раз и уже получилась "отдельная сущность". От всего не застрахуешься. Точно так же может внезапно выясниться, что, допустим, сотрудники иногда меняют адреса, телефоны, фамилии и даже пол, а при этом надо хранить все как новое, так и старое , но не станешь же заводить заранее из-за этого отдельную таблицу вообще под каждый аттрибут. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2020, 16:52 |
|
|
start [/forum/topic.php?fid=32&msg=39982406&tid=1539841]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 167ms |
0 / 0 |