blog: 削除フラグって必要？
休日なので、結論の出ない軽い話題を。 DB設計の時に、場合によっては全テーブルに「delete_flag」なんていう名前でフラグを持たせることがままあります。 テーブルのデータを実際に削除せずに、「削除フラグ（delete_flag）」をONにすることで「削除したものとして扱いますよ」というフラグです。 ちなみに、実際にデータを削除することを「物理削除」、削除フラグを立てて削除したものとみなすことを「論理削除」と呼んだりもします。 この削除フラグ、特に意識せずについつい付けてしまうことが多いのですが、本当に必要なのかね・・・？というのが趣旨です。 ※恐らく日本では、ある程度の規模以上のシステム開発の常識では削除フラグは絶対必要だと考えられていますので、開発リーダーに「削除フラグ要らないんじゃないっすか」みたいなことを言ってみて一蹴されても責任は負いません。 ■削除フラグの根拠 削除フラグを
DB のスキーマ設計とかの話 - tsucchi’s diary(元はてなダイアリー)
はじめに ここ1年くらい、わりとまじめに DB 設計やってみて、うまくいったもの、失敗したものなど、いろいろ出てきました。その知見(というほどものじゃないけど)を書いてみようかなー、と思います。 僕は基本的にアプリ屋さん(+運用)なので、データモデルの綺麗さよりもアプリからの使いやすさ(+運用しやすさ)を重視してると思います。 前提 業務系のアプリケーションで、DB は MySQL を想定しています。*1。Web 屋さんとは違って、「COUNT したら返ってこない」、「ALTER TABLE が半日たっても終わらない」みたいな恐ろしいテーブルはありません。(とはいえ、データ量は GB 単位で、それなりにでかくて困ってるテーブルとかもあったりします) なお、アプリケーション更新のための停止が許されていて、スキーマの変更はある程度定期的かつ自由に可能となっています。*2 主キーについて いかな
そろそろ履歴データについて真面目に考えてみていいんじゃないの - iakioの日記
WEB+DB PRESS Vol.75の「理論で学ぶSQL再入門/履歴データとの上手なつきあい方」が面白かったと感想を書こうと思っていたらもうVol.76が出そうなのでいい加減慌てて書きます。 さてこの記事では、リレーショナルモデルが苦手とするデータ構造の1つとして履歴データを挙げています。 もしかすると「履歴データ」であるということを気づかずにデータベースの設計、クエリの記述をしたことがあるかもしれません。 この記事ではショッピングサイトの価格表を例としています。 価格表が常に現在の価格のみを扱うのであれば問題ありませんが、ある期間に価格を変えたことも価格表に含めるのであればそれは「履歴データ」となります。記事から一部引用するとこんな感じ item price start_date end_date 懸垂マシーン 18000 2010-01-01 2011-12-31 懸垂マシーン 20
私がインテグレーションテストを書く際のやり方について | 自転車で通勤しましょ♪ブログ
前回、私がRSpecを書く場合のやり方についての記事を書きました。 今回はインテグレーションテストについて書きます。 私の場合はController,Viewのテストは基本的には書かず、インテグレーションテストで済ませています。インテグレーションテストフレームワークは、 Cucumber Turnip RequestSpec FeatureSpec Steak など色々あります。以前はCucumberを使っていたのですが、現在担当しているプロジェクトを始める前に、Cucumberに不満があったので、他のやつを試そうという話になって、Steak, RequestSpec, FeatureSpecを試して、FeatureSpecにしました。Turnipはこれらを検討していた頃は有名でなかったので、試していませんが、うちの会社の他のプロジェクトでは、Cucumberの代わりにTurnipを使うよ
.NETでドメイン駆動開発～ValueObject後編～
であった。詳しくは前編を参照願いたい。 さて、ではValueObjectとして実装する例として「期間」を取り上げてみよう。データとして「期間」を取り扱う場合、通常開始と終了があり、場合によっては時刻単位まで考慮することもある。ここでは時刻は考慮せず、日付単位で開始日、終了日が設定されている「期間」をValueObjectとして実装してみるとしよう。クラス名はDateRangeとした。 1: public class DateRange 2: { 3: public DateRange(DateTime startDate, DateTime endDate) // コンストラクタでのみデータを受け取る 4: { 5: this._startDate = startDate; 6: this._endDate = endDate;
シュキーンの開発とドメイン駆動設計について｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
シュキーンの開発とドメイン駆動設計について こんにちわちわ。Underbar.phpの記事ぶりになりました@emonkakです。 本エントリでは、以前のエントリでお伝えした勤怠管理アプリケーションのシュキーンの開発について述べたいと思います。 シュキーンとは シュキーンはAndroidで動作する勤怠管理アプリケーションです。打刻はNFCタグをAndroid端末にかざすことで行います。勤怠データはAndroid端末からサーバーに送信されるので、ネットワーク環境さえあればどこからでも確認することがきます。 開発のスタート 社内向けに使っていたシュキーンを一般公開に向けて改修をするということで、開発はスタートしました。メンバーは私を含む2名で進み、リリース直前に増員があり現在は3名体制になりました。今回リリースされたものは以前のバージョンからほとんど1から書き直すことになりました。 ドメイン駆動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.yoslab.com/entry/2014/06/11/201103
美しいシューゲイザーを貼っていこう - 見る前に飛べ踊れ