MySQLでニュースレターのデータベースを設計するためのガイド

このチュートリアルでは、ユーザー、ニュースレター、購読者、およびメーリングリストを管理するためのニュースレターシステムのデータベーススキーマを設計するための完全な手順を提供します。それをさらに強化し、ニュースレターサービスを提供するための電子メールベースのマーケティングプラットフォームを開発するために使用することができます。同じデータベースアーキテクチャまたはスキーマを参照として使用して、オンラインニュースレターを管理したり、ニュースレターや雑誌のハードコピーを配布したりできます。また、デジタルマーケティングエージェンシーがリードやマーケティングキャンペーンを管理するために使用することもできます。

実体関連図または視覚的なデータベース設計を以下に示します。

ニュースレターデータベースの設計

メモ：データベースは、役割ベースのアクセス制御（RBAC）テーブルを追加することでさらに拡張できます。このセキュリティは、MySqlでRBACデータベースをフォローすることで処理できます。また、顧客への請求に必要なテーブルは含まれていません。 MySQLのオンラインショッピングカートデータベースを参照して、注文の管理に必要なテーブルを導き出すことができます。

また、Ubuntu 20.04LTSにMySQL8をインストールする方法、WindowsにMySQL 8をインストールする方法、UbuntuにMySQL Workbenchをインストールする方法、Windows10にWorkbenchを使用してMySQL8をインストールする方法、MySqlのRBACデータベースなどの人気のあるチュートリアルにアクセスすることもできます。 MySqlのブログデータベース、MySQLのクイズデータベース、MySQLのPoll＆Surveyデータベース、MySQLのオンラインショッピングカートデータベース、MySQLの基本的なSQLクエリを学ぶ。

ニュースレターデータベース

最初のステップは、ニュースレターデータベースを作成することです。以下に示すクエリを使用して作成できます。

CREATE SCHEMA `newsletter` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

文字セットutf8mb4を使用しました幅広いキャラクターをサポートします。

ユーザーテーブル

このセクションでは、ユーザーテーブルを設計しますユーザー情報を保存します。同じテーブルを使用して、管理者や顧客を含むさまざまなタイプのユーザーを管理できます。また、ニュースレターの管理者に関連するために使用することもできます。ユーザーは自分のニュースレターやメーリングリストを追跡できます。以下は、ユーザーテーブルのすべての列の説明です。

Id 名ミドルネーム姓モバイルメールパスワードハッシュ管理者顧客登録場所最終ログインはじめにプロフィール

ユーザーを識別するための一意のID。

ユーザーの名。

ユーザーのミドルネーム。

ユーザーの名前。

ユーザーの携帯電話番号。ログインと登録の目的で使用できます。

ユーザーのメールアドレス。ログインと登録の目的で使用できます。

適切なアルゴリズムによって生成されたパスワードハッシュ。プレーンなパスワードや暗号化されたパスワードの保存は避けなければなりません。

ユーザーが管理者であるかどうかを識別するフラグ。 RBACデータベースの設計に従ってRBACテーブルを作成する場合は、必須ではありません。

登録ユーザーがニュースレターと購読者を管理できるかどうかを識別するフラグ。 RBACデータベースの設計に従ってRBACテーブルを作成する場合は、必須ではありません。

この列は、アプリケーションを使用しているユーザーの寿命を計算するために使用できます。

ユーザーの最後のログインを識別するために使用できます。

ユーザーの簡単な紹介。

顧客の詳細。

適切な制約のあるユーザーテーブルを以下に示します。

