lynx   »   [go: up one dir, main page]

タグ

DB設計に関するatsushifxのブックマーク (7)

  • 履歴データテーブルとの向き合い方_PHPerKaigi2024

    PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222

    履歴データテーブルとの向き合い方_PHPerKaigi2024
    atsushifx
    atsushifx 2024/03/09
    スライドに参考資料へのリンク付き
  • アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey

    はじめまして。そーだい(@soudai1025)です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化

    アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
  • Railsでの区分値の扱いについて考える | Webシステム開発/教育ソリューションのタイムインターメディア

    Railsでの区分値の扱い、皆様どのようにしておられるでしょうか? 区分値とは、例えば性別情報(1: MALE, 2: FEMALE)とか、服を扱っているシステムの場合は商品種別(1: LADIES, 2: MENS, 3: KIDS)の事を指します。 私は区分値情報をDBに保存しておこうか、アプリ側でのみもっておこうか、毎回悩まされます。 区分値をDBに保存しておくと、外部キー制約もつけられるしActiveRecordでも扱いやすいといったメリットがあります。 しかし、アプリとDB両方に区分値情報を持っているとデータの二重管理になってしまいます。 DB側の区分値とアプリ側の区分値がい違ってる! なんていう事態も発生します。 ならば、いっその事DBに保存するのはやめて、区分値情報をアプリ側にのみ持っていた方がよいのでは、というのが最近の私の考えです。 今回はRailsで区分値を扱う方法に

    Railsでの区分値の扱いについて考える | Webシステム開発/教育ソリューションのタイムインターメディア
    atsushifx
    atsushifx 2014/01/06
    いわゆるデータベースでのコード化した属性の扱いについて。記事ではRailsだけど他の言語やフレームワークでもデータベースとアプリでの二重化は発生しうるリスク
  • IDの設計についてのさらに突っ込んだ議論

    今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり(ブログ書いてないで原稿書けよ>俺)であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で

    IDの設計についてのさらに突っ込んだ議論
    atsushifx
    atsushifx 2013/12/10
    IDというかコードという気がする。学籍番号、郵便番号、電話番号といった昔からのコードは意味づけがあるから管理が大変。Railsとかのサロゲートキーはそのたけの現実的な解。ただし、きちんと正規化しないとあとで問
  • その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント

    最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い!!絶対にだ!!」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの

    その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
    atsushifx
    atsushifx 2013/12/01
    DBエンジニアとか設計をするなら当たり前の話。NoSQLは個人認証のような、正規化がほとんど必要ないけど大量のデータを裁く必要のあるデータを使うための技術だから使いどころが違う。
  • astahの品質スイートプラグインとSVNプラグインが凄い - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    astahの品質スイートプラグインとSVNプラグインが凄い - プログラマの思索
    atsushifx
    atsushifx 2012/11/07
    Gitプラグインもほしくなる。
  • Jiemamy プロジェクト日本語トップページ - OSDN

    Jiemamy Projectは、データベースの進化的設計を実現します。 このプロジェクトは「Jiemamy開発モデル」と呼ばれる開発方法論を策定・提唱・普及し、またその実現を補助するプラットホームとして、関連ソフトウェアをオープンソースソフトウェアとして提供します。

    Jiemamy プロジェクト日本語トップページ - OSDN
    atsushifx
    atsushifx 2008/05/08
    DB設計でアジャイルするためのeclipseプラグイン
  • 1
Лучший частный хостинг