SQL Server 2008 - Слишком много денормализации и чрезмерного индексирования: какая польза от Матрицы?

Question

У меня есть начинающий разработчик, который с энтузиазмом относится к тому, что он называет «матрицей»

Я ищу понимание сверстниками

В двух словах, это то, что мы имеем:
- 1 сильно денормализованная таблица с примерно 120 столбцами
- Точки данных варьируются от аккаунта, клиента, домашнего хозяйства, отношений, продукта, сотрудника и т. Д. *
- Один индекс на столбец: около 120 некластеризованных индексов
- Около 90% всего пространства в базе данных, используемой сегодня индексами, составляют индексы этой таблицы
- Сегодня около 1,5 миллионов строк с большим количеством нулей
- Таблица загружена хранимой процедурой, ядро ​​которой является динамическим SQL
- Все имена полей являются общими и не описывают данные
- Таблица типов словаря данных используется с динамическим SQL для загрузки любой точки данных в любое поле
- Отображение поля не является статическим: сегодня столбец dim_0001имя клиента, но завтра может быть что-то еще
- без первичного ключа
- без внешних ключей
- без реальных ограничений (для(например, все поля имеют значение NULL)

Аргумент для таблицы:
- Упрощает написание запросов, поскольку устраняет необходимость в написании соединения

Предполагаемое использование:
- AnУровень конечного пользователя и будет основным компонентом сборки Universe в Business Objects
- после разработки ETL-процесса

Моя рекомендация либо убьет тот процесс, который существует сегодня (ранняя разработка в тестовой среде), либопереместите его на следующий шаг в тесте.

На основании проведенного мною исследования, моего образования и опыта я не поддерживаю его и хочу, чтобы таблицы отбрасывались, как только один или два процесса, зависящие от этих таблиц, были перенесены в другое решение.

Сценарий ниже для вашей справки (я ограничился одним примером индекса).

Любое понимание, которое вы можете предложить (даже одним словом), ценно

-- The Matrix

CREATE TABLE [z005497].[tblMatrix](
    [as_of_dt] [datetime] NOT NULL,
    [dim_0001] [varchar](100) NULL,
    [dim_0002] [varchar](103) NULL,
    [dim_0003] [varchar](100) NULL,
    [dim_0004] [varchar](100) NULL,
    [dim_0005] [varchar](100) NULL,
    [dim_0006] [varchar](100) NULL,
    [dim_0007] [varchar](100) NULL,
    [dim_0008] [varchar](100) NULL,
    [dim_0009] [varchar](100) NULL,
    [dim_0010] [varchar](100) NULL,
    [dim_0011] [varchar](100) NULL,
    [dim_0012] [varchar](100) NULL,
    [dim_0013] [varchar](100) NULL,
    [dim_0014] [varchar](100) NULL,
    [dim_0015] [varchar](100) NULL,
    [dim_0016] [varchar](100) NULL,
    [dim_0017] [varchar](103) NULL,
    [dim_0018] [varchar](103) NULL,
    [dim_0019] [varchar](103) NULL,
    [dim_0020] [varchar](103) NULL,
    [dim_0021] [varchar](103) NULL,
    [dim_0022] [varchar](103) NULL,
    [dim_0023] [varchar](103) NULL,
    [dim_0024] [varchar](103) NULL,
    [dim_0025] [varchar](103) NULL,
    [dim_0026] [varchar](11) NULL,
    [dim_0027] [varchar](11) NULL,
    [dim_0028] [varchar](11) NULL,
    [dim_0029] [varchar](11) NULL,
    [dim_0030] [varchar](11) NULL,
    [dim_0031] [varchar](11) NULL,
    [dim_0032] [varchar](11) NULL,
    [dim_0033] [varchar](11) NULL,
    [dim_0034] [varchar](11) NULL,
    [dim_0035] [varchar](11) NULL,
    [dim_0036] [varchar](11) NULL,
    [dim_0037] [varchar](11) NULL,
    [dim_0038] [varchar](11) NULL,
    [dim_0039] [varchar](11) NULL,
    [dim_0040] [varchar](11) NULL,
    [dim_0041] [varchar](11) NULL,
    [dim_0042] [varchar](11) NULL,
    [dim_0043] [varchar](11) NULL,
    [dim_0044] [varchar](11) NULL,
    [dim_0045] [varchar](11) NULL,
    [dim_0046] [varchar](11) NULL,
    [dim_0047] [varchar](11) NULL,
    [dim_0048] [varchar](11) NULL,
    [dim_0049] [varchar](11) NULL,
    [dim_0050] [varchar](11) NULL,
    [dim_0051] [varchar](11) NULL,
    [dim_0052] [varchar](11) NULL,
    [dim_0053] [varchar](11) NULL,
    [dim_0054] [varchar](5) NULL,
    [dim_0055] [varchar](5) NULL,
    [dim_0056] [varchar](5) NULL,
    [dim_0057] [varchar](5) NULL,
    [dim_0058] [varchar](5) NULL,
    [dim_0059] [varchar](5) NULL,
    [dim_0060] [varchar](5) NULL,
    [dim_0061] [varchar](5) NULL,
    [dim_0062] [varchar](5) NULL,
    [dim_0063] [varchar](5) NULL,
    [dim_0064] [varchar](5) NULL,
    [dim_0065] [varchar](5) NULL,
    [dim_0066] [varchar](5) NULL,
    [dim_0067] [varchar](5) NULL,
    [dim_0068] [varchar](5) NULL,
    [dim_0069] [varchar](5) NULL,
    [dim_0070] [varchar](5) NULL,
    [dim_0071] [varchar](5) NULL,
    [dim_0072] [varchar](5) NULL,
    [dim_0073] [varchar](5) NULL,
    [dim_0074] [varchar](5) NULL,
    [dim_0075] [varchar](5) NULL,
    [dim_0076] [varchar](5) NULL,
    [dim_0077] [varchar](5) NULL,
    [dim_0078] [varchar](5) NULL,
    [dim_0079] [varchar](5) NULL,
    [dim_0080] [varchar](5) NULL,
    [dim_0081] [varchar](5) NULL,
    [dim_0082] [varchar](5) NULL,
    [dim_0083] [varchar](5) NULL,
    [dim_0084] [int] NULL,
    [dim_0085] [int] NULL,
    [dim_0086] [int] NULL,
    [dim_0087] [int] NULL,
    [dim_0088] [int] NULL,
    [dim_0089] [int] NULL,
    [dim_0090] [int] NULL,
    [dim_0091] [int] NULL,
    [dim_0092] [int] NULL,
    [dim_0093] [int] NULL,
    [dim_0094] [varchar](12) NULL,
    [dim_0095] [varchar](12) NULL,
    [dim_0096] [varchar](12) NULL,
    [dim_0097] [varchar](120) NULL,
    [dim_0098] [varchar](120) NULL,
    [dim_0099] [varchar](120) NULL,
    [dim_0100] [numeric](20, 0) NULL,
    [dim_0101] [varchar](20) NULL,
    [dim_0102] [varchar](20) NULL,
    [dim_0103] [varchar](20) NULL,
    [dim_0104] [varchar](20) NULL,
    [dim_0105] [varchar](20) NULL,
    [dim_0106] [varchar](20) NULL,
    [dim_0107] [varchar](20) NULL,
    [dim_0108] [varchar](20) NULL,
    [dim_0109] [varchar](20) NULL,
    [dim_0110] [varchar](20) NULL,
    [dim_0111] [varchar](20) NULL,
    [dim_0112] [varchar](20) NULL,
    [dim_0113] [varchar](20) NULL,
    [dim_0114] [varchar](20) NULL,
    [dim_0115] [varchar](20) NULL,
    [dim_0116] [varchar](20) NULL,
    [dim_0117] [varchar](20) NULL,
    [dim_0118] [varchar](20) NULL,
    [dim_0119] [varchar](20) NULL,
    [dim_0120] [varchar](20) NULL,
    [lastLoad] [datetime] NULL
) ON [PRIMARY]



-- Index example

CREATE NONCLUSTERED INDEX [idx_dim_0001 (not unique)] ON [z005497].[tblMatrix] 
(
    [dim_0001] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]


-- The configuration table from which developers would find out what is in the Matrix

CREATE TABLE [z005497].[tblMatrixCfg](
    [dimId] [int] IDENTITY(100000,1) NOT NULL,
    [colName] [varchar](25) NOT NULL,
    [dataType] [varchar](25) NOT NULL,
    [dimName] [varchar](25) NOT NULL,
    [dimDesc] [varchar](500) NOT NULL,
    [dimpath] [varchar](5000) NOT NULL,
    [loadDate] [datetime] NOT NULL,
    [modUser] [varchar](100) NOT NULL,
    [modDate] [datetime] NOT NULL,
 CONSTRAINT [PK_tblMatrixCfg_1] PRIMARY KEY CLUSTERED 
(
    [dimId] ASC,
    [colName] ASC,
    [dimName] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Answer 1

Убейте его, если сможете.

Кроме того, этому разработчику нужно гораздо больше опыта.И он / она должен получить его в другой компании.

Это в основном нарушает так много вещей, что я не знаю, с чего начать.

Даже если вы закончите борьбу с сильно нормализованной моделью, котораяследуя чьему-то рабскому опыту, это не сравнится с катастрофой, которую собирается создать этот проект.

Answer 2

Просто приведу один пример того, что Кейд имел в виду «я не знаю, с чего начать»:

"сегодня столбец dim_0001 - это имя клиента, а завтра, может быть, что-то еще"

Как правило, это также означает, что в системе принятия пользователей dim_0001 может быть именем клиента (и система может показаться работающей и принятой), а затем вы переходите к производству, а dim_0001 становится именем жены президента или поэтому, а затем часы собраний нужно потратить, чтобы выяснить (а) где проблема, и (б) как решить ее как можно быстрее.

((b) обычно сводится к исправлению кода такими словами, как «если col_name = dim_0001, тогда не рассматривайте его как то, что указано в матрице, а вместо этого обрабатывайте его как жестко закодированный здесь».)

Answer 3

«Какая польза от Матрицы?»

Ну, я конечно не понимаю.

Я никогда не видел ничего подобного раньше, и я не понимаю, как это должно использоваться или как индексы предназначены для ускорения чего-либо или как можно запрашивать эту таблицу, не используя хотя бы самостоятельные объединения.

Если хочешь, назови меня неопытным, но для меня это первое. Я думаю, что если это способ делать вещи, поставщики БД не должны прилагать столько усилий, чтобы позволить нам, разработчикам, определять таблицы со столбцами, которые имеют разные типы данных, со связями.

Answer 4

Это результат попытки вставить объектно-ориентированную парадигму в реляционную систему. Базы данных документов допускают такой вид программирования:

Документы внутри базы данных, ориентированной на документы, в некотором роде похожи на записи или строки в реляционных базах данных, но онименее жесткийОни не обязаны придерживаться стандартной схемы, и при этом они не будут иметь одинаковые секции, слоты, детали, ключи или тому подобное.Например, вот документ:

FirstName="Bob", Address="5 Oak St.", Hobby="sailing".

Другой документ может быть:

FirstName="Jonathan", Address="15 Wanamassa Point Road", Children=[{Name:"Michael",Age:10}, {Name:"Jennifer", Age:8},
{Name:"Samantha", Age:5}, {Name:"Elena", Age:2}].

Оба документа содержат некоторую похожую информацию, а другую - разную.В отличие от реляционной базы данных, в которой каждая запись будет иметь один и тот же набор полей, а неиспользуемые поля могут оставаться пустыми, в этом случае в любом документе (записи) нет пустых «полей».Эта система позволяет добавлять новую информацию и не требует явного указания, если другие части информации пропущены.

Попытка использовать эту парадигму в реляционной базе данных - это "квадратный колышек, круглыйдыра "проблема.База данных документов могла бы быть превосходной для высокотранзакционной системы, но анализ был бы лучше обслуживать, загружая транзакционные данные в различные таблицы фактов в хранилище данных.