Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
【初心者向け】各OSのTCP通信チェックコマンド入門 | DevelopersIO
最新版は以下となります。 https://dev.classmethod.jp/etc/ec2-tcp-port-check-command-2018/ こんにちはコカコーラ好きの梶です。 EC2では色々なOSが構築できますよね。構築後の通信確認はどのように実施してますか？ 各OSで他のインスタンスへTCP通信確認のために、ツールをインストールしたり、ICMPなどの別なプロトコルで確認するためにSecurity Groupを一時解放していませんか？ 構築直後の状態で、簡単にTCPポート疎通確認可能なコマンドをご紹介します。 Amazon Linux,Ubuntu,Windows2012R2,CentOSについて自分も忘れやすいのでまとめてみました。 どなたかのお役に立てれば幸いです。 Amazon Linux 動作確認AMI:amzn-ami-hvm-2014.09.2.x86_64-eb
おそらく現時点でNo1 AWS本です。正確には、既にAWSを使っていて、もう少しIAMやIDS/IPSなども使おうと考えているエンジニア向け。: 自宅クラウドでAI・機械学習・CI/CD・自動化、全てやろう！
元々、メルマガ連動目的で始めた初心者・中級者向けブログでした。が、コロナによる在宅勤務が当たり前の時代に突入した2020年。会社に存在していた仕事環境が、自宅内に存在して当たり前の時代に、一気に突入することとなりました。AWSを筆頭としたクラウド環境をベースに、AI、機械学習、CI/CD、自動化等、全てが自宅で動作・操作可能です。全てが可能となるよう、自宅環境整備に役立つ内容をブログに記載していく方針とし、今後の内容に反映させていきたいと思います。 ようやく中級者向けっぽい書籍が出ました。 VPCに関する部分も、現在発売されているAWS書籍では、 一番実務に役立つと思います。 P365～IAMに関して触れていて、 MFA(多要素認証）や2015年2月に提供された 新ポリシー「IAMマネージドポリシー」の事も 記載されています。 従来のインラインポリシーとの違い、とか。 P378から外部から
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
