|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
06.06.2019, 08:44
|
|||
|---|---|---|---|
|
|||
вопрос по проектированию БД |
|||
|
#18+
Добрый день! Поделитесь, пож-та, практикой. Планируется некое подобие хранилища данных, в которое будут складываться данные из автоматизированных систем, далее они будут в зависимости от задач преобразовываться. Собственно, вопрос, как хранить такие данные: - делать одну огромную БД и в ней много схем? Видятся возможные проблемы с backup/restore - делать много отдельных БД, например Источник1.Исходные_данные, Источник2.Преобразованные данные? Видятся возможные проблемы с межбазовым взаимодействием. Возможно есть ещё какие то нюансы при выборе одного или другого решения. В общем, кто что посоветует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.06.2019, 08:57
|
|||
|---|---|---|---|
вопрос по проектированию БД |
|||
|
#18+
Michail A.Собственно, вопрос, как хранить такие данные: - делать одну огромную БД и в ней много схем? Видятся возможные проблемы с backup/restore - делать много отдельных БД, например Источник1.Исходные_данные, Источник2.Преобразованные данные? Видятся возможные проблемы с межбазовым взаимодействием.С одной БД работать проще. Если размеры не особо большие, ну, не больше 10 Тб, то лучше одну. Решение ещё зависит от того, насколько данные из этих разных систем "близки". Если это совершенно разные системы (допустим одна система - это 1С база бухгалтеров, другая - база исходников для киномонтажа, третья - оперативная база турникетов на проходной), то разделение на много баз позволяет упростить управление этим бизнесом для компании. Например, управлять разработкой разных подсистем у разных оутсорсеров, управлять финансированием, разделять разработку и модернизацию по времени, ну и так далее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.06.2019, 13:25
|
|||
|---|---|---|---|
|
|||
вопрос по проектированию БД |
|||
|
#18+
Michail A., для трехуровневой архитектуры надо принять решение о размещении второго уровня, слоя бизнес-логики. Если большую часть бизнес-логики Вы планируете разрабатывать на языках, отличных от T-SQL, то можно без затруднений использовать многобазовый вариант, если бизнес-логику планируете писать на T-SQL, то более практичным будет вариант размещения данных в одной базе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.06.2019, 00:45
|
|||
|---|---|---|---|
|
|||
вопрос по проектированию БД |
|||
|
#18+
Michail A., Обратите внимание, что foreign key возможны только внутри одной базы. Я бы смотрел насколько данные различаются по признакам уровня базы данных, типа бэкапа, логирования итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.06.2019, 01:23
|
|||
|---|---|---|---|
вопрос по проектированию БД |
|||
|
#18+
- stage-уровень, куда заливаются сырые данные - расчетный слой, где расположены etl-процедуры, заливающие данные в сущности и суперсущности на основе данных предыдущего слоя(и только, отсюда больше никуда лезть нельзя), и расчетные процедуры - база витрин, в отличии от первых двух может располагаться на другом сервере, туда лезут пользователи со своими adhoc-запросами, туда лезут кубы, туда лезут иные системы (при необходимости таких баз может быть несколько в разных местах) Последнего слоя может и не быть, если юзеры не имеют к ним прямого sql доступа (например, данные поступают только в кубы). Везде применяется единый принцип "тянем", а не "толкаем". То есть последующий слой сам берет данные из предыдущего. Соответственно за процесс отвечают те, кто отвечает за данный слой. Никаких проблем с резервированием и восстановлением нет - достаточно соблюдать порядок. Схемами в stage-области разделяют данные разных баз-источников. Схемами в других слоях разделяют данные разных бизнес-сущностей или специальных отчетов, например rwa или raroc, если брать банковскую область, им ifx, если это данные Интерфакса и т.д. Вообще, если возникают такие вопросы, то вам лучше сразу нанять архитектора. Потом переделывать будет дорого и долго. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.06.2019, 01:26
|
|||
|---|---|---|---|
вопрос по проектированию БД |
|||
|
#18+
PizzaPizzaMichail A., Обратите внимание, что foreign key возможны только внутри одной базы. Я бы смотрел насколько данные различаются по признакам уровня базы данных, типа бэкапа, логирования итп. В ХД fk как правило не применяются, т.к. сначала может приехать факт, а справочная запись через полчасика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.06.2019, 02:10
|
|||
|---|---|---|---|
вопрос по проектированию БД |
|||
|
#18+
alexeyvgMichail A.Собственно, вопрос, как хранить такие данные: - делать одну огромную БД и в ней много схем? Видятся возможные проблемы с backup/restore - делать много отдельных БД, например Источник1.Исходные_данные, Источник2.Преобразованные данные? Видятся возможные проблемы с межбазовым взаимодействием.С одной БД работать проще. Если размеры не особо большие, ну, не больше 10 Тб, то лучше одну. Решение ещё зависит от того, насколько данные из этих разных систем "близки". Если это совершенно разные системы (допустим одна система - это 1С база бухгалтеров, другая - база исходников для киномонтажа, третья - оперативная база турникетов на проходной), то разделение на много баз позволяет упростить управление этим бизнесом для компании. Например, управлять разработкой разных подсистем у разных оутсорсеров, управлять финансированием, разделять разработку и модернизацию по времени, ну и так далее. Всякое бывает. Есть БД первичных данных. Есть процедуры, которые неким образом периодические из них делают некие сводные данные которые хранятся в другой БД. Например - в бухгалтерии сотового оператора совершенно не нужна информация по каждому абоненту. Достаточно сводных оборотов. В БД технологической линии не нужны показания с датчиков на каждую миллисекунду. Достаточно раз в 10 секунд. Но вся детальная информация хранится в соответствующих базах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=46&mobile=1&tid=1687714]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 351ms |
| 0 / 0 |
