タグ: DB設計

DBのロック順序デッドロック対策

2020年7月28日 | by 優 | にコメントを残す

・基本は１→Nの順番で更新する規約を設定・同一テーブルでのidを利用したトランザクションはソートしてから　// ユーザ間のフリマ購入のやりとりなど爆速レンタルサーバならConoHa WING サーバはプロに全部お任せ！「仕事」に専念したいあなたにおすすめです。 ConoHa VPSで運営してま🐱 サーバの勉強がしたいあなたにおすすめ！現役エンジ …

の続きを読む

RDB

Laravel5 複合主キー

2019年11月26日2019年11月28日 | by 優 | にコメントを残す

複合主キーはどういう時利用するの？履歴系購入者id + 商品id + 購入日時 WordPress『wp_term_relationships』テーブル外部テーブルのサロゲートキーを集中管理ターゲット系例プッシュ通知でのお知らせお知らせテーブルお知らせターゲットテーブルお知らせターゲットテーブルはお知らせidとお知らせするu …

の続きを読む

RDB, 読書

楽々ERDレッスン読み終わり。

2019年6月9日2019年10月3日 | by 優 | にコメントを残す

とても実践的な内容で私は好き。業務変更に強いDB設計にはテーブルの「主キーに自動採番のID(サロゲートキー, 代理キー)を設定する」こと、IDによってJOINさせること。コード(ナチュラルキー)ではないことが徹底されて書かれている。 @see 商品コードを主キーにするべきではない理由システムの寿命はコードで決まる！ (3/3) テーブル設計の理想と現実なぜIDを主キーにするのか …

の続きを読む

MySQL, RDB, チューニング

コンシューマ世界でのJOIN禁止、固定長ルールのまとめ私 JOIN禁止の世界は知らない(1テーブルに1億以上のレコードを扱ったことがない) 原則として正規化できるものは正規化してJOINを行い、正規化する必要のないものは正規化しないスタンス 1テーブルはどんなに大きくても20カラム限界がセオリー →正規化できるのではないか、テーブルをわける 1テーブルが大きく正規化されずに開発されたサービスの保 …

の続きを読む

MySQL, SQL, チューニング

SQL インデックスが効かない検索

2018年1月25日2019年9月8日 | by 優 | にコメントを残す

基本戦略テーブルを正規化する JOIN(INNER JOIN)を有効に活用する非正規化でテーブルを巨大にしないすべてのテーブルを正規化することは出来ない出来るテーブルのみ正規化する EXPLAINで計測する、INDEXが有効に動いているか確認するインデックスのデメリット SELECT性能がBtreeインデックスによって向上するが、UPDATEでINDEXが再生 …

の続きを読む

RDB, システム設計

データベース設計正規化とNULL

2018年1月21日2019年1月25日 | by 優 | にコメントを残す

まとめすべてのテーブルを正規化する必要もない正規化出来るテーブルを正規化する正規化でNULLは許容できない NULLがないようにDB設計を行う正規化できるテーブル「事実の集合」集合の要素に重複がない要素同士に順序がない NULLがない正規化できないテーブル履歴やグラフは正規化出来ないよくあるケース …

の続きを読む

MySQL, SQL, トラブルシューティング

MySQL デッドロック対処

2017年12月4日2019年1月21日 | by 優 | にコメントを残す

MySQLのデッドロック対処おまけでギャップロック寄稿しました。今回はトランザクションでよくありがちなデッドロックのご紹介。たすきがけのデッドロックよくデッドロックはなんぞや？といった時に提示されるパターンです。

CREATE TABLE a_table(
	a_id       INT UNSIGNED PRIMARY KEY,
	point      INT UNSIGNED,
    value      VARCHAR(255)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO a_table(a_id, point, value) VALUES
	(1, 100, "a");
	



CREATE TABLE b_table(
	b_id       INT UNSIGNED PRIMARY KEY,
	point      INT UNSIGNED,
    value      VARCHAR(255)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;


INSERT INTO b_table(b_id, point, value) VALUES
	(1, 100, "a");

CREATE TABLE a_table(

a_id INT UNSIGNED PRIMARY KEY,

point INT UNSIGNED,

value VARCHAR(255)

)ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO a_table(a_id, point, value) VALUES

(1, 100, "a");

CREATE TABLE b_table(

b_id INT UNSIGNED PRIMARY KEY,

point INT UNSIGNED,

value VARCHAR(255)

)ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO b_table(b_id, point, value) VALUES

(1, 100, "a");

…

の続きを読む

MySQL, SQL, SEノウハウ

中間テーブル関連実体 intermediate table

2017年7月26日2019年1月25日 | by 優 | にコメントを残す

リレーション AとBのテーブルがあった時に、AのレコードがBのレコードにいくつかリレーション(関係)を持つかを考える。 1対1の関係将来も1対1のリレーションであるなら、そもそもテーブルを分割する必要がない１対多の関係通常のリレーション playerテーブルのサトシくんはポケモンをたくさん所有しています。更 …

の続きを読む

RDB, SEノウハウ, システム設計

RDB 正規化

2017年5月20日2019年5月20日 | by 優 | にコメントを残す

正規化を行う意義更新時に1行で済むもし正規化されていなければWHEREを利用した該当レコードについて全行更新が必要になる。データの整合性正規化されていると更新時に親子テーブルでデータの整合性がとれるので、データ構造が壊れない設計になるデータの可読性 ER図で可視化できる、わかりやすくなる注意正規化は可逆的なもの正規化されたテーブルは、非正規化されたテーブ …

の続きを読む

優技録

タグ: DB設計

DBのロック順序デッドロック対策

Laravel5 複合主キー

楽々ERDレッスン読み終わり。

コンシューマでJOIN禁止, 固定長DBまとめ

SQL インデックスが効かない検索

データベース設計正規化とNULL

MySQL デッドロック対処

中間テーブル関連実体 intermediate table

RDB 正規化