SQLには複数レコードから最大値/最小値を求める集約関数のMAX(), MIN()関数がありますが、そうでなく複数指定した引数のうちの最大値/最小値を求める関数を、SQL非標準ながら複数のRDBが持っています。 それがGREATEST(), LEAST()関数。 しかしこの両関数に渡した引数値にひとつでもNULLが含まれていた場合の振る舞いがPostgreSQLだけ違うので製品移行の際に注意が必要です。 RDB NULLが含まれた場合
![GREATEST(), LEAST()関数はPostgreSQLだけNULLの扱いが違う - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5d9e60a0285fef4e68267592a9425dbd8ac66875/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9R1JFQVRFU1QlMjglMjklMkMlMjBMRUFTVCUyOCUyOSVFOSU5NiVBMiVFNiU5NSVCMCVFMyU4MSVBRlBvc3RncmVTUUwlRTMlODElQTAlRTMlODElOTFOVUxMJUUzJTgxJUFFJUU2JTg5JUIxJUUzJTgxJTg0JUUzJTgxJThDJUU5JTgxJTk1JUUzJTgxJTg2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1mNDgwYmY2OTY5ZGFmNjZkNjVlNzg2NWQ3NTUzN2JhNQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5dWJhJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mY2QwYWIzMjZhNDAyNjA5ODc5OGEwMDc2OWFhYTMxZA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g44Ko44Og44K544Oq44O85qCq5byP5Lya56S-%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Def41428df8ff35ef7e4eab918eabd7a3)
信頼できるタイムスタンプがログに残っていることが障害調査の重要な手がかりとなります。 正確な時刻の確保はサーバ管理の根本ですので、時刻同期の設定はOSをインストール後に最優先で行う作業と位置づけられるものです。 基礎知識として 時刻は ハードウェアクロック とOS上の ソフトウェアクロック がともに刻んでいます。 稼働中はソフトウェアクロックだけが参照されますが、ハードウェアクロックはマシン停止時にも動き続けているので 起動時にはハードウェアクロックがソフトウェアクロックへ読み込まれます。 ネットワークから現在時刻を提供するサービス(NTP)により時刻合わせをします。 このとき、特に時刻を遅らす場合、急に遅らせる操作はしません。時刻が後ろへ飛ぶことによりログの時刻の前後関係がひっくり返る可能性があるからです。 (ログ以外のソフトウェア動作も異常を来すかも知れません) ソフトウェアクロックの
アプリケーション上でなにかエントリ(例えば記事だとかユーザだとか)を削除したとき、DB上の行は削除せず単に【削除済み】フラグを立てるだけという扱い方を 論理削除 と呼びます。 論理削除にはいろいろなメリットがあります。行削除のように関連する他テーブルへ削除が波及しないこと、エントリ復活ができること、障害時にデータ変更の経緯を追いやすくなることなどなど(デメリットもわんさかあるんですが、この記事の主旨からははずれるので別途お調べください)。 ところが論理削除の方針でDBを組んでいて困ったことはありませんか? 「 メールアドレスは一意性(UNIQUE)制約をかけたいのに、それだと削除済みのユーザと同じメールアドレスが使えないことになる 」 論理削除と一意性制約、両立はできないのか? できないと思っている方、多いと思います。実はちゃんとできます。DB製品によって実現方法がちょっと違ってくるだけで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く