CREATE TABLE `newsletter`.`user` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `firstName` VARCHAR(50) NULL DEFAULT NULL,
  `middleName` VARCHAR(50) NULL DEFAULT NULL,
  `lastName` VARCHAR(50) NULL DEFAULT NULL,
  `mobile` VARCHAR(15) NULL,
  `email` VARCHAR(50) NULL,
  `passwordHash` VARCHAR(32) NOT NULL,
  `admin` TINYINT(1) NOT NULL DEFAULT 0,
  `customer` TINYINT(1) NOT NULL DEFAULT 0,
  `registeredAt` DATETIME NOT NULL,
  `lastLogin` DATETIME NULL DEFAULT NULL,
  `intro` TINYTEXT NULL DEFAULT NULL,
  `profile` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_mobile` (`mobile` ASC),
  UNIQUE INDEX `uq_email` (`email` ASC) );

ニュースレターテーブル

このセクションでは、ニュースレターテーブルをデザインします。ニュースレターのデータを保存します。以下は、ニュースレターテーブルのすべての列の説明です。

Id ユーザーID タイトル説明タイプ複数グローバルステータス作成場所更新日公開日コンテンツ

ニュースレターを識別するための一意のID。

管理者または顧客を識別するためのユーザーID。

ニュースレターを識別するためのニュースレターのタイトル。

ニュースレターの説明。

さまざまなニュースレターの種類を区別するための種類。

ニュースレターを1回送信するか複数回送信するかを示すフラグ。

ニュースレターをすべての購読者に送信するかどうかを示すフラグ。

ステータスを識別するために使用できます。ニュースレターのステータスには、新規、準備完了、公開済みが含まれます。

ニュースレターが作成された日時を保存します。

ニュースレターが更新された日時を保存します。

ニュースレターが発行された日時を保存します。

複数フラグがfalseに設定されている場合にニュースレターのコンテンツを保存するために使用される列。

複数の列を使用して、ニュースレターが1回だけ送信するように計画されているか複数回送信するように計画されているかを識別します。ニュースレターのコンテンツは、1回だけ送信する予定の場合に備えて、コンテンツ列に保存できます。複数フラグがtrueに設定されている場合、各エディションのコンテンツを格納するためにエディションテーブルを使用する必要があります。適切な制約のあるニュースレターの表は次のとおりです。

CREATE TABLE `newsletter`.`newsletter` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `userId` BIGINT NOT NULL,
  `title` VARCHAR(75) NOT NULL,
  `descritpion` VARCHAR(2048) NULL DEFAULT NULL,
  `type` SMALLINT(6) NOT NULL DEFAULT 0,
  `multiple` TINYINT(1) NOT NULL DEFAULT 0,
  `global` TINYINT(1) NOT NULL DEFAULT 0,
  `status` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `publishedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_newsletter_user` (`userId` ASC),
  CONSTRAINT `fk_newsletter_user`
    FOREIGN KEY (`userId`)
    REFERENCES `newsletter`.`user` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ニュースレターメタ

ニュースレターメタテーブルは、ニュースレターバナーのURLなどのニュースレターに関する追加情報を保存するために使用できます。以下は、ニュースレターメタテーブルのすべての列の説明です。

Id ニュースレターID タイプキーコンテンツ

ニュースレターのメタを識別するための一意のID。

親ニュースレターを識別するためのニュースレターID。

メタデータを分類するタイプ。

メタを識別するキー。

ニュースレターのメタデータを保存するために使用される列。

適切な制約のあるニュースレターメタテーブルは次のとおりです。

CREATE TABLE `newsletter`.`newsletter_meta` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `newsletterId` BIGINT NOT NULL,
  `type` VARCHAR(50) NOT NULL,
  `key` VARCHAR(160) NOT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_meta_newsletter` (`newsletterId` ASC),
  UNIQUE INDEX `uq_pnewsletter_meta` (`newsletterId` ASC, `key` ASC),
  CONSTRAINT `fk_meta_newsletter`
    FOREIGN KEY (`newsletterId`)
    REFERENCES `newsletter`.`newsletter` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

エディションテーブル

このセクションでは、エディションテーブルを設計します複数のフラグがtrueに設定されているニュースレターに必要なニュースレターのエディションを保存します。以下は、エディションテーブルのすべての列の説明です。

Id ニュースレターID タイトル説明ステータス作成場所更新日公開日コンテンツ

エディションを識別するための一意のID。

親ニュースレターを識別するためのニュースレターID。

エディションのタイトル。

エディションの説明。

ステータスを識別するために使用できます。エディションの可能なステータスには、新規、準備完了、公開済みが含まれます。

エディションが作成された日時が保存されます。

エディションが更新された日時が保存されます。

エディションが公開された日時が保存されます。

エディションのコンテンツを保存するために使用される列。

適切な制約のあるエディションテーブルは次のとおりです。

CREATE TABLE `newsletter`.`edition` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `newsletterId` BIGINT NOT NULL,
  `title` VARCHAR(100) NOT NULL,
  `description` VARCHAR(2048) NULL DEFAULT NULL,
  `status` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `publishedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_edition_newsletter` (`newsletterId` ASC),
  CONSTRAINT `fk_edition_newsletter`
    FOREIGN KEY (`newsletterId`)
    REFERENCES `newsletter`.`newsletter` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

サブスクライバーテーブル

このセクションでは、サブスクライバーを設計します テーブル サブスクライバーの詳細を保存します。サブスクライバーテーブルを使用して、グローバルニュースレターを直接トリガーできます。以下は、サブスクライバーテーブルのすべての列の説明です。

