タグ

modelingとrailsに関するyuguiのブックマーク (12)

  • 【Rails関西】Rails屋からデータモデリングに対する回答 - プログラマの思索

    1/20に開かれた第6回RubyOnRails関西へ行ってきた。 場所は神戸電子専門学校。目の前にオランダ館、風見鶏館などの異人館があり、華やかな場所でした。 このたびの発表の中で最も興味を引いた講演が「やさしいRailsの育て方」(by 西和則さん)。 講演内容は、Railsでもテーブル設計をきちんと考えましょう、ということなのだが、それは昨年8月の渡辺さんの指摘に対する回答になっているように思う。 【1】RDBのテーブル設計におけるアンチパターン Railsをやっていると、例えば、下記のアンチパターンに囚われてしまう。 1・無限FK地獄や列破綻 テーブルに他テーブルの外部キーをどんどん持たせると列が増えていく。 西さんの例では、社員テーブルに派閥1、派閥2のカラムを増やしていた。 2・フラグステータスとバタフライ効果 「北京で蝶が羽ばたくとニューヨークで嵐が起きる」がその意味だが、「小

    【Rails関西】Rails屋からデータモデリングに対する回答 - プログラマの思索
  • Using DBDesigner to generate Rails files | Bill Katz

    An occasionally updated repository of thoughts, past work, and links. Topics include programming, web ventures, and writing. dbmodel is a tool to generate Rails files (models, scaffolds) from a free graphic database design tool, DBDesigner 4. You can create tables in DBDesigner, specify table relations, synchronize the model with a MySQL database, and then use dbmodel to automatically generate cod

    yugui
    yugui 2006/10/13
    DBDesignerからrailsの定義を作成
  • 関数従属性は多重度に先行して認識される - 設計者の発言

    「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるORマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次TTMレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Rails格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ

    関数従属性は多重度に先行して認識される - 設計者の発言
  • 【感想】RubyOnRails 勉強会@関西とデータモデリング - プログラマの思索

    デスマーチ・プロジェクトに束の間の休日ができたので、RubyOnRails 勉強会@関西に初参加してきた。 Ruby勉強会@関西と同じく、女子学生や女性エンジニアも多くて、華やかな雰囲気で、講演も甘辛だった。 僕はRubyOnRails初心者なので、聞きやすかった。 聴講の目的は、もちろん渡辺さんの「アジャイルにデータモデリング」。 「何故、RubyにDOAの第一人者の渡辺さんがいるの?」みたいな。 【1】RubyOnRailsに、複合キー(複数の識別子)を持つテーブルはない!? 渡辺さんのお話は、業務システムとデータモデリングの関係から始まり、テーブルの項目の関数従属性の説明と演習まで、というとても初心者向けの講義。 懇親会で業務に携わっていると言うエンジニアの女性が、 「私はRailsのインストール方法も知らない初心者だが、渡辺さんが話した関数従属性や正規化の話はとても基的な話です」

    【感想】RubyOnRails 勉強会@関西とデータモデリング - プログラマの思索
  • L'eclat des jours(2006-06-26)

    _ まとめ 良くわからなくなったのでまとめてみた。わかる粒度が名前を知ってるだけ、概念を理解している、実際に利用したまでばらけているので、嘘八百のような気もする(というか、嘘は確実にある)。 こういうときにマインドマップってのを使うんだろうか? EA(全体統合) BA …… プロセス DA …… データ AA …… 制約 TA …… 実装 DOA(AS IS重視)—フラット—物理モデル—ボトムアップ まずモノ(エンティティとリレーション) 検証手段:エンティティの整合性 思考法:join 抽象的  T字型派……純粋抽象派(ここに含めるべきではないのでは) ↑   伝統派……業務分析 ↓   TH派……帳票上のエンティティ 具象的  はぶ派……UI(Webのページ、帳票など)上のエンティティ+業務フロー (頂いたコメントを元に修正:7/1) 伝統派……業務分析 TH派……帳票上のエンティティ

  • 考えさせられる - yojikのlog

    RubyKaigi2006 RESTのPOST,GET,PUT,DELETEとDB(というかリソース)のCRUDの類似。Webアプリケーションにおける殆どの操作は、リソースのCRUDに対応させることができる。*1 実際のアプリのレベルに落として考えると、例えばユーザをグループに追加する際に、ユーザコントローラに対して「グループに加入させよ」メッセージを送る*2のではなく、メンバシップコントローラに、ユーザ-グループ間のメンバシップをCREATE(REST的にはPOSTで依頼)してもらう事になる。*3。 上記を徹底すればWeb(アプリ|サービス)が、外部からDBのように扱えるようになる。多分、この話がActiveResourceに繋がる。(のだと思う) なんか学ぶべき点が多そうです。 あと個人的には、DBのように扱うためには、ユーザ(や他のアプリ)との対話の中で、適切な単位でCRUDを纏め上

    考えさせられる - yojikのlog
  • 複雑さに金が落ちる時代は本当に終わるのか? - アンカテ

    RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース

    複雑さに金が落ちる時代は本当に終わるのか? - アンカテ
    yugui
    yugui 2006/06/22
    はぶさんの提起する問題への素晴らしい分析。「向上しているとは言っても、私が今持っている「業務」のレベルの複雑さに対応できるものではない。ただ」。そうか、ABDはその直感的分析が通用する上限を押し広げるんだ
  • http://capsctrl.que.jp/kdmsnr/diary/20060620.html

  • RailsとABDとCRUDとワークフロー - moroの日記

    羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと=イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ

    RailsとABDとCRUDとワークフロー - moroの日記
  • 6月のはぶにっき

    not found

    yugui
    yugui 2006/06/17
    Railsの開発法はDOAではないかという批判。「そもそも画面にあわせてDBを持てばいいっていうなら、もっと優れた方式があるじゃん。そうです、Tuigwaaですよ。」。そこで、acts_as_abd(仮)ですよ。
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • OBB vs AABB - Radium Software Development

    iPhoneの一般修理店は予約なしでも来店できる? 基的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、

  • 1