忍者ブログ
めもとか趣味の事とかめもとか仕事の事とか、あとめもとか!
プロフィール
名前:ゆた
mixi :ゆた@GLADIUS
愛車:
 GLADIUS 400 ABS
 COROLLA FIELDER
 GIANT Escape R3
趣味:
 ツーリングとか音楽聴いたりとかとか
お気軽にコメントくださいねー
twitter
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

100get!っておい!自分で最初のキリ番っぽいの踏んじゃったよ!こんにちは。

なんていうか仕事が忙しいです。

まぁ遅くなっても21時半には会社出られるんだから、この業界で考えるとやさしいんだろうなーと思いつつ・・。

とりあえず今回のプロジェクトで切に思ったのは、DB 設計が重要過ぎるということ。

完全新規じゃなく、以前のに追加って事もあって、DB 構成がカオス過ぎるw

テーブル A
連番、得意先、売上日

テーブル B
得意先、適用日、価格

とかってあって、1ヵ月分データを横並びに出したい時、
単純に得意先で繋げて売上日と適用日を繋げてやれば自ずと価格が抽出でき・・ないんだよなぁorz

この適用日ってのがクセモノで、売上日と適用日がイコールではないから、

適用日 <= 売上日

の中の

適用日のMAX

を引っ張ってきて、引っ張ってきた適用日を元に再度 テーブルB を見てようやっと持って来たい一意のデータになる。

SELECT
    CASE WHEN A.売上日 = /*ym*/'200909' + '01' THEN B.価格 ELSE 0 END AS 価格01
    ,CASE WHEN A.売上日 = /*ym*/'200909' + '02' THEN B.価格 ELSE 0 END AS 価格02

FROM
    テーブルA AS A
LEFT JOIN
    (SELECT
        A.連番
        ,A.得意先
        ,A.売上日
        ,B.価格
    FROM
        (SELECT
        MAX(A.連番) AS 連番
        ,MAX(A.得意先) AS 得意先
        ,MAX(売上日) AS 売上日
        ,MAX(適用日) AS 適用日
    FROM
       テーブルA AS A
    LEFT JOIN
        テーブルB AS B
    ON
        A.得意先 = B.得意先
    AND
        A.売上日 >= B.適用日
    GROUP BY
        A.連番,A.得意先,A.売上日
    ) AS TKY
    INNER JOIN
        テーブルB AS B
    ON
        TKY.適用日 = B.適用日
    ) AS B
ON
    A.連番 = B.連番
AND
    A.得意先 = B.得意先
AND
    A.売上日 = B.売上日

とか悶々とこねくり回す事に。
対応する価格出すためだけに同じテーブル何度も参照してるからパフォーマンス落ちるわ、無駄に長くてコーディングに時間かかるわ、バグの元だわ、そもそも上ので動く自信ないわで散々。
こねくり回しながら、「もうーっ!(ぷんすか)」ってなる。

これがもし、適用日ではなく、適用開始日と適用終了日だったらば。

SELECT
    CASE WHEN A.売上日 = /*ym*/'200909' + '01' THEN B.価格 ELSE 0 END AS 価格01
    ,CASE WHEN A.売上日 = /*ym*/'200909' + '02' THEN B.価格 ELSE 0 END AS 価格02

FROM
    テーブルA AS A
LEFT JOIN
    テーブルB AS B
ON
    A.得意先 = B.得意先
AND
    A.売上日 >= B.適用開始日
AND
    A.売上日 <= B.適用終了日

くらいで済むんじゃないかい。

や、既にねむねむだからいよいよ怪しくなってきたんだけど。

他にも幾つも、こうだったら作りやすいしパフォーマンスもあがるんだろうなぁとか思いつつ実際の業務には中々いかせられないんだろうなぁと思いつつ。

明日もそんなSQLこねくりまわしの日々なのでねるよ!うわーん!
PR
この記事にコメントする
お名前
タイトル
メールアドレス
URL
コメント
パスワード   Vodafone絵文字 i-mode絵文字 Ezweb絵文字
無題
DB設計はかなり重要だな。
DB作ってプログラムやってるときによくアレ追加したほうがいいとか、やっぱいらないとかよくなるわ。
さらく 2009/11/20(Fri)09:40:13 編集
無題
DB設計はきついなぁ^^;
将来要りそうなものを全部突っ込むと、どんどんでかくなっていくし、途中で入れようと思うと、どうしてもつぎはぎになるし^^;

上記の場合、僕だとテーブルAに価格が欲しいかなw
価格がころころ変わるんなら、実際に売った時の価格を入れといてよ!的なw

後、適用開始日-適用終了日のだと、入れ子になってる時がきついのか?
入れ子になってることがあるのかは、謎だがw
2009/11/20(Fri)12:29:25 編集
無題
>>さらく
あるあるw
折角追加したのにやっぱなしとかなるとしょんぼりw

>>しn
>将来要りそうなものを全部突っ込むと、どんどんでかくなっていくし、途中で入れようと思うと、どうしてもつぎはぎになるし^^;
うんうん。
最終的には、つぎはぎな上にでかくなっているというw

>テーブルAに価格
まるほど。
確かにPG目線からするとそうだと楽・・なんだけど・・使う側は無理ゲーすぎるやねw
毎日の業務中に発生するデータを入れるだけで終わる人間が複数出ることになりそうだw

>入れ子
確かに、↑で書きながらそれもちょっと思いはしたんだけど・・そこはほら、入れ子にせず全部FromToでお願いしたいw
それこそ適用日1本だと入れ子も何もあったもんじゃないしねw
ゆのひと 2009/11/20(Fri)22:22:47 編集
この記事へのトラックバック
この記事にトラックバックする:
カレンダー
03 2024/04 05
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
最新コメント
[05/08 ゆた]
[05/08 yass]
[05/03 ゆた]
[04/25 yass]
[04/25 ゆた]
カウンター



忍者ブログ [PR]