Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
WebエンジニアのためのSwift言語入門 - ICS MEDIA
Mac、iPhone・iPad、そしてApple Watch。これらのApple製品上で動くアプリはObjective-CとSwiftという言語で開発できます。Swiftは2014年に発表され、他のプログラミング言語の長所を多く取り入れたプログラミング言語です。何かしらのプログラミングの経験がある開発者にはもちろん、これからプログラミングを始める人にも比較的学習しやすいものとなっています。今回はiOSアプリにおけるパーティクル表現を通して、ActionScript 3.0やJavaScriptのようなウェブ開発技術と比較しながらSwiftを始めてみましょう。 デモについて Swiftで作られたパーティクルアニメーションをiPhone 6 Plus上で動かすデモです。画面上でフリックした場所にパーティクルが発生し、時間の経過とともに色が変わっていきます。 ソースコードはGitHubで公開して
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: データの削除は非推奨
