0

私は組織のメンバーシップ ディレクトリを作成しており、全員の詳細を整理して更新可能な方法で保持するための良い方法を見つけようとしています。私は3つのテーブルを持っています:

Person テーブルは実際の人物を扱います

CREATE TABLE `person` (
    `personid` BIGINT PRIMARY KEY AUTO_INCREMENT,
    `personuuid` CHAR(32) NOT NULL,
    `first_name` VARCHAR(50) DEFAULT '',
    `middle_name` VARCHAR(50) DEFAULT '',
    `last_name` VARCHAR(50) DEFAULT '',
    `prefix` VARCHAR(32) DEFAULT '',
    `suffix` VARCHAR(32) DEFAULT '',
    `nickname` VARCHAR(50) DEFAULT '',
    `username` VARCHAR(32) ,
    `created_on` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    `created_by` CHAR(33) DEFAULT '000000000000000000000000000000000',
    `last_updated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    `last_updated_by` CHAR(33) DEFAULT '000000000000000000000000000000000'
) ENGINE=InnoDB, COMMENT='people';

個人に関する情報。学校、電話番号、電子メール、Twitter 名など。これらの値はすべて json として「値」に格納され、私のプログラムはすべてを処理します。ユーザーが更新するたびに、変更の推移を示す新しいエントリが作成されます。

CREATE TABLE `person_info` (
    `person_infoid` BIGINT PRIMARY KEY AUTO_INCREMENT,
    `person_infouuid` CHAR(32) NOT NULL,
    `person_info_type` INT(4) NOT NULL DEFAULT 9999,
    `value` TEXT,
    `created_on` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    `created_by` CHAR(33) DEFAULT '000000000000000000000000000000000',
    `last_updated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    `last_updated_by` CHAR(33) DEFAULT '000000000000000000000000000000000'
) ENGINE=InnoDB, COMMENT="Personal Details";

person テーブルと person_info テーブルの間のマップ

CREATE TABLE `person_info_map` (
    `personuuid` CHAR(32),
    `person_infouuid` CHAR(32) ,
    `created_on` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    `created_by` CHAR(33) DEFAULT '000000000000000000000000000000000',
    `is_active` INTEGER(1)
) ENGINE=InnoDB, COMMENT="Map between person and person info";

更新があるたびに新しいエントリを作成していることを考えるとperson_info、I / Oエラー、テーブルが大きくなるなどを心配する必要があるかどうか疑問に思っています.もしそうなら、可能な解決策は何ですか? 私は、このようなデータベース スキーマを実際に扱ったことがないので、将来失敗するのではなく、助けを求める必要があると考えています。

更新の頻度を尋ねる人もいると思います。正直なところ、私はあまり期待していません。現在、ディレクトリには 2,000 人のメンバーがいますが、いつでも 10,000 を超えるアクティブなメンバーがいるとは思っていません。また、最大で 50 の異なるオプション タイプがあると考えていますが、安全と将来の目的のために、最大 1000 の異なるオプション タイプを許可します。

この小さなピースを考慮して、ここからどのように進めるべきかについて誰かアドバイスはありますか?

4

3 に答える 3

1

  1. person と person_info の関係は、1 対多の関係としてモデル化する必要があるようです (つまり、1 人の person レコードに多くの person_info レコードがあります)。そうであれば、person_info_map は何の役にも立たないので削除できます。

  2. テーブル間の関係を確立するために UUID フィールドを使用しないでください。主キーを使用して、それらに外部キー制約を作成します。これにより、データの整合性が強化され、クエリ時の結合のパフォーマンスが向上します。

于 2012-12-15T14:59:05.873 に答える
0

個人的には、現時点での人物のビューとして 2 つのテーブルをマージし、変更を書き込む別のテーブル (イベント ストアなど) を用意します。

これにより、人を取得する必要があるたびに 2 つのテーブルに参加する必要がなくなります。

しかし、それはアプリケーションの観点からです。DBAが私の耳の中で叫んでいるのがすでに聞こえます:)

于 2012-12-15T14:59:18.620 に答える
0

誰も実際に質問に答えなかったので、私がやったことを投稿します。システムが稼働していないため、まだ機能するかどうかはわかりませんが、機能するはずです。

私は先に進み、上記のシステムを維持しました。問題になるほど多くの行にヒットしないことを願っていますが、ヒットした場合は、「古い」データのチャンクをアーカイブする予定です。それは役立つと思いますが、機械はおそらく私たちの使用ペースになると思います。

于 2012-12-28T01:18:25.167 に答える