コボラは横長DBがお好き

>>917
おまえフェッチするくせになにがクエリダヨｗ>>875クエリも糞もねえだろｗ

>>916
そのつどPG修正か....大変だな。

先輩！ロールバックセグメントが足りません！！！！！

>>914
まぁあんまし熱くなるなよ。
お前を怒らそうとしてるだけなんだと思うぜ。
お前がそうやって反応するから奴らも調子にのるんだよ。
だから、気にするなよ。





でも、お前の言ってることはおかしいけどな ｗ

FOR UPDATEをはずすんだ！

先輩！ロックと読取一貫性は関係ないのではないでしょうか

>>921
さては本気でわかってねーな？
新しい税率が施行されるたびにレコード一件追加すればいいだけだ。
コードに手は入らない。

>>920
苦しいな。

アホだな。年間集計するクエリを書いて実行計画を見てみろ。
JOINでアホみたいにコストがかかるぞ

まあ別にいいやもうメンドクセエ
好きにやれよ

>>926
フロントで計算するのか？

>>929
めんどくさいなら、いちいちそんなこと書かずに黙って消えろ ｗ

なんだか素人がMS-Accessで作ったような話だな。

なんでも連結連結

>>926
で、お前の発言は、何番と何番と.....？

>>926
フロントで計算するのか？

>>931
そしたら寂しいくせによく言うよｗ

データウェアハウス的運用をまるっきり考えていないおばかさんが設計するとこうなります。

年次処理中はアクセスしないで下さい。ロールバックセグメントがパンクします。

だいたいさあ、DBに無理してつっこまなきゃいいじゃん。

まあ、COBOLで立派に動いてたシステムのリプレースなんてISAMで十分だろと
思うことは多々あるな。

>>883
> # ネタじゃないのが恐ろしい。

一度やってみたかったのに、ガチでやったやついるのかｗｗ

集計なんてPL/SQLでカーソル開いて一行一行フェッチしていけばいいだろ。
税率マスタは予めカーソル開いて連想配列に全件を展開しておくんだ。
これで高速になる。わかったかね。素人諸君。

>>919

>>941にもう一度言ってやてくれ ｗ

PL/SQL

Oracleに限定されちまったね。

ジャーナルデータをあーだこーだ弄って遊んでどうするよ？
ログみたいなモンだろ＞ジャーナル

キーとか正規化とか関係ねぃよ。

レジのはき出すレシート情報が書き出されていれば問題ねぃよ＞ジャーナル

逆に正規化されたり別計算ロジックぶっ込まれたり、冗談じゃねぇっつぅの！

とりあえず、おまいさんらがDBを愛してやまないことだけはわかった。

伝票 == ジャーナルデータ　== 後で更新されない

これを前提にして索引構成表（Oracle)やクラスタ化インデックス（MS-SQL/MySQL)に
しておくと、週報や月報用の集計が高速になります。挿入順に並べられるからな。

これ、豆知識な。

ジャーナルの行き着く先はDWH(データマイニング)なんだよ。
使い道が違うんだ。

現場ではマスターとかと同列に語れないんだよ。

そろそろ次スレたのむ

やめとけ！！

>>947
今日、塾でならったのか。
よかったな。

更新系、参照系は要求が全然違うからね。

同じデータでも、更新される可能性のあるうちに存在するテーブルと、
更新の終了したテーブルは分けたりするんだよ。

コボラは横長ＤＢがお好き ２カラム目
http://pc11.2ch.net/test/read.cgi/prog/1179927770/

>>953
　　　　ガッ　_, ,_　　ガッ
ガッ_, ,_ 　（ ･д･）　 _, ,_ガッ 　　　　　
　 （ ･д･）　Ｕ☆ミ　（･д･ ）　　　　　　　
　　　⊂彡☆))Д´☆ミ⊃　　ガッ
　　　 , ,∩彡☆ ☆ミ∩, ,
　 （ 　　）　　ガッ 　（　　　）
　ガッ　　　　　　ガッ

POSレジやれ。勉強になる。
それが全てではないし、最強でもないが。

そんだけだ。

DWHを念頭において全テーブル

create table hoge (
col char(10000)
)

とします

列のバインドが楽でいいね。

金融機関の勘定系処理で毎日為替レートが変わるシステムとか
組んでみれば、正規化は多少崩したほうが楽ではある。

が、消費税とか保険の利率程度の変更だとJOINした方が
パフォーマンスいいだろうなぁ。

>>958
普通為替レートと消費税を同じ次元で扱うか？

>940
> 一度やってみたかったのに、ガチでやったやついるのかｗｗ

例えば某社のレセコ(ry

消費税とかは後から計算できるかどうかより、実際に請求した金額の履歴としての
意味から残しておくようにするけどな。俺なら。
履歴系データってそういうもんだろ。

つか、それ正規化してもレコードのコンパクト化には殆ど寄与しないよな。

正規化はコンパクト化とはイコールじゃないだろ。
結果的に一部コンパクトになる事が有るにしてもだ。

毎度JOINするなら冗長化させた方が速い場合も

消費税は、相手がAなら端数切り上げ、Bなら端数切捨て、
一回の注文でも請求書がN枚になったらN回に分けて計算、とか
色々言われたことあるな。

消費税はそれを決めるルールに基づいて（場合によってはマスタ参照もありうる）、
その値をそのまま伝票を切るときに伝票に書き込んで終わり。
連結しても意味が全然無い。パフォーマンスもあがらない。

てか問題なのは消費税カラムの必要性とかでは無いだろ…。
脱線しすぎ。

もとはといえば>>887のａｆｏが....

>>887はコボラ以上の人気者
飲み会に出れば皆が相手してくれる
飲み会をﾊﾟｽれば皆が陰口たたいてくれる

消費税は、端数のルールが途中で変わる可能性がある。
履歴と言う意味からも実際の請求額を残しておく。
このときに、表示用に税率を残しておく場合もありえる。