Id 顧客ID 名ミドルネーム姓メールモバイル電話アクティブ作成場所更新日

サブスクライバーを識別するための一意のID。

顧客を識別するための顧客ID。これはオプションのフィールドであり、アプリケーションが顧客とそのニュースレターを管理するように設計されている場合にのみ必要です。顧客は自分のサブスクライバーを管理できます。

サブスクライバーの名。

サブスクライバーのミドルネーム。

サブスクライバーの名前。

サブスクライバーの電子メール。

加入者の携帯電話番号。

加入者の電話番号。

サブスクライバーがアクティブかどうかを識別するフラグ。

加入者が登録された日時を保存します。

サブスクライバーが更新された日時を保存します。

適切な制約のあるサブスクライバーテーブルは次のとおりです。

CREATE TABLE `newsletter`.`subscriber` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `customerId` BIGINT DEFAULT NULL,
  `firstName` VARCHAR(100) NOT NULL,
  `middleName` VARCHAR(100) NULL DEFAULT NULL,
  `lastName` VARCHAR(100) NULL DEFAULT NULL,
  `email` VARCHAR(100) NOT NULL,
  `mobile` VARCHAR(50) NULL DEFAULT NULL,
  `phone` VARCHAR(50) NULL DEFAULT NULL,
  `active` TINYINT(1) NOT NULL DEFAULT 1,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_subscriber_customer` (`customerId` ASC),
  CONSTRAINT `fk_subscriber_customer`
    FOREIGN KEY (`customerId`)
    REFERENCES `newsletter`.`user` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `newsletter`.`subscriber` ADD UNIQUE `uq_sub_cust_email`(`customerId`, `email`);

アドレステーブル

このセクションでは、アドレステーブルを設計します顧客と加入者のアドレスを保存します。このアドレスは、ニュースレターの物理的な配信に使用できます。以下は、アドレステーブルのすべての列の説明です。

Id ユーザーID サブスクライバーID 名ミドルネーム姓モバイルメール 1行目 2行目都市州国市外局番作成場所更新日

アドレスを識別するための一意のID。

アドレスに関連付けられているユーザーを識別するためのユーザーID。

アドレスに関連付けられているサブスクライバーを識別するサブスクライバーID。

アドレスに使用される名。対応するユーザーまたはサブスクライバーから取得できます。

アドレスに使用されるミドルネーム。対応するユーザーまたはサブスクライバーから取得できます。

アドレスに使用される姓。対応するユーザーまたはサブスクライバーから取得できます。

アドレスに使用されるモバイル。対応するユーザーまたはサブスクライバーから取得できます。

アドレスに使用されるメールアドレス。対応するユーザーまたはサブスクライバーから取得できます。

住所を保存する最初の行。

住所を保存する2行目。

住所の都市。

住所の州。

住所の国。

配達エリアを識別するための市外局番。

アドレスが作成された日時が保存されます。

アドレスが更新された日時が保存されます。

適切な制約のあるアドレステーブルは次のとおりです。

CREATE TABLE `newsletter`.`address` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `userId` BIGINT NULL DEFAULT NULL,
  `subscriberId` BIGINT NULL DEFAULT NULL,
  `firstName` VARCHAR(50) NULL DEFAULT NULL,
  `middleName` VARCHAR(50) NULL DEFAULT NULL,
  `lastName` VARCHAR(50) NULL DEFAULT NULL,
  `mobile` VARCHAR(15) NULL,
  `email` VARCHAR(50) NULL,
  `line1` VARCHAR(50) NULL DEFAULT NULL,
  `line2` VARCHAR(50) NULL DEFAULT NULL,
  `city` VARCHAR(50) NULL DEFAULT NULL,
  `province` VARCHAR(50) NULL DEFAULT NULL,
  `country` VARCHAR(50) NULL DEFAULT NULL,
  `areaCode` VARCHAR(50) NULL DEFAULT NULL,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_address_user` (`userId` ASC),
  CONSTRAINT `fk_address_user`
    FOREIGN KEY (`userId`)
    REFERENCES `newsletter`.`user` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `newsletter`.`address` 
ADD INDEX `idx_address_subscriber` (`subscriberId` ASC);
ALTER TABLE `newsletter`.`address` 
ADD CONSTRAINT `fk_address_subscriber`
  FOREIGN KEY (`subscriberId`)
  REFERENCES `newsletter`.`subscriber` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

メーリングリストテーブル

このセクションでは、メーリングリストテーブルを設計します。特定のニュースレターのメーリングリストを保存します。メーリングリストは、非グローバルニュースレターをトリガーするために使用できます。サブスクライバーテーブルを使用して、グローバルニュースレターをトリガーできます。以下は、メーリングリストテーブルのすべての列の説明です。

