1

I have a project in which there is a site with multiple user types. And I am having trouble wrapping my head around the best practice for this.

I want to be able to get activity from (nodes) you follow regardless of node type. Pretend the node types are:

User: Organization:

An organization will be an entity that can act as a user. Write comments, send messages. But an organization is made up of users who can edit the orgs information. Organizations can also follow, and be followed.

  • A) Should Users and Organizations be separate tables?
  • B) Generally speaking how should this be stored.
  • C) If they are in fact 2 tables, how does a join work when getting activity from those you follow?
4

2 回答 2

2

好的，这是一种可能的方法。

这里的粗略策略是这样的

  • 帐户（即访问凭据）与配置文件（实体特定数据）分开
  • 帐户识别配置文件的类型
  • 配置文件使用外键链接回他们的帐户。其他相关表（例如注释）将account.account_id用作它们的外键。然后查询可以确定在选择附加信息时使用哪个配置文件表。

这是我使用出色的MySQL Workbench工具完成的快速 ERD 。

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. 您将有另一个表用于关系。它只需要两列，一列是组织，另一列是属于该组织的用户。假设一个组织有 100 个用户，您将在此表中为每个用户创建 100 个条目。

于 2009-08-06T19:37:27.047 回答