第11週コードセグメント/Instagramアーキテクチャ設計

Instagramのすべての機能とプロトタイプが完了しました.
バックエンド開発者として、データベースのアーキテクチャを設計する必要がある場合は、どのようにアーキテクチャ設計を行いますか?
パターンとは?
1.パターンは、データベース構造および制約のグローバル詳細を記述するメタデータの集合です.
2.パターンは、データベースを構成するデータオブジェクト(Entity)、属性(Attribute)、リレーションシップ(Relationship)、およびデータ操作時にデータ値が持つ制約などについての全面的な定義である.
3、モードはユーザーの観点から外部モード、概念モード、内部モードに分けられる.

リレーショナル・データベースのリレーションシップ

リレーショナル・データベースは、データ間の関係を確立できることからリレーショナルと呼ばれます.
この関係は2つのデータが相互に関連している場合に確立でき,3つの関係がある.
一対一
一対多(1:n):一方が複数(親子関係)
親は何人かの子供を持つことができて、子供は1人の親しかいません
マルチペアマルチ(n:m):両方とも複数あります

𕼧代表鍵pk(Primary Key)外来鍵fk(Foreign Key)

pkとfkはテーブルの必須要素であり、すべてのテーブルに1つ以上のテーブルが含まれている必要があります.

Primary key

pkは各行を一意に識別する役割を果たし、各テーブルは1行しか定義できない
固有インデックスの自動生成
韓国国民を識別できる代表キーで身分証明書番号が存在する

foreign key

テーブル間の関係を表す外部識別子キー
2つのテーブル間の親、子関係->依存関係が必要な場合は、fkとして指定して相互参照します.
fkを定義したテーブルはサブテーブル
参照されるテーブルは親テーブルと呼ばれ、親テーブル参照カラムに存在する値のみを入力できます.
fkを作成するには、親テーブルにpkを作成する必要があります.
テーブル間の関係を確立するときに、代表キーを使用して関係を確立します.
例えばINSの投稿とコメントの関係
コメントテーブルのコラムには、次のデータがある可能性があります.
id(pk)-コメントid
userid-作成者ID
コメント-コメント内容
作成日
ここでは、このコメントがどのような文章に書かれているかについての情報が必要です.
id(fk)-後id
これは外来語と言います
ここで、post idはpostテーブルのプライマリ・キーです.
この代表キーをコメントテーブルの外来キーに設定して関係を築くことができます

シナリオの実装方法

シナリオを設計する際には、実装する機能に基づいて大きな区分を行います.
そこに必要なプロパティを考慮して実装できます

Instagramの機能を大きく3つに分けて
1.INSを使用するプレイヤー-他のプレイヤーに注目し、他のプレイヤーからのフィードバックを得ることができる
2.Postをアップロードし、Post内にhashtagを記入し、多くのユーザーに視聴させることができる
3.アップロードした投稿に「いいね」や「伝言」を押してユーザー間のコミュニケーションをとる

シナリオ設計

まず彼らの関係を考えてから書く.

プレイヤーと注目者の関係

user : follow = n:m
プレイヤーは複数の人に注目できる
プレイヤーが注目している人も複数の人に注目できます
まずユーザテーブルを作成し,ユーザテーブルを識別する一意のキーをidに設定する.
注目関係を貯めるテーブルを作ることもできます.

プレイヤー-注目-プレイヤー形式の登録表
follow idは私の注目する人を保存します
follow idに私に注目している人を保存します
両方のマスターはユーザーであり、その情報はユーザーテーブルにあります.
プレイヤーテーブル上のpkをそれぞれのfkに入れればよい.

記事とラベルの関係

Post : Hashtag = n : m
1つの文章に複数のラベルを付けることができます
1つのラベルに複数のpostを存在させることができる

マルチペアマルチリレーションの作成にはjoinテーブルが必要です
postのidとhashtagのidをfkで参照

なぜ「89 join」テーブルが必要なのか

postがjoinテーブルのないテーブルに存在し、hashtagがフィールドとして存在する場合、複数のラベルは配列の形で存在し、1つのラベルを検索するためには、すべてのラベルが過去に検索される必要があります.
データを別々に関係を設定し、fkを使用してラベルを検索するだけで、必要なラベルが見つかるのでjoinテーブルが必要です.
-->データ実装方式が効率的ではないと判断したため、NoSQLが出現した

文章と評論の関係

Post : Like = 1 : n
Post : Comment = 1 : n
一つの文章にはいくつかの称賛がある.
1つのコメントは1つの投稿しか押すことができません
1つの文章にはいくつかの評論がある.
1つのコメントは1つの投稿にしか書けません

post commentとpost likeは一対多の関係であるため、postテーブルには2つのテーブルの情報は必要ありません.
必要に応じてその文章の情報を参照すればよい
post commentとpost likeのuser idはpostのuser idとは異なり、コメントをクリックした人のIDがいい人のIDです
ユーザーと記事の関係
user : post = 1 : N
1人のプレイヤーが複数のpostを書くことができます
1つの文章は1人のプレイヤーだけが書くことができます.
大きなフレームを設定して、残りの考慮すべき関係を考えて、それをつなぎ合わせればいいのです.

Table users {
  id int [pk, increment] // auto-increment
  userId varchar
  password varchar
}

Table follow_following {
  id int [pk, increment] // auto-increment
  follow_id int
  following_id int
}

Table post {
  id int [pk, increment] // auto-increment
  img blob
  content varchar
  created_at timestamp
  total_like int
  total_comment int
  user_id int
}

Table hashtag {
  id int [pk, increment] // auto-increment
  name char
}

Table post_hashtag {
  id int [pk, increment] // auto-increment
  hashtag_id int
  post_id int
}

Table post_comment {
  id int [pk, increment] // auto-increment
  comment varchar
  created_at timestamp
  user_id int
  post_id int
}

Table post_like {
  id int [pk, increment] // auto-increment
  created_at timestamp
  user_id int
  post_id int
}


Ref: "users"."id" < "follow_following"."follow_id"

Ref: "users"."id" < "follow_following"."following_id"

Ref: "post"."id" < "post_hashtag"."post_id"

Ref: "hashtag"."id" < "post_hashtag"."hashtag_id"

Ref: "post"."id" < "post_comment"."post_id"

Ref: "post"."id" < "post_like"."post_id"

Ref: "users"."id" < "post"."user_id"

Ref: "users"."id" < "post_comment"."user_id"

Ref: "users"."id" < "post_like"."user_id"

リファレンス
dbdiagram