ORマッピングの功罪 - 設計者の発言
オブジェクト指向にもとづくクラス構造を、本来異質なRDBのテーブル構造に対応させることをOR(Object-Relational)マッピングといい、そのための仕掛けがORマッパーである。代表的なものがHibernateやJPAで、これらを使うことは、WEBアプリ界隈では常識といっていいものになっている。しかし、これを業務システム開発で利用するのは、特別な事情がない限りお勧めできない。 ORマッピングの技術は良いものと悪いものとをもたらした。良いものとしては、Ruby on Railsのような生産性の高い開発環境を挙げられる。じっさいRailsは、TwitterやGithubといった優れたサービスの基礎として社会に貢献した。いっぽう、業務システム開発の世界に対しては、ORマッパーはどちらかといえばハタ迷惑な影響ばかりをもたらしたと言わざるを得ない。テーブル構成が比較的単純に済むWEBアプリを
正規化崩しの目的は「高速化」だけではない - 設計者の発言
ひとつの事実が１か所にしか記録されないようにする――これはDB構造を正規化する際の基本だが、このルールを意図的に違反すること（正規化崩し）で、効果的なDB構造が生み出されることがある。正規化崩しは高速化のためだけにあると思われがちだが、それ以外の目的もある。そのような正規化崩しのテクニックとして、「抽象化（汎化）」を取り上げよう。 説明の前に、正規化崩しに関して大事なことを言い添えておきたい。勘違いしている技術者がいるが、正規化崩しとは「正規化してから崩す」という意味である。本来の正規形を経由せずに非正規形になっているとしたら、正規化崩しではなく、単なる「無手勝流」でしかない。 では、いったん正規化してから崩すことがなぜそれほど重要なのか。事前に「更新時異状（更新処理にともなって発生するデータの不整合）」に対処しておくためだ。正規化崩しにせよ無手勝流にせよ、そのままでは遅かれ早かれ更新時異
フレームワークとドメイン特化基盤 - 設計者の発言
JavaやRubyは「汎用プログラミング言語」であって、これを使えばたいていのソフトウエアを作れる。ゲームソフトも、組み込みソフトも、業務システムも、バンドのリズムセクションの自動演奏音源だって作れる。すばらしい。しかしこれは、汎用プログラミング言語の使い方として適切なのだろうか。 それらのソフトウエアは、いずれかの「ドメイン（ソフトウエアの分野）」に分類される。同一ドメイン内のソフトウエア群であれば、同一の特性を具えている。その共通特性にもとづいて、開発過程を合理化するための枠組みを想定できる。 そのような枠組みとして、もっとも素朴なものが「クラスライブラリ」だ。当該ドメイン向けに便利なクラス群をあらかじめ用意しておくのである。それらにテンプレート機能等を組み込んで整備すれば「アプリケーション・フレームワーク(APFW)」と呼ばれるものになる。 ドメインに対する合理化の営為はこれで終わら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
