4

私が懸念しているのは、私が現在「辞書テーブル」と呼んでいるもの、つまり統制された語彙のリストを含むデータベース テーブルです。

例を使用してみましょう:フィールドを含むテーブルUserがあるとします:

  • user_id : 主キー
  • ファーストネーム
  • 苗字
  • user_type_id : UserType テーブルへの外部キー

2 つのフィールドだけを持つ別のテーブルUserType :

  • user_type_id : 主キー
  • name : 特定のタイプのユーザーの名前/値。

たとえば、UserTypeテーブルには、(1, Administrator)、(2, PowerUser)、(3, Normal)... が含まれる場合があります。

私の質問は次のとおりです: UserTypeのようなテーブルの正規用語は何ですか? この種のテーブルの管理に役立つコードを公開したいのですが、まず名前を付けなければなりません!

ご協力いただきありがとうございます。

現在の考え: 今のところ、ルックアップテーブルは適切な用語だと思います。これらの投稿でも同じ意味で使用されています。

唯一の問題は、ルックアップテーブルがジャンクションテーブルの名前付けにも使用される場合があることです。

4

5 に答える 5

1

単語のリストを関数のドメイン (許可される入力値のセット) としてよく見かけるので、ドメイン テーブルと呼んでいます。しかし、それは数学的な観点からです。

編集

見る：

于 2012-09-03T15:41:57.540 に答える
1

SQL 開発者との私の経験では、リレーショナル理論のバックグラウンドが強いほど、「ルックアップ テーブル」、「検証テーブル」、「ディクショナリ テーブル」などの用語を使用する可能性は低くなります。

代わりに、単にテーブルと呼んでいます。なんで？

あなたにとって重要な部分は、

  • テキスト列を 1 つだけ含む、または
  • 1 つのテキスト列と ID 番号のみを含む、または
  • 1 つのテキスト列と短いテキスト コードのみを含み、
  • 主キーは、外部キー参照のターゲットとして使用されます。

しばらく考えてみると、これらのテーブルと他のテーブルを区別しているのは、列の数だけです。関係論は列の数で関係を区別しますが、SQL においてもそのような区別の必要性を感じません。

  • すべての候補キーは、この意味で制御された語彙を実装します。キー (およびその他の適用可能なすべての制約) は、「語彙」を制御するメカニズムを提供します。
  • 表に含まれる候補キーの数、候補キーに含まれる列の数、および候補キーのいずれかが外部キー参照として使用されるかどうかに関係なく、すべての候補キーを外部キー参照のターゲットとして使用できます。今日。
  • このようなテーブルの多くは、最初は「ルックアップ」テーブルとしてのみ機能します。1 年後、誰かがより多くの情報を保存する必要性に気づきます。1 つまたは 2 つの列を追加した後、それはまだ「ルックアップ」テーブルですか?
于 2012-09-03T18:09:52.827 に答える
0

あなたが説明しているものは、一般的にデータディクショナリと呼ばれています

于 2012-09-03T15:56:39.960 に答える
0

まったく反対の方向に進み、意味ではなく技術的な名前でそれらを呼び出すことができ、人々にそれを推測させることができます-あなたはそれらを呼び出すことができますcandidate keys-それは「あなたが選んだ候補者を選ぶ」ちょっとした方法で意味があります; そして、各候補は一意です*（またはそうであるはずです）。

命名法の問題は、完全な頭痛の種ではない場合、楽しい傾向があります:-)

于 2012-09-03T15:57:07.753 に答える
0

enumC コーダーとして、このテーブルは(または列挙型)のように見えると思います。許容値を徹底的に定義し、自動的に与えられた整数を名前にリンクします (逆も同様です)。

そして、SOユーザーとして、この質問は本当に少しオープンすぎるように見えると思います.1つの一意の正規名はないと思います...

于 2012-09-03T15:47:02.517 に答える