データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
DB論理設計のノウハウ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DB設計の概要を簡単におさらいした後、論理設計について主にまとめていきます。 DB設計の全体手順のおさらい DB設計は、大きく論理設計と物理設計に分けられます。 論理設計 概念スキーマを定義します。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 物理設計 論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決めます。 テーブル定義 インデックス定義 ハードウェアのサイジング ストレージの冗長構成決定 ファイルの物理配置決定 テーブルの構成要素のおさらい 行と列 行(レコード)：横のデータの組 列(カラム
変更履歴を持つテーブルの設計 - Qiita
ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser
DBのCRUDでUとDは必要ないという話を聞きましたが具体的にどう実装するの？
"CRUD is Dead"なんて言われてる方もいらっしゃるようでCRUDのUとDを禁止する流れが存在するようです。 以下のようなサイトでも言われているように、CRUDのUとDを利用せずデータをログのように扱う方法は関連するデータ（特に履歴）が失われないために好感が持てました。 http://tanakakoichi9230.hatenablog.com/entry/6715376804 http://qiita.com/Jxck_/items/156d0a231c6968f2a474 http://mike-neck.hatenadiary.com/entry/2015/03/24/231422 現在MySQLを利用してウェブサービスを作成しようと考えているのですが、実際にUとDを利用しないDB設計をするにはどうすれば良いのかというところでつまづいてしまいました。 自分で考えたものは5つ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Glue（分析用データ抽出、変換、ロード (ETL) ）| AWS
