-
LEFT JOINにON句を使って抽出をすればINNER JOINと同じように使うこともできます。なので、開発現場によっては「LEFT JOINのみを使うこと」とルールを決めている現場もあるようです。 ただ、これは以下の理由によりあま…
-
【SQL】「ON句」の意外と知らない活用法
10.24
JOINのON句は以下のように結合条件のために普通は使うと思います。 [crayon-617945f4f3d02683014000/] それで結合後に条件を絞りたい場合は、以下のようにするでしょう。 [crayon-617945f4f…
-
【SQL】SQL設計の基本指針
10.24
基本指針 「複雑なSQL」から逃げないこと 複雑なSQLは避けたがる現場もあるかもしれません。しかし、複雑なSQLを使わないとループからのDB呼び出しの多重ループが発生するため、アプリの性能が遅くなってしまいます。複雑なSQLから逃げな…
-
【設計】「リトライ」についての考え方
10.23
リトライのユースケース バッチ処理などでどうしても失敗できない処理の場合 バッチ処理はオンライン処理に比べたら同時処理数は一定のため過負荷などにはなりにくいです。 リトライの注意点 回数の多いリトライは過負荷を生む原因になるのでやっ…
-
【DB設計】「データ保持」の考え方
10.23
デメリット データ量が増えてくると性能が低減する。 削除しないのであれば、ストレージやディスクを追加購入する必要がある。（今はクラウドなので論理的なものになるが。） しょうがないケース 以下のようなケースはそもそもデ…
-
【DB設計】日付データの持たせ方
10.23
DATETIME型で時間まで持たせる方法 基本的にこれで統一するのが一般的です。 文字列で持たせる方法 これも一つの手ですが、妥当性を確実にチェックできないので、13月だとか、32日だとか登録されるはずがないデータまで登録できてしまう…
-
【MySQL】日付型について
10.23
DATETIME型 サポートされてる時間の範囲 [crayon-617945f5003c5920241219/] create文 [crayon-617945f5003cf178476720/] insert文 [crayon-…
-
normalizeする。 [crayon-617945f50076e748830617/] id以外をキーにしたい場合 idAttributeを使います。例えば、以下の例はオブジェクトのキーを「ItemName」というものにしたい場合…
-
バックアップとレプリケーションは別物です。運用設計時は必ず併用するように設計しましょう。 バックアップ 「アプリケーションの不具合」や「ヒューマンエラー（運用者のミス）」によるデータ破損からのデータ復旧ができる。 メリット…
-
【データベース】バックアップ設計について
10.10
論理バックアップ SQLやCSVとしてDBそのものを再構成できるようにバックアップを取ること。 MySQLの場合は、mysqldump PostgreSQLの場合は、pg_dump 論理バックアップの実体はテキストな…