WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！ - Qiita
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離
データベース設計の際に気をつけていること - 食べチョク開発者ブログ
皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。
SQLアンチパターンもりもりDBを設計しよう！ - Qiita
概要 名著SQLアンチパターンを読み終えたので、それの復習のために悍ましいデータベースを作ろうと思った。 まず前半では、SQLアンチパターンを意図的に盛り込み、目も当てられない酷い設計をします。 そのあとリファクタリングを行なったER図に書き直していきます。 なお、真面目に書くと参考書の丸写しになってしまうので、この記事は アンチパターンもりもりのER図を見て嫌悪感を学習し、設計に役立てようという趣向のもと、詳しい説明は省きます。 とても良い本なので読んでください。 想定するシステムの概要と状況 目的において適切かはわかりませんが、とりあえず考えることの多い”お金”を扱うシステムを想定してみます。 私はブラックジョークが好きなので、今回は「ちょっと怖い金融屋さんが使う債務者管理システム」のER図を設計してみようと思います。 ざっくりした要件 債務者を登録でき、プロフィールを入力できる。 債
ゲームエンジニアのためのデータベース設計
GameServerDevelopers Vol.1 https://gsdevelopers.doorkeeper.jp/events/42497
1日に100万レコード増える場合のテーブル設計
MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
ソーシャルゲームのためのMySQL入門その２ | BLOG - DeNA Engineering
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第２弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ＆読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBMS in Action
データベース設計の煩雑な作業を自動化する「ERMaster」