0

質問があります。

2つのテーブルがあるとしましょう

Parent(nameParent, children)

明らかに私が持っている場合:

Parent

'Mary' | 'John'
'Mary' | 'Dan'
'Mary' | 'Chris'

重複したnameParentエントリがあります。だから私が持っている場合：

Parent(nameParent)
'Mary'

Child(nameChild, nameParent)
'John' | 'Mary'
'Dan'  | 'Mary'
'Chris'| 'Mary'

nameParentディスク上のスペースを消費するエントリではなく、親 Mary へのポインタであるため、これは最初の例よりも効率的であるというのは本当ですか?

4

3 に答える 3

2

効率的？幾分。物理ディスク容量ではなく、設計とパフォーマンスに重点を置く必要があります。ただし、参照整合性は提供されます。この質問の典型的なデザインは、次のようなものです。

id | 名前| parent_id
1メアリーNULL
2ヨハネの手紙1
3ダン1
4クリス1
于 2013-01-27T21:03:43.307 に答える
1

ディスク容量に関しては、 aVARCHARは指定した最大バイト数 (おおまかに) を単純に取り (VARCHAR(16)常に の 2 倍VARCHAR(8))、 anINTは一定の 4 バイトなどです。行ごとのディスク容量 (マイナス インデックス) を簡単に見積もることができます。 ）すべてのフィールドを合計するだけです：

INT id           -- 4 bytes
CHAR name(15)    -- 15 bytes
TEXT description -- variable, depending on the content

理想的には、同じ文字列を 2 回格納しないようにして、データの重複を回避します。あなたの場合、nameParent列を親テーブルを指す数値 ID に置き換えるのがおそらく最善です。

とはいえ、インデックスもディスク領域を占有します。これは、フィールドのサイズの約 2 倍の行数を掛けたものです。idキー ( ) を主キーにしたと仮定しましょうint。2048 行で、約 16 キロバイトを占めます。

行ごとのテーブルの合計ディスク使用量を見積もるときは、すべてのフィールドのサイズを合計してから、インデックスのサイズを追加します。これにより、大まかな見積もりが得られます。

実は重要な部分

もちろん、ディスク容量はデータベースにとって重要ではありません。代わりに、常にパフォーマンスに重点を置く必要があります。テーブルが非常に大きくならない限り (数百万行)、実際にはまったく問題にはなりません。

特定のケースでpersonは、フィールドid、parentおよびを含むテーブルを作成するだけnameです。parent親がいない人のためにフィールドをに設定しNULL、子供がparentフィールドを使用して親が誰であるかを指定できるようにします。そうすれば、すべてが 1 つの表にまとめられ、家系全体を表すことができますが、それでも非常に簡単です。

于 2013-01-27T21:16:06.793 に答える
0

データの整合性を向上させながら、データの冗長性を排除するために Names テーブルを作成することを検討してください。

create table Names (
  ID MEDIUMINT NOT NULL AUTO_INCREMENT,
  Name VARCHAR(30) NOT NULL,
  PRIMARY KEY (ID),
  UNIQUE (Name)
);

create table ChildParentNames (
  ChildName MEDIUMINT,
  ParentName MEDIUMINT,
  FOREIGN KEY (ChildName) REFERENCES Names(ID),
  FOREIGN KEY (ParentName) REFERENCES Names(ID)
)
于 2013-01-27T21:16:21.803 に答える