タグ

DB設計に関するdencygonのブックマーク (11)

  • 論理削除が云々について - mike-neckのブログ

    今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意

    論理削除が云々について - mike-neckのブログ
  • 論理削除フラグという名の死亡フラグ - @ledsun blog

    RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか?」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職(・転属)する (売掛金の回収を諦めて)売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ

    論理削除フラグという名の死亡フラグ - @ledsun blog
  • #ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ

    名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる!! 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる

    #ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
  • AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ

    AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ
  • 開発現場ですぐに通用する"今どきの"モデリングテクニック | ウルシステムズ株式会社

    パート2では「開発プロジェクトの工程全体の中におけるモデリング」という視点から、実際のモデリングに必要な要素や具体的な作業の進め方を解説していきます。なぜそのような視点にしたのかは編で述べていますが、基的には筆者のこれまでの経験上、実際の開発現場で通用するモデリングのスキルを取得するにあたっての最短の近道だと考えるからです。これまでのモデリングに関する書籍や記事とは一味違った切り口での説明になると思いますが、どうぞ最後までお付き合いください。 "教科書に載っていない"モデリング作法とはこれまでに筆者は、データモデリングに関する数多くの書籍や雑誌/Webの記事を読んできました。それらから得た知識は、確かに実践の中で活かされてきましたが、実際のプロジェクトDB設計を担当するとなると「記事には載っていない何か」が現場では必要になったのです。世の中にある、多くのモデリングに関する書籍や記事に

    開発現場ですぐに通用する"今どきの"モデリングテクニック | ウルシステムズ株式会社
  • アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)

    毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした! この記事がすごく良かったので、触発されてブログ書く!!! developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき

    アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)
  • DSAS開発者の部屋:apache

    KLab Advent Calendar 2011 「DSAS for Social を支える技術」の10日目です。 昨日の記事 では並列数を設定する基的な方法を紹介しました。 今日は実際に DSAS for Social で利用している設定方法を紹介します。 背景 実際の並列数の設定はマシンのCPUスペックやアプリの特性(レスポンスタイムの 何割をWebサーバーのCPUを使う処理が占めているか)に応じて設定するのですが、 DSAS for Social ではアプリの負荷に応じて柔軟にWebサーバーを 追加・削除するので、CPUスペックが一定ではありません。 具体的に言えば、 Core2 世代の4コアサーバーと、Core i7世代の4コア8スレッド サーバーが Web サーバーとして利用されています。 でも、Webサーバーごとに違う設定ファイルを用意したくはありません。 なんとかできない

  • 大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック

    OSC 2011 Hokkaidoの発表で使用したスライド資料です。 弊社が「ブラウザ三国志」や「英雄クエスト」といったゲームを、PHPMySQLで構築してきた上で、身につけたノウハウや、注意すべき箇所、指針などをまとめた資料となっています。Read less

    大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
  • 分割と整合性と戦う

    え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理NTT DATA Technology & Innovation

    分割と整合性と戦う
  • Amazon CloudSearchとRDS / DynamoDBの連携を考えてみる | DevelopersIO

    データベースとは? データベースと聞いて直ぐに思い浮かべるのはリレーショナルデータベースではないでしょうか。しかし、世の中には様々な種類のデータベースが存在します。 データベースの種類例 NoSQL:DynamoDBなど GraphDBNeo4jなど ColumnDB:Redshiftなど TextSearchEngine:CloudSearchなど それぞれのデータベースには特徴があり、他のデータベースと較べて秀でている部分があります。CloudSearchは、テキスト検索エンジンとして、文字の検索に優れています。それぞれの要素は基的に文書として保管され、文書にはフィールドがあります。フィールドは、複数の値や長さを持つことができます。そして、文書は正規化(ノーマライズ:Normalize)されていません。リレーショナル・データベースと異なる部分は、文書内の文字に完全に一致しなかったと

    Amazon CloudSearchとRDS / DynamoDBの連携を考えてみる | DevelopersIO
    dencygon
    dencygon 2015/05/08
    “DynamoDBは、非常に高いスループットを保証することができるサービスです。NoSQLですから、グループ化したりソートしたり、テキスト検索することは不得意です。”
  • InfoQ: データの削除は非推奨

    垂直スケーラビリティと効果的なテストによる金融取引システムのパフォーマンスと効率の最大化 Peter Lawrey氏はJavaチャンピオンであり、Chronicle SoftwareのCEOとして、開発者を鼓舞してソリューションのクラフトマンシップを高めることに情熱を注いでいる。経験豊富なソフトウェアエンジニアとして、Lawrey氏はソフトウェア開発プロセスにおけるシンプルさ、パフォーマンス、創造性、革新性を奨励することに努めている。

    InfoQ: データの削除は非推奨
  • 1