1

複数のユーザータイプのサイトがあるプロジェクトがあります。そして、このためのベストプラクティスに頭を悩ませるのに苦労しています。

ノードの種類に関係なく、フォローしている（ノード）からアクティビティを取得できるようにしたい。ノードタイプが次のようになります。

ユーザー：組織：

組織は、ユーザーとして機能できるエンティティになります。コメントを書いて、メッセージを送ってください。ただし、組織は、組織の情報を編集できるユーザーで構成されています。組織もフォローでき、フォローできます。

  • A）ユーザーと組織は別々のテーブルにする必要がありますか？
  • B）一般的に言えば、これはどのように保存する必要がありますか。
  • C）それらが実際に2つのテーブルである場合、フォローしているテーブルからアクティビティを取得するときに結合はどのように機能しますか？
4

2 に答える 2

2

わかりました、ここに1つの可能なアプローチがあります。

おおまかな攻略法はこちら

  • アカウント (つまり、アクセス資格情報) はプロファイル (エンティティ固有のデータ) とは別のものです
  • アカウントはプロファイルのタイプを識別します
  • プロファイルは、外部キーを使用してアカウントにリンクします。他の関連テーブル (コメントなど) はaccount.account_id、外部キーとして使用します。クエリは、追加情報を選択するときに使用するプロファイル テーブルを決定できます。

これは、私がすばらしいMySQL Workbenchツールで作成した簡単な ERDです。

エルド http://www.shackpics.com/files/sample_erd_co3zt3y5la0l81g4m530.png

このモデルのツールによって生成された CREATE スクリプトは次のとおりです。

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
USE `mydb`;

-- -----------------------------------------------------
-- Table `mydb`.`account`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `account` (
  `account_id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `login` VARCHAR(45) NULL ,
  `password` VARCHAR(45) NULL ,
  `account_type` TINYINT UNSIGNED NULL ,
  PRIMARY KEY (`account_id`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`organization_profile`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `organization_profile` (
  `organization_profile_id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `account_id` INT UNSIGNED NOT NULL ,
  `organization_name` VARCHAR(45) NULL ,
  PRIMARY KEY (`organization_profile_id`) ,
  INDEX `fk_organization_profile_account` (`account_id` ASC) ,
  CONSTRAINT `fk_organization_profile_account`
    FOREIGN KEY (`account_id` )
    REFERENCES `account` (`account_id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`user_profile`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `user_profile` (
  `user_profile_id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `account_id` INT UNSIGNED NULL ,
  `first_name` VARCHAR(45) NULL ,
  `last_name` VARCHAR(45) NULL ,
  PRIMARY KEY (`user_profile_id`) ,
  INDEX `fk_user_profile_account1` (`account_id` ASC) ,
  CONSTRAINT `fk_user_profile_account1`
    FOREIGN KEY (`account_id` )
    REFERENCES `account` (`account_id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`xref_user_profile_has_organization_profile`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `xref_user_profile_has_organization_profile` (
  `user_profile_id` INT UNSIGNED NOT NULL ,
  `organization_profile_id` INT UNSIGNED NOT NULL ,
  PRIMARY KEY (`user_profile_id`, `organization_profile_id`) ,
  INDEX `fk_xref_user_profile_has_organization_profile_user_profile1` (`user_profile_id` ASC) ,
  INDEX `fk_xref_user_profile_has_organization_profile_organization_pro1` (`organization_profile_id` ASC) ,
  CONSTRAINT `fk_xref_user_profile_has_organization_profile_user_profile1`
    FOREIGN KEY (`user_profile_id` )
    REFERENCES `user_profile` (`user_profile_id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_xref_user_profile_has_organization_profile_organization_pro1`
    FOREIGN KEY (`organization_profile_id` )
    REFERENCES `organization_profile` (`organization_profile_id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

注:平文のパスワードを保存することはお勧めしません。これは、関係を説明するためのサンプル モデルにすぎず、安全なアクセス資格情報ストレージの詳細をカバーするものではありません。

ここでの基本的な戦略は、各プロファイル テーブルに「account_type」番号を任意に「与える」ことです。たとえば、組織は1、ユーザーは2になります。

于 2009-08-06T20:11:03.273 に答える
1

あなたの場合、組織もユーザーのように聞こえます。これは、次のようなデータベースと非常によく似ています。

  1. すべてのユーザーと組織のテーブルがあります。それらをプリンシパルと呼びます。この表では、組織とユーザーは同じように扱われます。これは、アクティビティのようにデータを保存する場所です。タイプ（組織またはユーザー）の列を追加できます。

  2. 関係のための別のテーブルがあります。2つの列が必要です。1つの列は組織で、もう1つの列はこの組織に属するユーザーです。組織に100人のユーザーがいるとすると、このテーブルにはユーザーごとに100個のエントリがあります。

于 2009-08-06T19:37:27.047 に答える