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

public string[] 優技録 = { "Data Science", "Linux", "MS", "DB", "AWS", "Infrastructure", "C#", "PHP", "Python", "JavaScript"};
・基本は1→Nの順番で更新する規約を設定 ・同一テーブルでのidを利用したトランザクションはソートしてから // ユーザ間のフリマ購入のやりとりなど 爆速レンタルサーバならConoHa WING サーバはプロに全部お任せ!「仕事」に専念したいあなたにおすすめです。 ConoHa VPSで運営してま🐱 サーバの勉強がしたいあなたにおすすめ!現役エンジ …
複合主キーはどういう時利用するの? 履歴系 購入者id + 商品id + 購入日時 WordPress『wp_term_relationships』テーブル 外部テーブルのサロゲートキーを集中管理 ターゲット系 例 プッシュ通知でのお知らせ お知らせテーブル お知らせターゲットテーブル お知らせターゲットテーブルはお知らせidとお知らせするu …
とても実践的な内容で私は好き。 業務変更に強いDB設計にはテーブルの「主キーに自動採番のID(サロゲートキー, 代理キー)を設定する」こと、IDによってJOINさせること。コード(ナチュラルキー)ではないことが徹底されて書かれている。 @see 商品コードを主キーにするべきではない理由 システムの寿命はコードで決まる! (3/3) テーブル設計の理想と現実 なぜIDを主キーにするのか …
コンシューマ世界でのJOIN禁止、固定長ルールのまとめ 私 JOIN禁止の世界は知らない(1テーブルに1億以上のレコードを扱ったことがない) 原則として正規化できるものは正規化してJOINを行い、正規化する必要のないものは正規化しないスタンス 1テーブルはどんなに大きくても20カラム限界がセオリー →正規化できるのではないか、テーブルをわける 1テーブルが大きく正規化されずに開発されたサービスの保 …
基本戦略 テーブルを正規化する JOIN(INNER JOIN)を有効に活用する 非正規化でテーブルを巨大にしない すべてのテーブルを正規化することは出来ない 出来るテーブルのみ正規化する EXPLAINで計測する、INDEXが有効に動いているか確認する インデックスのデメリット SELECT性能がBtreeインデックスによって向上するが、UPDATEでINDEXが再生 …
まとめ すべてのテーブルを正規化する必要もない 正規化出来るテーブルを正規化する 正規化でNULLは許容できない NULLがないようにDB設計を行う 正規化できるテーブル「事実の集合」 集合の要素に重複がない 要素同士に順序がない NULLがない 正規化できないテーブル 履歴やグラフは正規化出来ない よくあるケース …
MySQLのデッドロック対処 おまけでギャップロック 寄稿しました。 今回はトランザクションでよくありがちなデッドロックのご紹介。 たすきがけのデッドロック よくデッドロックはなんぞや?といった時に提示されるパターンです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
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"); |
…
リレーション AとBのテーブルがあった時に、AのレコードがBのレコードにいくつかリレーション(関係)を持つかを考える。 1対1の関係 将来も1対1のリレーションであるなら、そもそもテーブルを分割する必要がない 1対多の関係 通常のリレーション playerテーブルのサトシくんはポケモンをたくさん所有しています。 更 …
正規化を行う意義 更新時に1行で済む もし正規化されていなければWHEREを利用した該当レコードについて全行更新が必要になる。 データの整合性 正規化されていると更新時に親子テーブルでデータの整合性がとれるので、データ構造が壊れない設計になる データの可読性 ER図で可視化できる、わかりやすくなる 注意 正規化は可逆的なもの 正規化されたテーブルは、非正規化されたテーブ …