タグ

設計に関するabbey_rita_sadyのブックマーク (6)

  • [J] テーブル構造を調べてて、そのときのメモ - Jamz

    特に、お題はなく、タラタラと検索していたときのクリップ。 ツリー構造を表現するのが難しい 再帰的に抽出するのがミソ。 PHPMySQLでツリー構造を扱うツリー構造は昔からあるものなので、当然ながらそれを扱うアルゴリズムもできあがっているはずです。そこでググッてみたのですが、なかなかきちんと説明したものが見あたらない。どうも「RDBでツリー構造を扱う」というのが、ひとつの壁みたいです。おきらくたぬきの次のへそ CakePHP には実装済みのライブラリ (CakePHP ではビヘイビアと呼ぶらしい) がある模様。 CakePHP1.2でツリー構造(Tree Behavior)を使うCakePHP1.2になって、ツリーデータをテーブル上に表現するという、モデルにツリー構造を扱うモジュールを追加するだけで、容易にツリー構造を扱える機能が付加された。モデルに決められたデータ構造を扱わせることから、

  • データベース大得意の方に質問します。 あなたの商品マスタの考え方を教えてください。…

    データベース大得意の方に質問します。 あなたの商品マスタの考え方を教えてください。このフィールドは必須だろ。 商品の内容に応じてテーブルは分けたほうがいい。いや全ての商品は一つのテーブルで管理した方がいいだろ。 とか何でもOKです。参考になるページや考え方を教えてください。

  • テーブル設計について - OKWAVE

    テーブル設計において、マスタ、色マスタ、素材マスタの組み合わせを制御する方法について質問があります。 ご教授お願いします。 マスタ(スニーカーA、スニーカーB、サンダルA・・・) 色マスタ(赤、青、黄色、黒・・・) 素材マスタ(皮、ビニール、木・・・) 上記3マスタがあるとします。 受注システムにおいて、マスタを選んだ際に、 組み合わせとして可能な「色(色マスタより)」、「素材(素材マスタより)」だけを選択させたいという仕様があります。 それらの組み合わせを制御するために、 下記画面の様な「組み合わせマスタ保守」を用意しようと思います。 :スニーカーA ---------------------- 「選択可能色」  「選択可能素材」 黒        皮 赤 上記により受注画面においては 「スニーカーA」を選んだ時点で、色は(黒or赤)、素材は(皮) という選択しか出来なくなり

    テーブル設計について - OKWAVE
  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

  • 美しい設計の追求(113~119日)

    今回のテーマは、シンプルで、美しい設計の追求である。ソフトはハードに比べ、一見変更が容易に見える面があり、絶えず変更追加がなされる。しかも長期にわたって使われるだけに、当初からしっかりした美しい設計がなされていないと修正に伴う事故が発生しやすくなり、保守費も増えてしまう。 最近は短納期が増えてきたこともあり、基設計に十分に時間をかけずに先を急ぎ、「まずいところは後から修正するしか仕方がない」と考える人が散見される。だが、これは大きな誤りである。たとえ時間がかかってでも、まずは徹底的に基設計を行い、しっかり土台を固めてから先に進むという王道を歩まなければならない。 プログラム構造、基となるデータベースやテーブルの構造、プログラム制御方式、サブシステム間インタフェース、マン-マシン・インタフェースの基画面、基的な操作方式などは最初に必死に考えておかないと、後で大変苦労することになる。

    美しい設計の追求(113~119日)
  • デスマーチ撲滅への「飛躍」なるか--大手SI事業者、外部設計書の記述を標準化

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます デスマーチはデスマッチになりやすい――。SI業界でよく言われることだ。しかし、そのデスマーチを撲滅するための即効薬は、いまだ存在しない。そうしたなかで、デスマーチを撲滅するための「小さな一歩だが、大きな飛躍」と関係者から期待されている文書類が公開された。 NTTデータなど大手SI事業者6社が2006年4月から共同で立ち上げた「実践的アプローチに基づく要求仕様の発注者ビュー検討会」(発注者ビュー検討会)の第1弾の成果物がこのほどウェブで公開されたのである。同検討会には、NTTデータのほか、富士通NEC、日立製作所、構造計画研究所、東芝ソリューションの計6社が参加している。 発注者ビュー検討会は、情報システムの仕様について、ユーザー企業に

    デスマーチ撲滅への「飛躍」なるか--大手SI事業者、外部設計書の記述を標準化
  • 1