Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
明日から使えるPostgre sql運用管理テクニック(監視編)
3. 本日のお話 ● 運用管理の 監視 に特化した話です ● 監視に重要となる考え方、観点とともに、 基本的な設定やテクニックを中心に紹介します – まずは「これだけはやっておこう」というアレコレ ● PostgreSQLを使う(使ってみたい)ことになっ たけど、よくわからなくて困っている方の手助 けになれば幸いです ● バージョンに依存した話ではありません – 機能上、バージョンを意識した話は注釈を入れてい ます 4. (ちょっと寄り道) 最近のPostgreSQL 2011 2012 2013 9.0 9.1 9.2 2010 8系 -2009 9.3 2013.9.9 に最新版となる Ver 9.3.0 リリース！ 非同期レプリケーション ホットスタンバイ SQL構文強化 同期レプリケーション UNLOGGED TABLE SQL/MED カスケードレプリケーション IndexOnl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
