4

私には、彼が「マトリックス」と呼んでいるものに非常に熱心な新進の開発者がいます</p>

ピアインサイトを探しています

簡単に言うと、これが私たちが持っているものです:
- 約 120 列の 1 つの高度に非正規化されたテーブル
- アカウント、顧客、世帯、関係、製品、従業員などのデータ ポイントの範囲...<br> - 列ごとに 1 つのインデックス: 約 120 の非-クラスタ化されたインデックス - 現在
インデックスで使用されているデータベース内の全領域の約 90% は、このテーブルのインデックスです
- 現在、多くの null を含む約 150 万行
- 動的 SQL をコアとするストアド プロシージャをロードしたテーブル
- すべてのフィールド名は汎用的ですデータを記述しない
- データ ディクショナリ タイプのテーブルを動的 SQL で使用して、任意のデータ ポイントを任意のフィールドにロードします
- フィールド マッピングは静的ではありません。今日は列 dim_0001 が顧客名ですが、明日は別の名前になる可能性があります
- 主キー
なし - 外部キー
なし - 実際の制約なし (たとえば、すべてのフィールドが null 可能)

テーブルの引数:
- 結合を記述する必要がなくなるため、クエリの記述が簡単になります。

使用目的:
- End User Layer であり、Business Objects のユニバース ビルドのコア コンポーネントとなる
- ETL プロセス開発 後

私の推奨事項は、現在のプロセスを強制終了するか (テスト環境での初期開発)、テストの次のステップに移行することです。

私が行った調査、教育、および経験に基づいて、私はそれをサポートしていません。これらのテーブルに依存する 1 つまたは 2 つのプロセスが別のソリューションに移行されたら、すぐにテーブルを削除したいと考えています。

以下のスクリプトを参照してください (インデックスの例を 1 つに限定しました)。

あなたが提供できる洞察は（たとえ一言の意見であっても）価値があります 

-- 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

「どこから始めたらいいのかわからない」という Cade の意味の例を 1 つ挙げると、次のようになります。

「今日の列dim_0001は顧客名ですが、明日は別の名前かもしれません」

これは通常、ユーザー受け入れシステムでは、dim_0001 が顧客名になる可能性があり (システムが機能して受け入れられるように見える場合があります)、その後、生産に移ると、dim_0001 が社長の妻などの名前になることも意味します。次に、(a) 問題がどこにあるのか、(b) できるだけ短時間で問題を解決する方法を見つけ出すために、何時間もの会議を費やす必要があります。

((b) 通常、「if 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 に答える