Id ニュースレターID サブスクライバーID アクティブ作成場所更新日

ニュースレターの購読を識別するための一意のID。

ニュースレターの購読に関連付けられているニュースレターを識別するためのニュースレターID。

ニュースレターの購読に関連付けられている購読者を識別するための購読者ID。

ニュースレターの購読がアクティブかどうかを識別するフラグ。

サブスクリプションが作成された日時が保存されます。

サブスクリプションが更新された日時が保存されます。

適切な制約のあるメーリングリストテーブルは次のとおりです。

CREATE TABLE `newsletter`.`mailing_list` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `newsletterId` BIGINT NOT NULL,
  `subscriberId` BIGINT NOT NULL,
  `active` TINYINT(1) NOT NULL DEFAULT 1,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_mlist_newsletter` (`newsletterId` ASC),
  CONSTRAINT `fk_mlist_newsletter`
    FOREIGN KEY (`newsletterId`)
    REFERENCES `newsletter`.`newsletter` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `newsletter`.`mailing_list` 
ADD INDEX `idx_mlist_subscriber` (`subscriberId` ASC);
ALTER TABLE `newsletter`.`mailing_list` 
ADD CONSTRAINT `fk_mlist_subscriber`
  FOREIGN KEY (`subscriberId`)
  REFERENCES `newsletter`.`subscriber` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

ニュースレタートリガーテーブル

ニュースレターの配信を追跡するためのテーブルも必要です。このセクションでは、購読者へのニュースレターの配信を追跡するために必要な表と列を提供します。以下は、ニュースレタートリガーテーブルのすべての列の説明です。

Id ニュースレターID エディションID サブスクライバーID 送信済み配信済みモード作成場所更新日送信先配信場所

ニュースレターのトリガーを識別するための一意のID。

トリガーに関連付けられているニュースレターを識別するためのニュースレターID。

トリガーに関連付けられたニュースレターのエディションを識別するエディションID。

トリガーに関連付けられているサブスクライバーを識別するサブスクライバーID。

ニュースレターが購読者に送信されたかどうかを確認するためのフラグ。

ニュースレターが購読者に配信されたかどうかを確認するためのフラグ。

ニュースレターの配信モードは、オンラインまたはオフラインのいずれかです。

トリガーが作成された日時を保存します。

トリガーが更新された日時を保存します。

トリガーが処理された日時を保存します。

ニュースレターが配信された日時が保存されます。

適切な制約のあるニュースレタートリガーテーブルは次のとおりです。

CREATE TABLE `newsletter`.`newsletter_trigger` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `newsletterId` BIGINT NOT NULL,
  `editionId` BIGINT NULL DEFAULT NULL,
  `subscriberId` BIGINT NOT NULL,
  `sent` TINYINT(1) NOT NULL DEFAULT 1,
  `delivered` TINYINT(1) NOT NULL DEFAULT 1,
  `mode` SMALLINT(6) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `sentAt` DATETIME NULL DEFAULT NULL,
  `deliveredAt` DATETIME NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `idx_trigger_newsletter` (`newsletterId` ASC),
  CONSTRAINT `fk_trigger_newsletter`
    FOREIGN KEY (`newsletterId`)
    REFERENCES `newsletter`.`newsletter` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

ALTER TABLE `newsletter`.`newsletter_trigger` 
ADD INDEX `idx_trigger_edition` (`editionId` ASC);
ALTER TABLE `newsletter`.`newsletter_trigger` 
ADD CONSTRAINT `fk_trigger_edition`
  FOREIGN KEY (`editionId`)
  REFERENCES `newsletter`.`edition` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

ALTER TABLE `newsletter`.`newsletter_trigger` 
ADD INDEX `idx_trigger_subscriber` (`subscriberId` ASC);
ALTER TABLE `newsletter`.`newsletter_trigger` 
ADD CONSTRAINT `fk_trigger_subscriber`
  FOREIGN KEY (`subscriberId`)
  REFERENCES `newsletter`.`subscriber` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

概要

このチュートリアルでは、ユーザーを保存し、ニュースレターを管理するためのニュースレターシステムのデータベース設計について説明しました。また、サブスクライバーとメーリングリストを管理するためのデータベース設計も提供しました。

コメントを送信して、ディスカッションに参加できます。 BlogおよびPoll＆Surveyアプリケーションのデータベースの設計にも興味があるかもしれません。完全なデータベーススキーマはGitHubでも入手できます。