|
Как кошернее спроектировать структуру?
|
|||
---|---|---|---|
#18+
Задач несколько, но возьму для примера небольшую подзадачу. Нужно раз в сутки проверять размер файлов БД на сервере, например. Запросом можно вывести все файлы за сутки с датами и наименованием БД и другими полями которые выдает нам запрос (пророст файла, ридонли или ридрайт и т.п.), передать все это в DWH и уже хранить в DWH не все подряд, а только изменения. Т.е. запросом получим выборку (БД, Операция [i,u,d], ДатаСнимка, Размер, ИмяФайла, ПриростВКБ, ПриростВПроцентах, РидОлни. ...) смысла хранить одно и тоже нет, в DWH можно хранить тоже самое плюс поле "опареция" со значением 'Insert','Update (change)','Delete/Drop'. При создании новой БД, соответственно нужно сохранить дату снимка со всеми полями, при удалении БД с сервера, нужно добавить информацию, что такая то БД, ДатаСнимка, Операция=D, остальной информации нет, уже не важно какие будут свойства на момент удаления БД. Далее на одной версии сервера select * from databases возвращает один набор полей, на более свежих серверах набор полей может быть увеличен. Хочется в единой структуре хранить и старые и свежие и следующие версии этого запроса. Поэтому решил сделать структуру Entity Attribute Value. Т.е. динамически свернуть структуру в DWN из (БД, Операция [i,u,d], ДатаСнимка, Размер, ИмяФайла, ПриростВКБ, ПриростВПроцентах, РидОлни. ...) в (БД, Операция [i,u,d], ДатаСнимка, НазваниеПоля, ЗначениеПоля). Это можно делать динамическим SQL и даже если добавятся новые поля, они вписываются в эту структуру, единственное все значение полей нужно будет приводить к одному типу binery/varchar/string. Теперь возникает вопрос мы имеем например 50 полей в запросе select * from что_смотрим, многие поля могут быть NULL. С апдейтами вопросов нет одно поле изменилось добавляем в DWH одну строку, но что получается, если БД удалили с сервера, то нужно 50 строк добавлять и указывать что все поля удалены? Или например НазваниеПоля не заполнять заполнить дату и операцию (удаление)? При вставке тоже из запроса получим 50 полей (может из другого подобного запроса) из которых ID (БД) заполнено и пара свойств - нужно вставлять 48 полей NULL? по сути да они добавились и не заполнились. реализация 1 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Вроде все просто и красиво, но блин смущают меня изначально при проектировании костыли. С другой стороны можно все нормализовать нормализованное решение Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.
Здесь при удалениях и добавлениях строк в источник (БД в примере новая), заполняется только необходимое и даже NULL можно не хранить в значениях. Что посоветуете, коллеги? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2018, 09:00 |
|
Как кошернее спроектировать структуру?
|
|||
---|---|---|---|
#18+
Дед-Папыхтет, Прошу прощения, а может быть купить систему мониторинга для своей БД? По идее почти все вендоры предотставляют такие системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2018, 09:24 |
|
Как кошернее спроектировать структуру?
|
|||
---|---|---|---|
#18+
mad_nazgulДед-Папыхтет, Прошу прощения, а может быть купить систему мониторинга для своей БД? По идее почти все вендоры предотставляют такие системы. Может )))). Пользовался несколькими. забикс, леново и sqlcentral мне sqlcentral больше всего понравилась. 1. в любой системе есть полезные фичи есть и не нужные, часто нет реализации того что нужно, один фиг то что нужно придется допиливать... 2. на покупку системы нужны обоснования, пока обоснование - денег нет, есть ДБА и разрабы - пилите. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2018, 09:28 |
|
Как кошернее спроектировать структуру?
|
|||
---|---|---|---|
#18+
В общем при нормализации вылазит 8 сущностей: версии серверов список серверов апгрейды (сслыки на версию и на сервер плюс дата апгрейда, от апгрейда могут меняться структуры системных представлений) сущности - сами запросы/вьюхи/таблицы данные которых нужно сохранять, есть ссылка на сервер типы данных - т.к. все сохраняем в бинари или строку нужно понимать какой тип на выходе поля - со ссылкой на тип и версию сервера операции - (вставка удаление изменение, ссылка на сущность если была операция) детализация - если была операция обновления нескольких полей то в детализацию попадает несколько строк что получается Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
По моему трешак полный... Чота думаю что одну табличку проще и обслуживать и читать из нее, да с костылями и не полностью нормализована... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2018, 11:45 |
|
Как кошернее спроектировать структуру?
|
|||
---|---|---|---|
#18+
реализация сильно зависит от задачи под ту задачу что вы озвучили подойдёт обычное key-value где value это ваша строка "состояния" сущности (xml, json ...) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2018, 11:58 |
|
Как кошернее спроектировать структуру?
|
|||
---|---|---|---|
#18+
авторТеперь возникает вопрос мы имеем например 50 полей в запросе select * from что_смотрим, многие поля могут быть NULL. а вы точно про нормальную форму не забыли? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2018, 13:58 |
|
Как кошернее спроектировать структуру?
|
|||
---|---|---|---|
#18+
Дед-Папыхтет2. на покупку системы нужны обоснования, пока обоснование - денег нет, есть ДБА и разрабы - пилите. Угу... А вы покажите смету на разработку. Может быть смогут задуматься. Если нет... Ну тогда вам все карты в руки. Проект будет долгим и интересным... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.05.2018, 05:54 |
|
|
start [/forum/topic.php?fid=32&tid=1540040]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
172ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 286ms |
0 / 0 |