powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как кошернее спроектировать структуру?
7 сообщений из 7, страница 1 из 1
Как кошернее спроектировать структуру?
    #39649146
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Задач несколько, но возьму для примера небольшую подзадачу. Нужно раз в сутки проверять размер файлов БД на сервере, например. Запросом можно вывести все файлы за сутки с датами и наименованием БД и другими полями которые выдает нам запрос (пророст файла, ридонли или ридрайт и т.п.), передать все это в 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.
/*
------ конечная структура - ДЕнормализованная
При вставке все поля которые есть в таблице #source сохраняются в #destination не важно NULL или NOT NULL
При удалении все прекрасно - добавляются только измененные поля
При удалении... добавляются все поля с oper$='D' т.е. в нашем случае 3 строки
или альтернативный вариант
При удалении добавляется только одно поле, FieldID = NULL (вся строка удаляется)

Преимущества - одна сущность
Недостаток - нужно сохранять лишнюю информацию (NULL значения) при вставках обязательно, при удалении
	как выберем.
*/
create table #destination
(
	ID int not null, -- foreign key #source (ID)
	FieldID varchar(128) null, -- foreign key #field (FieldID)
	Val varchar(max) null,
	dt$ datetime not null default getdate(),
	oper$ char(1) not null check (oper$ in ('I','D','U')),
	unique (ID, FieldID, dt$) -- FieldID может быть NULL для вставок и удалений поэтому не primary key
)


Вроде все просто и красиво, но блин смущают меня изначально при проектировании костыли.

С другой стороны можно все нормализовать
нормализованное решение
Код: 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.
/*
------ конечная структура - нормализованная
таблица #field заполняется данным (Field1),(Field2),(Field3)
при вставке в #source заполняются поля #field если не заполнены все,
	далее добавляется в #operation (#source.ID, getdate(),'I')
	и поля not null добавляются в таблицу #target
при удалении, добавляется только в #operation (ID, getdate(),'D')
при изменении добавляется #operation тоже самое только 'U' и все измененные not null поля
	добавляются в таблицу #target

Преимуществом метода, не храним NULL значения, сохраняется только необходимая и достаточная инфа
*/
create table #field
(
	FieldID smallint not null primary key,
	Field varchar(128) not null,
	Ver varchar(50) not null
)
create table #operation
(
	OperationID bigint not null primary key,
	ID int not null, -- foreign key #source (ID)
	dt$ datetime not null default getdate(),
	oper$ char(1) not null check (oper$ in ('I','D','U')),
	unique (ID, dt$)
)
create table #target
(
	OperationID bigint not null, -- foreign key #operation (OperationID)
	FieldID smallint not null, -- foreign key #field (FieldID)
	Val varchar(max) not null
)


Здесь при удалениях и добавлениях строк в источник (БД в примере новая), заполняется только необходимое и даже NULL можно не хранить в значениях.

Что посоветуете, коллеги?
...
Рейтинг: 0 / 0
Как кошернее спроектировать структуру?
    #39649157
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дед-Папыхтет,

Прошу прощения, а может быть купить систему мониторинга для своей БД?
По идее почти все вендоры предотставляют такие системы.
...
Рейтинг: 0 / 0
Как кошернее спроектировать структуру?
    #39649163
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulДед-Папыхтет,

Прошу прощения, а может быть купить систему мониторинга для своей БД?
По идее почти все вендоры предотставляют такие системы.
Может )))). Пользовался несколькими. забикс, леново и sqlcentral
мне sqlcentral больше всего понравилась.
1. в любой системе есть полезные фичи есть и не нужные, часто нет реализации того что нужно, один фиг то что нужно придется допиливать...
2. на покупку системы нужны обоснования, пока обоснование - денег нет, есть ДБА и разрабы - пилите.
...
Рейтинг: 0 / 0
Как кошернее спроектировать структуру?
    #39649277
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем при нормализации вылазит 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.
create table #versions
(
	VersionID smallint not null identity primary key,
	Ver nvarchar(2048) not null
)
create table #servers
(
	ServerID int identity primary key,
	ServerName sysname
)
create table #upgrades
(
	ServerID int not null, -- fk #serverSQL
	VersionID smallint not null, -- fk #versionSQL
	dt$ datetime not null default getdate(),
	primary key (ServerID,dt$)
)
create table #entities
(
	EntityID int identity not null primary key,
	VersionID smallint not null, -- fk #versionSQL
	EntityName varchar(256) not null
)
create table #types
(
	TypeID int not null primary key,
	TypeName varchar(128) not null
)
create table #fields
(
	FieldID int not null identity primary key,
	EntityID smallint not null, -- fk #entities
	FieldName varchar(128) not null,
	TypeID int not null --fk #types
)
create table #operations
(
	OperationID bigint not null identity primary key,
	EntityID int not null, -- foreign key #entities
	dt$ datetime not null default getdate(),
	oper$ char(1) not null check (oper$ in ('I','D','U')),
	unique (EntityID, dt$)
)
create table #details
(
	DetailID bigint not null identity primary key,
	FieldID int not null, -- fk #fields
	NewValue varbinary(max) not null
)



По моему трешак полный... Чота думаю что одну табличку проще и обслуживать и читать из нее, да с костылями и не полностью нормализована...
...
Рейтинг: 0 / 0
Как кошернее спроектировать структуру?
    #39649293
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
реализация сильно зависит от задачи
под ту задачу что вы озвучили подойдёт обычное key-value
где value это ваша строка "состояния" сущности (xml, json ...)
...
Рейтинг: 0 / 0
Как кошернее спроектировать структуру?
    #39649424
tip78
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторТеперь возникает вопрос мы имеем например 50 полей в запросе select * from что_смотрим, многие поля могут быть NULL.
а вы точно про нормальную форму не забыли?
...
Рейтинг: 0 / 0
Как кошернее спроектировать структуру?
    #39649654
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дед-Папыхтет2. на покупку системы нужны обоснования, пока обоснование - денег нет, есть ДБА и разрабы - пилите.

Угу...
А вы покажите смету на разработку.
Может быть смогут задуматься.
Если нет...
Ну тогда вам все карты в руки.
Проект будет долгим и интересным...
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как кошернее спроектировать структуру?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]