2009年7月4日
業務アプリの各テーブルの末尾に、作成日、作成者,更新日、更新者、等を設定することがありまする
慎重なプロジェクトだと、作成端末、作成プログラム、更新端末、更新プログラムを設定することもあります。
これらの８項目を各テーブル必須項目としているプロジェクトも多いようです。
しかし、変更の発生しない、固定テーブル(性別表、人格表など)にも適用しているのは、どうでしょう。
売上伝票などの業務伝票データは変更するのは、本来良くなく、赤黒処理するのが原則です。
変更が発生しないのに、いつも8項目を伴って設置するのは、冗長感一杯です。
この8項目の役目は、「何か不具合があったときに追跡できるのため」と言われますが、この項目が役立つ場面に遭遇したことはありません。
何かあったときの保険なのかも知れません。
不具合データが発生したときは、入力した操作員を特定したり、どのような操作をしたかで追跡することはありますが、その時は操作ログを追求します。
(その前に)レコードに複数項目あり、複数者が変更を加えたとき、特定項目の変更者を特定することは、該当テーブルの変更者欄からは特定できないです。
他の仕組みで8項目の値が取得できれば、各テーブルに保持しなくても良いと思うのです。
私は、変更履歴表で、挿入、変更、削除ログを残すようにして、そこを参照すれば8項目に相当する値は取れるようにしています。
各テーブルが8項目を無くしてから、アプリ作成とテスト項目が軽減されました。
テーブル設計基準も画一的に適用させるのでなく、役割を吟味して、必要性を見直すことは大事です。
#テーブルの性質によっては、作成日、更新日、更新者等が大きな意味を持つのあります。それらには必須なのは勿論です。
2009年7月2日
自動車税はエンジンの排気量と車両のサイズで決まります。
最近は電気自動車やハイブリッドカーの登場で、動力源が多様化しています。
気になったまま放置していたのですが、電気自動車の税金ってどうなの。
車のセールスマンに聞いてみました。
乗用車仕様の場合、「総排気量1000cc以下の区分の税率によることが適当である」とされているようで、軽四並の税金だそうです。
走行性能も軽四並のようなので妥当かも知れません。と一応納得。
しかし、電気モーター出力をガソリンエンジン換算することは、比較自体無意味な気もします。
普及期になると、電気自動車税表ができると思いますが、その時は、馬力でしょうかね。
大出力にすると、蓄電池のサイズも大きくなり重たくなるので、一定サイズ以上すると、性能劣化が目立ちそう。
バッテリー問題を除くと、電気駆動って安いらしいですね。
聞いたところでは、電車1両の燃費は 30円/1Km らしい。
http://www.mydoco.com/html/goodstory/goodstory_17.htm
スケールメリットが大きいのでしょうが、想像以上に安いです。
ジャンボだと 65m/1リットルだとか。
http://oshiete1.goo.ne.jp/qa3080161.html
うん、比較条件が違うので、なんなのですが、車の効率が悪いのが見える気がします。飛行機も非エコのようだし。
エコ度で比較することがオカシイのか....(続きは....ないかも)
2009年7月1日
いつもの、エントリーだと、この制度はオカシイのでは...となるのですが......。
今乗ってる車はミニワゴン車(2400cc:94年登録車)で燃費が 5.5km/1リッタ という非エコカー。
7月に車検なんですが、あちこち部品交換や、タイヤも消耗してフル交換しないと車検が通らないと指摘を受けました。
車検を通すのに200K以上、掛かるらしい。
「今、コンパクトカーはコストパフォーマンスがよく、税金類が75%OFF に加えて、 車齢14年なので 25万円返ってくる。車検を通す費用を考えると、上下 50万も得だ」
セールスマンのセールストークの巧さなんでしょうが、凄く誘惑。
昨今の不況で、5.5Km/リッタの車は、頭痛の種です。悩んだ末、買い換えることに。
(何故か、排気量の1000cc車はエコカー指定されていない。大型家電のエコポイントに共通する変な匂いを感じるのですが....)
いざ、詳しく聞いてみると、 25万円は購入後に戻ってくるらしい。つまり、購入時は、売価の価格を用意しないと駄目。
これって辛い。25万円引いてくれるから、購入可能になったのに.....一括払いならまだしも、ローンを組むとき、売価で組むことになるので後で金が返ってきても､ローン利息は変わらない。
エコポイントもそうですが、後から返金するというのは、制度として不味いと思うのです。
#関西は現金値引き商売の筈だったのに、関東のポイント制度が普及してしまった。嘆かわしい。
購買促進なら、現金値引きの面を表に出したほうが効果が大きいとおもうのですが。。
エコカーに変えてもCO2排出しているのでエコになってない。減税や購入補助金は税金で補填されているから駄目だ.....今回は言いません。 <= 勝手だ。ダブスタだ。
制度自体がセコイ制度だと、内心では思っていたのですが、自分に利があると得した気持ちになる我が儘は内緒です。
2009年6月29日
「歴史は刻々と変わる」という番組が時々あります。
(例として)鎌倉幕府成立は1192年と習いましたが、今は1180年から1221年と色々諸説あります。
史実が変わったり、新事実が発覚したわけでもないので、「鎌倉幕府成立時期は違っていた」と言われてもシックリきません。
1192年は征夷大将軍に任ぜられた年です。
確かに幕府組織はそれ以前から存在していたようですし、1180年に侍所を設置しています。
どちらも、昔から判明していた年です。ということは、単に幕府成立の定義が変わっただけなのでしょう。
室町幕府は1338年の征夷大将軍任官年から1336年の建武式目の年に変わったようです。
でも、江戸幕府は、1603年の征夷大将軍任官年に開始となっています。
日頃、ルールや処理の適用範囲に画一性を求めている目からすると、素直に「歴史は変わる」とは映りません。「定義が変わったから見え方が変わっただけだ」と映ります。
「幕府開始時期」を征夷大将軍任官年とするルールだと、一貫性があってスッキリするのに、鎌倉時代と室町幕府は違うというのは、定義の設定に矛盾感があります。
「過去の出来事の評価は、当時の文化・風習で評価すべきで、以降の価値観で評価しては駄目だ」というのは当然だと思うのです。
時代名称は、当時の呼称でなく以降の呼称を遡って適用しているように思えて、落ち着きません。
室町幕府の呼称は、3代義満の公邸の場所からきてますね。当時の呼称はどのようだったのだろう。当初は足利幕府と称していたのでしょうか。
文字文化の乏しかった古代以前は、当時の呼称は不明なので、適切な用語を決めるのは難しいと思います。
でも、縄文が付いているから縄文時代はまだしも、弥生町から発掘されたから弥生時代というのは、以前にも書きましたが、個人感覚として嫌。
現在、第二次世界大戦の日本対連合国戦を太平洋戦争と称してますが。これも後追いの呼称ですね。当時、日本は「大東亜戦争」と称してました。
後追いで、定義や呼称を変更すると、要らぬ混乱を招くことが多いので、当時の呼称があるなら継続使用するのが歴史的扱いだと思うのです。
後追い定義以前に記された文献は違う基準で記述されているので、訂正は不可能です。
命名する人の責任は重いということでしょうか。
メソッドやインターフェースを提供後に変更するのは御法度ですが、何か通じるモノを感じるのは職業病でしょうか。
2009年6月27日
いまや、事務アプリにRDBは必須になってます。生産状態管理アプリでもデータ保持にRDBが使われています。
XMLが取って代わるかのように言われた時期もありますが、XML_Fileの更新は煩雑感があり見かけません。
RDBが万全だから使われているのではなく、他に代替がないから、使わざるを得ない面もあります。
過去に頂いたコメントに「RDBは時間軸がなく一面性しかない」というのがありました。
それは、しばしば感じます。
例: 得意先マスター
Code 氏名 住所
(1) A001 鴻池艶子 東京府東京市蒲田1-1 ; 昭和10年当時
(2) A001 住友艶子 東京府東京市蒲田3-4 ; 昭和15年:婚姻による改姓
(3) A001 住友艶子 東京都大田区蒲田3-4 ; 昭和18年特別区制度による表示変更
有る特定の人のデータですが、婚姻や地域制度の変更により、氏名・住所欄が変わります。システム上のCODEはA001であり、取引上は同一顧客に変わりません。
単純な顧客マスター引用だと (1)=>(2) に変更した時点で、(1)は抹消されます。 (2)=>(3) の時点で(2)は抹消され(3)が残ります。
昭和10年から 今まで毎年、この人の取引データが残っていたとします。
昭和16年の取引状況を再発行したととき、顧客住所は、(3)で表示されることになります。
少し気の利いたマスターなら
Code 氏名 住所 有効期間(From) 有効期間(To)
の項目を保持していて、
(1),(2),(3)のデータを保持していて、再発行当時の住所で印刷することを可能にしているのもあります。
しかし、構造的矛盾として、 (2)の時の請求書発送漏れがあり、(3)の住所に再発行したいケースには対応出来ません。
これは、運用ルールの問題かも知れませんが。
個々のアプリで対応することになります。
RDBに時間軸が無いと感じる所です。
業務の仕組みを処理するのが情報処理ですが、今や処理はプログラム言語で解決する時代ではなく、RDBやF/Wに委譲する部分も多くあります。
データテーブルなどのスキーマや制約で処理している部分も増加しています。
特定のキーのデータに有効期間が必要な場合は、少なくありません。しかし、RDBの機能としてはありません。
〒番号表も現在有効な住所に対して更新がなされるので、市区町村合併で消滅した地域名には無力です。
私は、項目単位の変更履歴を取る仕組みを実装しています。
多重化やOLAP機能などの機能強化は喜ばしいのですが、業務的に現場で必須的に作られる仕組み(変更ログや更新履歴、更新日、更新者等)は標準機能で保持してもいいのでは?
と思うのです。
(P.S) 更新日、更新者は個別アプリ的性格が強いので無理っぽいですが、変更履歴や有効期間型はF/W化可能な気がします。
2009年6月25日
RDBテーブル上の主キーと業務上のキーは一致させる必要はないので、人工キーが有効になるのですが、今回は、業務上のキーの話。
顧客台帳や商品台帳などのマスターのコード化は、対象のモノを特定するために設定します。
逆に、名称で特定できるのであれば、コード化する必要はありません。
性別を "男","女" , 人格区分を "個","法" で固定値で保持しても、支障がないし、スッキリする場合もあります。
なんでもコード化することに疑問を覚える時があります。
顧客台帳や商品台帳の名称をキーにできないのは同姓同名や、名称変更などがあり、単一のモノと対にならないことも一因です。
ユニーク値を構成できれば、何でもキーになり得るのですが、浅い考えでコードルールを作ると混乱を招きかねません。
閑話休題。不思議な体系のシステムがあるそうな。
顧客コードを6桁に設定しているシステムがあります。
上1桁が "T" は得意先 "S" は仕入先 "@"は得意先兼仕入先
二桁目: 顧客名称の50音表の行数
青木さんなら あ なので 1
香川さんなら か なので 2
三桁目: 顧客名称の50音表の段数
木村さんなら き なので 2
4,5,6桁目
上3桁確定後の連番
その結果、得意先の木村さんは、T22002のようになります。
疑問:
・得意先と仕入先の区別は、客の扱い区分なので、客情報とは別にすべきでしょう。
ある人を得意先で登録していて、そこから仕入れることになったらキーを付け替えることになってしまいます。
「そんなことはあり得ない。仕入先と得意先は厳格に分かれている」というケースでも、キー構成に組み入れるのは疑問です。
・５０音表の段数と行数で数値化する意味が不明。
そのままカタカナを取り入れたら済むのでは。.....これは質問したことがあります。
木村さんなら "ｷ" にすれば、二桁目と三桁目は一つで済みますしね。
主キー項目は文字項目だが、英数字項目になっていて、カタカナは入らない。....というのでなく、システム的な項目にカタカナが入るのは不細工だ。との判断らしい。アヤシイですが。
・社名変更や合併したりしたら、コード体系を変更するのでしょうか?
主キー付け替えを行っているらしいです。
このようになった背景はシステム歴史を聞くと、根拠はあるようです。
もともと得意先しか登録していなくて、キー項目は5桁の数字で管理していたらしい。
仕入先の項目も同じ項目なので、併用しようとしたとき、区別する必要があるという意見を聞いて、主キーの頭を1byte増やして、文字項目にしたらしい。
業務システムは滞りなく動作しているので、業務要件的には満足に動作している....というのですが。
過去の継承という束縛は以外意外に大きく、今までのルールを崩すのはナカナカできないようです。
システム屋は保守的な人が多いと見るか、継承したほうが危険率が少ないと見るか、見解は分かれますが、スクラッチビルドしたほうがスッキリすると思うのです。
#主キーを付け替える。というのは危険を伴う行為なので、極力発生しないようにシステム設計したいものです。
2009年6月22日
特定言語のソースを生成するジェネレータ定義語が言語に含むか否かは見解が分かれますが、広義で言語になると思っています。
XMLが言語に分類されることもあるので、「言語」の規定も広いです。
多くの言語は「汎用言語」を標榜していて、適用範囲は大きいです。科学計算をコボルで記述することも不可能ではないくらいです。
どの分野のアプリにも対応できるために、構文、文法も広くなっています。
開発者は各人独自のスタイルをもっています。
開発標準が在り、同一の仕様書に基づいて、作成しても同一のソースが上がってくることはマズありません。
こういう世界に住んでいると、違う発想の話は新鮮に聞こえます。
「スペリア」という言語製品の話を聞きました。
http://www.carrera.co.jp/speriatoha.html
開発者の主張は
「C#,JAVA/VBなどは汎用すぎて、ソースに個性が出る。
汎用言語はなんでもできる反面、開発者が去ってしまうと。保守できなくなる。それが欠点だ。
顧客は、業務がしたいのであって、ソースの保守はしたくない。保守できないソースは負の資産だ。
誰が作っても、同じソースが出来るのが、本来の業務向け言語て有るはず。
何十年たっても、同じソースで動き、保守可能になれば、負の資産にはならない。
当製品はそういう製品だ。使いたくなっただろう。買ってくれ。
」
うーん。私は、「スッキリしたソースが読みやすく、保守性が高い」と考える派で、開発者の能力・経験で同じソースに仕上がるのは不可能だし、それだから言語なのだと思う。
「日本人ならだれでも同じ文章を書く」なんて気持ち悪いですしね。否定的で反発したのですが、逆襲されました。
「確かに、WPF/LINQ/AJAX/正規表現/.....いろいろと新機能は次々と登場する。しかし、業務アプリの仕組みはコボル登場以前から変わっていない。
データを入力して、蓄えて、定型書式で出力するだけだ。この流れは10個程度のパターンに分類できる。
当製品の言語は、パラメータに近い文法で記述したソースだ。、それだけで業務パターンを実行できる優れものだ。
新人もベテランも、誰が作っても同じソースを記述することになる。それだけ生産性が高まる。
今後何十年たってもこの姿は残る。すなわち安定した製品である。
買わないか。
」
私と方向性が違うので、ゴメンナサイ。しました。
確かに、特定業務では、コボルでも十分対処できているので、何十年も同じスタイルなのが良い面もあるので、否定するものではありません。
でも、業務アプリがいつまで、その範囲で収まっているとは思えない。エントリー端末がキーポードからバーコード、OCRに変わったり、商品にICタブが付くようになれば、データエントリ系のアプリは変わるでしょう。
集計も「期間、部署、分類、集計方法..」を指示して集計する形式が続くとは思えません。一発指示一発集計が実現すれば、言語も大きく変わるでしょう。
新機能は、言語に加わる機能というより、開発設計を左右するものと私は思うのです。
Linqが使えるから、Linqを使う前提で設計できるし、SQLで集計ができるからSQLを前提に設計ができます。曖昧検索も正規表現を前提に設計できます。
作成者の個性差がソースに出るのは、マイナス面と見えますが、プラス面のが遙かに大きいです。(と信じたい。)
汎用性や新機能を否定し、同じソースを生み出す言語や開発標準は、短期間的にはメリットかも知れませんが、長期視点では納得できませんでした。
2009年6月20日
ソニーが中心となって開発したにも関わらず....
と言っても意味が通じませんね。私の携帯は Sony Ericsson製品で外部メモリがメモリスティックデュオです。
数年経過したので、機種変更しようとしたのですが、該当製品の後継機種は、MINI_SDになっている。
詳しく聞くと、本体内部のデータは移行できるが、外部メモリーの移行はできないとのこと。
PC経由でCOPYすれば済むことなんですが、なんかスッキリしない。
同一メーカー製品のメディア媒体形式を途中で変更するのは、営業的に英断なのでしょうが、ユーザーに負担をかけるのも事実。
どうも、ソニーはそういうことが多いように感じます。
βビデオ、エルカセット、
HD-DVDMD-DATA,Hi-MD....
それにしても、フラッシュメモリの乱立は収拾するのでしようか。xDカードも多いし。
そのお陰で低価格化したので功績は大きいです。USBメモリの低価格化も凄いですしね。
シリコンディスクも早く価格破壊しないかなぁ。
2009年6月19日
もちろん、優劣や速度の面で議論するのは的外れです。
Case by Caseです。と結論つけると、何も主張していないことになりますね。
私の基準は、該当レコードがリーフ行(自分行を親とする子データ)である時は、Updateにします。
自分の行が親(鏡行)になっていて、明細が付く時は、Delete/Insertで作るようにしています。
理由:
修正前と修正後で明細行の行数が増減するとき、 Delete/Insertでないと、処理が煩雑になる
例)
修正前
明細NO 品名 個数
明細1: 01 aaa 10
明細2: 02 bbb 20
明細3: 03 ccc 30
この伝票で、 明細2が抹消になり, 明細3の個数が 22 に変わり, 1行追加( ddd 40個) があった。
明細1を最後に持って行きたい。
業務仕様で、明細NOは1基準の通番にしないといけない。
(このシーンは誇張ではなく、現場では起こりうる要求だったりします。)
この場合、明細2を消して 、明細3を変更して、明細4を追加し、明細NOを振り直す。 よりも、一旦、明細を削除して、新規Insertした方がシンプルになります。
修正後
明細NO 品名 個数
明細3: 01 ccc 22
明細4: 02 ddd 40
明細1: 03 aaa 10
業務面から見ると、どちらでも結果は同じなので、安定して作れるほうが良いと思います。
連番の付け方が問題になることがあります。
SQL ServerのIdentity項目やOracleのシーケンスは便利なんですが、トランザクションとの相性が悪く、ロールバックが起こると欠番が生じます。
いずれにしても、表示連番は、自力で管理する必要があります。
昔は、Delete/Insertで生じるData領域の抜け穴の処理問題がおおきく、「駄目だ/嫌だ」と主張する人もいましたね。
この主張は、当時から納得できませんでした。トリガーをみれば、
SQL Serverの更新トリガーでは変更前後は Delete/Insertに格納されていますし、 Oracleでも new/oldに格納されています。
RDBの内部実装上は、delete/insert的な仕組みで処理されているのでしょうね。
となると、アプリでどちらが良いかの議論は陰が薄れると思うのです。(下段補足)
今日のように、大容量ＨＤＤの時代では、定期的に全体のコンプレスすることもあり、個別の穴を意識することも少なくなりました。
(*) 少し後ろめたさは感じるのは、Byte単位で短いプログラムを作ったり、データ無効化による領域穴が、リソース的に大きな問題になっていた時代のトラウマでしょうか。
メモリアロケーションを自前でしてた当時、サイズとアロック順を意識しましたが、GCに依存する環境では、穴を意識することはないですね。
それと同様に、RDBでも、穴を意識しない時代になったのでしょうか。
(*)上記の例は 比較するために想定した例です。
実務で上記の更新操作は疑問です。伝票は、更新/削除するのは駄目で、赤黒処理するのが基本です。その面では、常に Insertになります。
更新でも削除でも、変更履歴を残すのは基本なので、変更履歴を追跡して、過去に戻って復元可能だからＯＫだとの意見もありますが、復元する仕組みは面倒そうですね。
「実装のしやすさで判断すれば良い」というのが、私の思いです。
鏡と明細の二次元ならこれで良いのですが、3次元以上の階層構造のテーブルになると、何が適切なのか判りません。
そのときは、Classのシリアライズ機能に適応して欲しいと願うのです。(Sql ServerのXML項目で可能か、試行してみて、挫折したのは内緒です。)
(PS). RDB内部で Delete/Insertしているという意味ではなく、 変更前後のデータほ保持しているのと、 rolleback/Comit用に多くの領域を確保しているので、行単位のdelete/Insert とupdateの領域効率を厳密に追求するのはどうなのなかぁ..という意味です。
2009年6月18日
(*)前回の不適切なSQL文を用いてPIVOTは遅いと結論付けてしまいました。改めて試行すると、遅くなかったので報告します。
誤った情報で迷惑をお掛けしました。ごめんなさい。
さて、下記のSQL文で処理したのですが、額の表示で SUM(額)かMax(額)にすべきかのコメントを貰ったのですが、結果が異なりました。
★PIVOT処理
select Top n 社員CODE ,[1Y] 予定1月,[1J] 実績1月,[2Y] 予定2月,[2J] 実績2月,[3Y] 予定3月,[3J] 実績3月,[4Y] 予定4月,[4J] 実績4月
,[5Y] 予定5月,[5J] 実績5月,[6Y] 予定6月,[6J] 実績6月,[7Y] 予定7月,[7J] 実績7月,[8Y] 予定4月,[8J] 実績8月
,[9Y] 予定9月,[9J] 実績9月,[10Y] 予定10月,[10J] 実績10月,[11Y] 予定11月,[11J] 実績11月,[12Y] 予定12月,[12J] 実績12月
From
(
select 社員CODE,cast(月 as varchar)+予実 区分,額 from 縦持ち
) T
PIVOT
(
sum(額) for 区分 in ([1Y] ,[1J],[2Y] ,[2J],[3Y] ,[3J],[4Y] ,[4J],
[5Y] ,[5J],[6Y] ,[6J],[7Y] ,[7J],[8Y] ,[8J],
[9Y] ,[9J],[10Y] ,[10J],[11Y] ,[11J],[12Y] ,[12J]
)
)
as PIVOT_TABLE
order by 社員CODE
■SUM(額)で実行
1人分:00.0156
10人分:00.0312
100人分:00.1872
1000人分:01.1388
10000人分:11.1944
100000人分:81.2126
■MAX(額)で実行
1人分:00.0312000
10人分:00.0468000
100人分:00.1248000
1000人分:00.5772000
10000人分:05.7096000
100000人分:41.2776000
■MAXMIN(額)で実行
1人分:00.0312000
10人分:00.0468000
100人分:00.0780000
1000人分:00.6084000
10000人分:05.6472000
100000人分:41.1800000
■AVG(額)で実行
1人分:00.0624000
10人分:00.0780000
100人分:00.1404000
1000人分:01.1232000
10000人分:11.2008000
100000人分:80.4960000
SUM()とAVG() はMAX(),MIN()の倍、要してますね。「内部ロジックなので差は少ない」と思い込んでいたので少しショック。
★LeftJoinで縦横展開..のコメントで参照先を教えて貰いました。すこし強引な力業で、遅いだろうなという印象を持ったのですが。
select top n T.社員CODE
, y1.額 月1予算 ,j1.額 月1実績
, y2.額 月2予算 ,j2.額 月2実績
, y3.額 月3予算 ,j3.額 月3実績
, y4.額 月4予算 ,j4.額 月4実績
, y5.額 月5予算 ,j5.額 月5実績
, y6.額 月6予算 ,j6.額 月6実績
, y7.額 月7予算 ,j7.額 月7実績
, y8.額 月8予算 ,j8.額 月8実績
, y9.額 月9予算 ,j9.額 月9実績
, y10.額 月10予算 ,j10.額 月10実績
, y11.額 月11予算 ,j11.額 月11実績
, y12.額 月12予算 ,j12.額 月12実績
from 縦持ち T
left join 縦持ち as y1 on T.社員CODE = y1.社員CODE and y1.月=1 and y1.予実='Y'
left join 縦持ち as j1 on T.社員CODE = j1.社員CODE and j1.月=1 and j1.予実='J'
left join 縦持ち as y2 on T.社員CODE = y2.社員CODE and y2.月=2 and y2.予実='Y'
left join 縦持ち as j2 on T.社員CODE = j2.社員CODE and j2.月=2 and j2.予実='J'
left join 縦持ち as y3 on T.社員CODE = y3.社員CODE and y3.月=3 and y3.予実='Y'
left join 縦持ち as j3 on T.社員CODE = j3.社員CODE and j3.月=3 and j3.予実='J'
left join 縦持ち as y4 on T.社員CODE = y4.社員CODE and y4.月=4 and y4.予実='Y'
left join 縦持ち as j4 on T.社員CODE = j4.社員CODE and j4.月=4 and j4.予実='J'
left join 縦持ち as y5 on T.社員CODE = y5.社員CODE and y5.月=5 and y5.予実='Y'
left join 縦持ち as j5 on T.社員CODE = j5.社員CODE and j5.月=5 and j5.予実='J'
left join 縦持ち as y6 on T.社員CODE = y6.社員CODE and y6.月=6 and y6.予実='Y'
left join 縦持ち as j6 on T.社員CODE = j6.社員CODE and j6.月=6 and j6.予実='J'
left join 縦持ち as y7 on T.社員CODE = y7.社員CODE and y7.月=7 and y7.予実='Y'
left join 縦持ち as j7 on T.社員CODE = j7.社員CODE and j7.月=7 and j7.予実='J'
left join 縦持ち as y8 on T.社員CODE = y8.社員CODE and y8.月=8 and y8.予実='Y'
left join 縦持ち as j8 on T.社員CODE = j8.社員CODE and j8.月=8 and j8.予実='J'
left join 縦持ち as y9 on T.社員CODE = y9.社員CODE and y9.月=9 and y9.予実='Y'
left join 縦持ち as j9 on T.社員CODE = j9.社員CODE and j9.月=9 and j9.予実='J'
left join 縦持ち as y10 on T.社員CODE = y10.社員CODE and y10.月=10 and y10.予実='Y'
left join 縦持ち as j10 on T.社員CODE = j10.社員CODE and j10.月=10 and j10.予実='J'
left join 縦持ち as y11 on T.社員CODE = y11.社員CODE and y11.月=11 and y11.予実='Y'
left join 縦持ち as j11 on T.社員CODE = j11.社員CODE and j11.月=11 and j11.予実='J'
left join 縦持ち as y12 on T.社員CODE = y12.社員CODE and y12.月=12 and y12.予実='Y'
left join 縦持ち as j12 on T.社員CODE = j12.社員CODE and j12.月=12 and j12.予実='J'
order by T.社員CODE
■Left Join文
1人分:00.0468000
10人分:00.1716000
100人分:01.0452000
1000人分:09.1104000
10000人分:48.4224000
100000人分: SQL server機で Outof memory発生: 大量のメモリーを食うようです。
なんと、Pivot のMax(額)に近い数値... LeftJoinを見直しました。
横持ちと縦持ち_その後3 -で報告した値(下記)の倍くらいでしょうか。
横持ち 縦横変換
1件 00.014 00.004
10件 00.015 00.008
100件 00.017 00.042
1000件 00.048 00.322
10000件 01.913 21.913
今シリーズは、速度比だけを重視した報告になり、実務に適していない面があります。
倍程度の速度差なら、どちらを使っても差違がなく、アプリケーション・ソースの作りやすいほうが良いと思います。
縦横は優劣の問題でなく、向き不向きを吟味する必要があります。
とはいうものの、私は、縦持ち派ですが。