4

我有一个崭露头角的开发人员，他对他称之为“矩阵”的东西非常热情</p>

我正在寻找同行的见解

简而言之，这就是我们所拥有的：
- 1 个高度非规范化的表，大约 120 列
- 数据点范围包括帐户、客户、家庭、关系、产品、员工等……<br> - 每列一个索引：大约 120 个非聚集索引
- 今天索引使用的数据库中大约 90% 的空间是该表上的索引
- 今天大约 150 万行有很多空值
- 表加载了一个存储过程，其核心是动态 SQL
- 所有字段名称都是通用的并且不描述数据
- 数据字典类型表与动态 SQL 一起使用以将任何数据点加载到任何字段
- 字段映射不是静态的：今天列 dim_0001 是客户名称，但明天可能是别的
- 没有主键
- 没有外键
- 没有真正的约束（例如所有字段都可以为空）

表的参数：
- 使编写查询更简单，因为它消除了编写一些连接的需要

预期用途：
- 最终用户层，将成为 Business Objects 中构建的 Universe 的核心组件
- 后 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]
4

4 回答 4

7

如果可以的话，杀了它。

此外，该开发人员需要更多的经验。他/她应该在另一家公司得到它。

它基本上违反了很多我不知道从哪里开始的事情。

即使你最终与一个高度规范化的模型作斗争，它盲目地遵循某人的最佳实践，它也无法与这种设计将要造成的灾难相提并论。

于 2011-10-15T01:42:21.393 回答
5

举一个例子来说明凯德对“我不知道从哪里开始”的含义：

“今天列 dim_0001 是客户名称，但明天可能是其他名称”

这通常也意味着在用户接受系统中，dim_0001 可以是客户名称（并且系统似乎可以工作并被接受），然后您进入生产阶段，dim_0001 会成为总裁妻子的名字左右，并且然后需要花费数小时的会议来试图找出 (a) 问题出在哪里，以及 (b) 如何在尽可能短的时间内解决问题。

（（b）通常相当于用“如果 col_name = dim_0001 则不要将其视为矩阵所说的内容，而是将其视为此处硬编码的内容”之类的内容来修补代码。）

于 2011-10-15T08:42:31.560 回答
4

“矩阵有什么用？”

好吧，我当然不明白。

我以前从未见过这样的事情，我不明白它是如何被使用的，或者索引是如何加速任何事情的，或者如何在不使用至少自连接的情况下查询这个表。

如果你愿意，可以叫我没有经验，但这对我来说是第一次。我认为，如果这是做事的方式，数据库供应商不应该付出太多努力来允许我们开发人员定义具有不同数据类型的列和关系的表。

于 2011-10-15T09:34:56.283 回答
1

这是试图将面向对象范式填充到关系系统中的结果。文档数据库允许进行这种编程：

面向文档的数据库中的文档在某些方面类似于关系数据库中的记录或行，但它们不那么严格。它们不需要遵守标准模式，它们也不会具有所有相同的部分、插槽、部件、键等。例如，这是一个文档：

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}].

两份文件都有一些相似的信息和一些不同的信息。与每条记录将具有相同字段集且未使用的字段可能保持为空的关系数据库不同，在这种情况下，任何一个文档（记录）中都没有空的“字段”。该系统允许添加新信​​息，并且不需要明确说明是否遗漏了其他信息。

试图在关系数据库中使用这种范例是一个“方钉圆孔”的问题。文档数据库可能非常适合高度事务性系统，但通过将事务性数据加载到数据仓库中的各种事实表中会更好地进行分析。

于 2011-10-17T20:01:28.850 回答