|  | 
| 
первичный ключ(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&gotonew=1&tid=1539841]: | 0ms | 
| get settings: | 7ms | 
| get forum list: | 15ms | 
| check forum access: | 3ms | 
| check topic access: | 3ms | 
| track hit: | 43ms | 
| get topic data: | 11ms | 
| get first new msg: | 8ms | 
| get forum data: | 3ms | 
| get page messages: | 53ms | 
| get tp. blocked users: | 2ms | 
| others: | 13ms | 
| total: | 161ms | 

| 0 / 0 | 
