タグ

2018年1月31日のブックマーク (5件)

  • 「スパゲッティクエリ」の解決策は断じて「ぐるぐるクエリ」ではない!! : i am BEST

    2013年06月11日01:35 カテゴリSQLデータベース 「スパゲッティクエリ」の解決策は断じて「ぐるぐるクエリ」ではない!! 『SQL アンチパターン』というに「スパゲッティクエリ」というアンチパターンが載っています。(17章) 名前だけでなんとなくわかった気になるアンチパターンなのですが、実はその「わかった気」は違っているのでは?! というのが今回のお話です。 「マッチョなクエリ」 以前、『SQL アンチパターン』を題材にしたセミナーに出たことがありました。 その時、参加者がこのアンチパターンについて「マッチョなクエリはよくない」とか「複雑なSQL はよくない」といった感想をもらしているのを聞きました。 そのまま続けていろいろ聞いていると、どうも「単純な SELECT などをプログラムのループでまわして結果を取得した方が、SQL のいろんな機能を使うよりいい」というようにこの「ス

    「スパゲッティクエリ」の解決策は断じて「ぐるぐるクエリ」ではない!! : i am BEST
    masa8aurum
    masa8aurum 2018/01/31
    “『SQL アンチパターン』という本に「スパゲッティクエリ」というアンチパターンが載っています。(17章)” ここ読みたい。「スパゲッティクエリ」の実例と、改善例を知りたい。
  • SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? : i am BEST

    2014年09月03日02:46 カテゴリSQLデータベース SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? 最近のたいていのデータベース製品では、ユーザー定義関数(UDF)という機能が使えるようになっています。Oracle では”ストアド・ファンクション”と呼ばれているものですね。 よく”処理の再利用”とか”処理の部品化”といった用途に使われていますが、パフォーマンスの問題が起こってしまうケースがままあるんですね。 ”集合”を原理とするリレーショナル・データベースの SQL 処理に対して”手続き指向”の発想で立ち向かってしまい、いろんな問題を起こしてしまうことがよくあります。これもそうした例のひとつと言っていいでしょう。 では、”集合指向”での再利用・部品化とはどのように行なうものなのでしょうか?? その答えは、「ビューの利用」なんです。 ユーザー定義関

    SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? : i am BEST
    masa8aurum
    masa8aurum 2018/01/31
    SQL での”再利用””部品化”
  • SQLの部品化について

    非実在naka aki @naka_aki_spl 再掲。SQLは、「完結したクエリ(つまりビュー)」だけじゃ部品化の粒度として大きすぎる。条件とかもを部品(名前付き部品も含む)化したい。個人的に今一番気がかりなのは「結合条件」の「部品」化。 2014-01-30 20:45:44 非実在naka aki @naka_aki_spl ただ、部品化といっても、特に結合条件なんてものは「任意のテーブル/サブクエリ」と好き放題に組み合わせれるハズが無い。使える組み合わせは強く拘束されるはず。、、、これって「型」じゃないのか? 2014-01-30 20:48:58 非実在naka aki @naka_aki_spl ある検索条件(ANDとかで複数合体するのも当然アリ)が「どのテーブル(やクエリ)を指すことができるか」は、「型」だよな。a.b=c.dなんてな条件は、テーブル粒度でいえば「aからcを

    SQLの部品化について
    masa8aurum
    masa8aurum 2018/01/31
    考える参考に。
  • レガシーな独自フレームワークから脱却してRailsへ徐々に移行している話 - メドピア開発者ブログ

    みなさんこんにちわ。 メドピアでエンジニアをやっている内田と申します。 現在メドピアではPHPで作られたレガシーな独自フレームワーク (以下FW) からRailsへと移行するプロジェクトが進んでいます。 今回は移行に向けて行ったことについて共有したいと思います。 移行の計画 メドピア株式会社では、医師限定のコミュニティサイト「MedPeer 」を運営しています。 「MedPeer 」サービス内では、薬剤評価掲示版、症例相談、Forum、ニュースなど、医師同士が情報交換をするための、機能の異なる複数のサービスを提供しています。 それらサービスの内部では7年前に作られたPHPの独自FWが採用されており、コードが肥大化したことで機能の変更や追加がとても困難になっていたことが課題でした。 そうした課題を解決するために、アーキテクチャの見直しを含めたリプレースがエンジニアの主導で計画されました。 様

    レガシーな独自フレームワークから脱却してRailsへ徐々に移行している話 - メドピア開発者ブログ
  • SI系企業で社内独自のフレームワークを作りたくなる理由について

    tl;dr社内フレームワークは開発生産性を高めるためと言われることが多いが、実際はシステムを守るために産まれる(ことがある)すべては複雑怪奇な業務をシステム化する人が、システムアーキテクチャや非機能面まで全て見れないことに起因する画期的なハックはなく、業務にもシステムにも詳しい人を増やしていきましょうはじめにSI系の大規模な業務システム開発に参加すると、社内独自の重厚なフレームワークに遭遇することがあると思います。ここでいう社内フレームワークとは以下の条件に一致するものを指すことにします。 クローズドソースであるその社内でゼロベースで開発されたり、既存のフレームワークを拡張・ラップしているなど、独自の背景・思想により開発されているそのため、フレームワーク独自のお作法や制約がある開発生産性の向上や、非機能的な要件を満たすことを目的とする社内フレームワークに思いを馳せる自分が経験があるのはJa

    SI系企業で社内独自のフレームワークを作りたくなる理由について