論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
DBコマンド横断比較リファレンスを作りました - clock-up-blog
横断的にDB操作の類似コマンドを探すためのサイト 例えば MySQL を知っている人が 新しく他のデータベース、例えば Oracle を学習する際に MySQL でいうところのアレは Oracle ではどういうコマンドなんだろう という感じに情報を探す場面が多くあります。 そういう類の情報を探すときに役に立ちそうなリファレンスサイトを作りました。 xref.jp xref.jp - Database 追記: コンテンツ増やしました yum, apt-get, rpm 等々の横断比較リファレンス - clock-up-blog ソースコード GitHub に上げてあるので興味ある人は見てみると良いです。 kobake/xref.jp · GitHub PHP で書いてます。すんごい汚いです。謙遜じゃなくて本当に。 プルリク歓迎。 機能 マトリクス方向の切替 比較表の見出しの向きって、その組み
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
QuickKnowledge Return
いやー・・・本当に情報が少なくて苦労した。というか現在進行形で苦労してます。表題の通り、MySQLのストアドプロシージャ/ストアドファンクションの件なのですが、oracle触っているときも、db2触っているときも、「管理が複雑になるから」ともっともらしいことをいって避けていた道なんですけど、なんとなくわかったところで、「あ、これ結構つかえるじゃん？」と思ってきた。まあ、たしかにプロシージャ側がデータベースサーバサイドで動くわけなのでアプリケーションとの比重を考える必要があるかと思うけど、phpとでもjavaでもアプリケーション視点で考えてみれば、小難しいこと考えなくてもよくなるので、パラメータ渡したら期待した結果が戻ればそれで良いわけでSQLでの過程なんてどーでも良いわけだ、またある意味アプリケーションのプログラムと、ストアドプロシージャは分離されているので、細かい計算ロジックをストアドプ
リレーションの正規化 - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2023年9月） ほとんどまたは完全に一つの出典に頼っています。（2023年9月） 出典検索?: "関係の正規化" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL 関係の正規化（かんけいのせいきか）は、関係データベース (リレーショナル・データベース) において、関係（リレーション）を正規形と呼ばれる形式に準拠させることにより、データの一貫性の維持と効率的なデータアクセスを可能にする関係設計を導くための方法である。正規形には様々なものが存在するが、いずれにせよ、正規化を行うことにより、データの冗長性と不整合が起きる機会を減らすことができる。 多くの関係デ
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
SQL入門
あなたがSQLの初心者であれ、 SQLをちょっと復習したいデータ ウェアハウス業界の経験豊かな人であれ、いいところに来られました。この SQL教材のサイトは、よく使われる SQL コマンドが掲載してあります。このサイトは以下のように分かれます。 - SQL コマンド: SQL がどのように保存、読み込み、又はデータベース内のデータ処理に使われること。 - テーブル処理: データベース内のテーブル作成にSQL がどのように使われること。 - SQL プログラミング: 当該教材に提示される SQL プログラミングを示すページ。 各コマンドについては、あらかじめ、当該プログラミングを示し、説明します。それから、そのコマンドの使い方をよく理解させるように、例を一つ挙げます。このサイトにおけるすべての教材を読み終えたとき、 SQL プログラミングについて、大まかな理解ができるはずだと思います。 そし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLのバックアップ＆リストア手法その1