本日は主にインフラの設計的なことに関して。連鎖倒産いい言い方が思いつかなかったんでこんな感じにしました(汗)要はあるサーバーのレスポンスが悪いことが原因で他の業務が遅延し、影響を受けることです。デメリット重要でないちょっとしたサービスの停止で他のシステムが止まる、などということが起こるあるシステムがハングし、適切なエラーを返さないため、いつまでも応答を待ってしまう対策エラー時の対策、障害テスト。基本正常系を前提としないこと受け取るだけ受け取って、そのトランザクションは一旦終わりにし、その後の処理は別のトランザクションで行う(キューイング)同期と非同期を分けること基本マイナス思考(どこかしらでシステムが落ちる、失敗する)で考えること(汗)他のAPIなどを使っている場合も要注意。正常に稼働しているかどうかの確認。人間の注意力を過信しすぎないこと監視ツールでのテンプレートを参考にするDB構築の中のプロセスの1つに入れるデータのバックアップ体制バックアップをしていない。コメントをキャンセルメールアドレスが公開されることはありません。※サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。以前も少し学習しましたが、今回からはサブクエリの扱い方です。異なった行の比較(年度計算など)に関して行われる自己結合をつかったものが非常に強力です。例によってここを学習しています。今まで使ってきたデータベースはMySQLがほとんどなのですが、最近少し、Postgresを触っています。今回はパスワードの設定とリモートからの接続など。正規化についていろいろ書いてきましたが、メリットもあればデメリットもあります。...Dockerでのredis活用(redisinsightなどについて)引き続きdockerネタですがredisを使ったネタに関して。redis自体は以前のエントリーでも説明しましたが、一般的なキャッシュサーバーかと思います。...集合としてのSQL今まで何度かSQLが集合ということを扱ってきました。今回はそれがよくわかる例を。実務ではあまりないと思うのですが、集合をイメージしやすい例題として、2つのテーブルが全く同じケースを考えます。