論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
論理削除フラグという名の死亡フラグ - @ledsun blog
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
SQL: ナイーブツリーと閉包テーブルモデル - CUBE SUGAR CONTAINER
今回のエントリは以前かいた SQL のアンチパターン「ナイーブツリー」に関する記事の続き。 blog.amedama.jp 再帰クエリをサポートしていない RDBMS で再帰的な構造のスキーマを作りたいときの解決策のひとつとして閉包テーブルモデルを扱う。 使った環境は次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.4 BuildVersion: 15E65 $ mysql --version mysql Ver 14.14 Distrib 5.7.12, for osx10.11 (x86_64) using EditLine wrapper 下準備 まずは下準備として MySQL にデータベースを作るところまで。 今回使ったのは Mac OS X なので MySQL は Homebrew でインストールする。 $ b
第5回 SQLで木構造を扱う～入れ子集合モデル （1）入れ子集合モデルとは何か | gihyo.jp
はじめに 木構造と呼ばれるデータ構造の一種があります。1つのルート（根）と呼ばれるノードを始点として、（通常）複数のリーフ（葉）と呼ばれるノードまでを経路で結んでできるデータ構造です。その名のとおり自然界にある「木」の構造ですし、学校時代、確率の授業で樹状図を書いた経験のある人もいるでしょう。 この構造は、私たちの周囲にとてもたくさん存在します。家系図や組織図も木ですし、IT関連の例では、ヒープやRDBのインデックス、ディレクトリ（フォルダ）によるファイルシステムやXMLも木構造です。Webの掲示板でも、最初の書き込みをルートとしてそれに対してコメントがつけられ、そのコメントにまたコメントがつけられるというプロセスで木構造を形成します。ここでは1つの書き込みがノードになります。 このように、IT技術と木構造は切っても切れない関係にありますし、多くの分野で応用されてもいるのですが、実は長い
2012年05月: プログラミングが好き！
プログラミング好きが、プログラミングのためのソフトウエア開発周辺の興味ある分野を勉強する記録。プログラミング言語、IT、ICT、情報処理技術、設計技法、数値計算、データベース、システム、SCM、画像処理、開発環境、ツールなどなど。 『アナリシスパターン-再利用可能なオブジェクトパターン』が難解なので、UMLの記法で図を書き換えながら自分なりに理解して行く勉強会の第一回目です。 2章の前半部分。パーティアナリシスパターンは比較的分かりやすいパターン。何度も類似の組織階層などをクラス化あるいはデータベースで扱って来ているので漠然と似たような構成は考えたことがある。例も身近。図の書き換えの練習にもなる。 型図の書き換えにはAstah*Professionalのクラス図を使いました。 「図2.1 アドレス帳の初期モデル」 これはよくある図。ちなみに、元の型図では集約は書かれていないが「(0..1)
ナイーブツリー - Strategic Choice
ナイーブツリー（Naive Trees, 素朴な木） どういうこと？ 【したいコト】 階層（ツリー状）構造をテーブルに格納します。階層構造の代表例には、組織図や掲示板のスレッドなどがあります。 【やらかしたコト】 自分の親を格納する列を用意します。この列は、自分のテーブルに外部キーを設定します。このような設計を「隣接リスト（Adjacency List）」とも呼びます。 どうしてヤル？ 隣接リストは、階層的なデータの格納に用いられる、最も一般的な設計です。 どうしてダメ？ 階層の検索がやりにくい 階層の深さに制限のないSQLが書けません。 アプリケーション側に任せるしかありませんが、パフォーマンスに問題が発生します。 階層のメンテナンスがやりにくい サブツリー全体を削除する場合、すべての子孫を特定するために複数回クエリを実行し、最下層から順番に子孫を削除する必要があります。この順番を守らな
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをまとめた章を用意したので、チェックポイントだけ知りたい方は最後だけ見ていただければと思います。 DB論理設計の流れ DB論理設計は以下のようなステップで進めていきます。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 以下では各ステップごとに章を
アーキ部：テーブル設計をやってみよう！ - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした！ この記事がすごく良かったので、触発されてブログ書く！！！ developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき
リレーショナルデータベースの仕組み (3/3) | POSTD
データマネージャ このステップで、クエリマネージャはクエリを実行するので、テーブルとインデックスからデータを取得する必要があります。そこでデータマネージャに対してデータを取得するよう要求するのですが、ここで次の2つの問題が発生します。 リレーショナルデータベースはトランザクションモデルを使用しています。この場合、「いつでも・どんなデータも取得できる」というふうにはいきません。どこか別の場所で、ここに格納されているデータを同時に使用したり更新したりしている可能性があるからです。 データの取得は、データベース内で実行する処理の中で最も時間のかかるもの です。従ってデータマネージャはそれを見越して、メモリバッファにデータを取得しておき、それを保持しなければなりません。 このセクションでは、リレーショナルデータベースがこの2つの問題にどう対処しているかを説明します。なお、データマネージャがデータを
100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す | POSTD
100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す MySQLはNoSQLよりも優れています。Key-ValueストアといったNoSQLのユースケースを考えてみると、パフォーマンスや使いやすさ、安定性の点でMySQLの方が合理的です。MySQLには、オペレーションや障害に関することからレプリケーションや異なる使用パターンまでと、多くのオンラインマテリアルが用意されおり、堅実なエンジンです。こういった理由から、比較するまでもなく、MySQLは最近のNoSQLエンジンよりも優れていると言えます。 ここ最近では、NoSQLエンジンが主流になってきています。多くの開発者が、MongoDBやCassandra、Redis、HadoopといったNoSQLエンジンをアプリケーション構築の第一候補としており、それらが全て昔からのSQLエンジンを上回
Amazon CloudSearchとRDS / DynamoDBの連携を考えてみる | DevelopersIO
データベースとは？ データベースと聞いて直ぐに思い浮かべるのはリレーショナルデータベースではないでしょうか。しかし、世の中には様々な種類のデータベースが存在します。 データベースの種類例 NoSQL：DynamoDBなど GraphDB：Neo4jなど ColumnDB：Redshiftなど TextSearchEngine：CloudSearchなど それぞれのデータベースには特徴があり、他のデータベースと較べて秀でている部分があります。CloudSearchは、テキスト検索エンジンとして、文字の検索に優れています。それぞれの要素は基本的に文書として保管され、文書にはフィールドがあります。フィールドは、複数の値や長さを持つことができます。そして、文書は正規化（ノーマライズ：Normalize）されていません。リレーショナル・データベースと異なる部分は、文書内の文字に完全に一致しなかったと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLで木と階層構造のデータを扱う――入れ子集合モデル
分割と整合性と戦う
InfoQ: データの削除は非推奨