1

ほとんどが「文字列」である非常に具体的な列が多数あるテーブルがあります。この名前のハードコーディングは、後でルールが変更されたときに悲しみをもたらすと思います。各行がマスターテーブルの列であり、それぞれがその名前のルックアップキーを持つことができる2番目のテーブルを使用するオプションを調査しています。

これはERのベストプラクティスに反するように見えるかもしれませんが、柔軟に対応できます. テーブル 1 から (SQL1)、(SQL2) などのサブセレクトを含むビューを使用できます。SQLServer でもマルチテーブル ビューを更新できるかどうかはわかりません。

上記の考えは大歓迎です。

ありがとう、

エド

4

3 に答える 3

3

あなたが探しているのは（EAV）テーブルのようなものです。Entity-Attribute-Value

EAV は、将来のさらなるカスタマイズを可能にするという点で柔軟になると、はるかに動的なプロセスを可能にしますが、実装が不十分であると、リレーショナル モデルにうまく従わないことを意味する可能性があります。This SO questionは、その種のソリューションに固有の問題のいくつかの概要を提供します。

列をリファクタリングして、コンテキストに依存しない命名規則を使用する方がよいでしょう。

于 2012-10-18T23:31:39.200 に答える
1

列をSQL_VARIANT型として格納できます。
これは世界のベストプラクティスではありませんが、使用できます。

create table t  (anything sql_variant);
insert t values (current_timestamp);
insert t values (current_timestamp+1);
insert t values (1);
insert t values ('some text');
insert t values (current_timestamp-3);
insert t values (null);
insert t values (2.1234);
insert t values (cast(2 as decimal(10,5)));
insert t values ('some more text');

-- sample based on type
select *
  from t
 where CAST(sql_variant_property(anything, 'BaseType') as varchar(20)) like '%char';

あなたの質問から、別の列またはリンクされたテーブルの列に格納されている型を格納することになります。

于 2012-10-18T23:27:37.330 に答える
1

インナー プラットフォーム効果を回避します。SQL Server では、テーブル内の列を照会する機能が既に提供されています。sys.tablesおよびsys.columnsを参照してください。

これらを使用して、所有している列をクエリし、標準の DDL コマンドを使用して、必要に応じて列を追加および削除します。正規化、結合などを恐れないでください。

「データベース内のデータベース」は、通常の設計では些細なことを行う必要がある場合、ほとんどの場合、途方にくれます。

于 2012-10-18T23:24:59.203 に答える