0

私は追跡する必要がある多くのアカウントを持っています。これらのアカウントはすべて非常に似ており、次のようなフィールドがあります。

account_number, date_opened, current_expenditure etc.

現在、これらのアカウントには 3 つのタイプがあります (タイプ A、B、C と呼びます)。これらのアカウントの各タイプには、そのタイプに固有の他のフィールドが少なくとも 1 つ必要です。例えば：

Type A: account_number, date_opened, current_expenditure, owner
Type B: account_number, date_opened, current_expenditure, location
Type C: account_number, date_opened, current_expenditure, currency

私の質問は、これらを 1 つの大きなテーブルに結合して、アカウントの種類を示す列を作成する必要があるかどうかです (無関係なフィールドは空のままにします)。

Table 1: accounts
Table 2: accts_emp_maps

Account Columns: 
account_number, type, date_opened, current_expenditure, owner, location, currency

または、アカウントの種類ごとに個別のテーブルを用意する必要がありますか? 従業員をこれらのアカウントにマッピングするテーブルが他にもあることに注意してください。アカウントをさまざまな種類に分割する場合は、マップも分割する必要があります。いいえ:

Table 1: A_accounts
Table 2: A_accts_emp_maps
Table 3: B_accounts
Table 4: B_accts_emp_maps
Table 5: C_accounts
Table 6: C_accts_emp_maps
4

3 に答える 3

1

古典的には、所有者、場所、通貨の1つだけを確保するために、これにスーパーキー/サブタイプパターンを使用する可能性があります

  • 共通列と型列を持つ1つのテーブル
  • PK +タイプ（A、B、またはC）列の一意のスーパーキー
  • PK+タイプのキーを持つ3つの子テーブル。ここで特定の列を追加します
  • 子テーブルのA、B、またはCに制限するために、子タイプ制約の制約を確認してください

さて、この場合、簡単にするために冗長な列を用意することを検討しますが

例：

于 2012-06-12T13:36:53.990 に答える
1

owner, location, currency余分な列を使用して、1 つのテーブル アプローチを使用します。それはあなたの人生を楽にします。

大きくなりすぎる場合は、タイプごとに分割できます。

于 2012-06-12T13:33:44.207 に答える
-1

あなたがリストした2つのオプションのうち、私は間違いなく最初のものを選びます. ほとんどのアプリケーションで問題なく、テーブルを手動でクエリする方が簡単です。(2 番目に提案された設計では、3 セットのアカウント テーブル間で多くの情報が複製されます)。

ただし、ニーズに応じて、より正規化されたより優れたデータベース設計は次のようになります。

Table: accounts
===============
number, type, date_opened, current_expenditure

Table: account_owners
=====================
account_number, owner

Table: account_currencies
=========================
account_number, currency

Table: account_locations
========================
account_number, location
于 2012-06-12T13:34:45.923 に答える