0214NAME IS NULL2017/04/30(日) 03:36:41.43ID:???>>182 後の人間を苦しめるコードをまき散らすのは止めよう 0215NAME IS NULL2017/04/30(日) 19:54:54.91ID:PSrTmapn>>214 馬鹿の苦しみなんか気にしてられんわw 0216NAME IS NULL2017/04/30(日) 20:56:47.54ID:??? 3年分取ってきてと言われて初めて問題に気付くパターンや 0217NAME IS NULL2017/04/30(日) 23:19:56.68ID:??? where fiscal_year(year, month) = 2017 みたいな感じで関数使うかビュー使うほうがロジックが一箇所に集まっていい気がする パフォーマンス気にするレベルならcalender yearとは別にfiscal yearをデータに持たせるかな 0218NAME IS NULL2017/04/30(日) 23:33:29.04ID:??? あと fiscal_year(date) みたいにオーバーロードしとけば インターフェースが統一されて使いやすい 0219NAME IS NULL2017/05/01(月) 09:41:38.57ID:??? SQLにオーバーロードあるんですか?どんなRDB? 0220NAME IS NULL2017/05/01(月) 10:54:41.81ID:??? え、、、普通にあるでしょ むしろできないDBってどれよ 0221NAME IS NULL2017/05/01(月) 13:48:49.26ID:???>>220 できないやつ多数でしょ 0222NAME IS NULL2017/05/01(月) 14:14:22.87ID:??? そうなんか、OracleとPostgreSQLで出来てるから普通なのかと・・・ 0223NAME IS NULL2017/05/01(月) 14:29:03.64ID:??? まーた、俺様の「普通」が炸裂しとる 0224NAME IS NULL2017/05/01(月) 14:33:46.48ID:??? Oracleは特例 いいね? 0225NAME IS NULL2017/05/01(月) 15:03:51.32ID:??? てか、そもそもOracleでも単純なオーバーロードってあったっけ? 0226NAME IS NULL2017/05/01(月) 15:05:03.60ID:??? packageを使ったオーバーロードはあるが・・・ http://www.shift-the-oracle.com/plsql/overloading-subprogram-name.html0227NAME IS NULL2017/05/01(月) 15:07:37.27ID:??? このケースはComputed Columnが使えればそれがいいと思うけど Postgresでは使えないから関数オーバーロードしとくって話 Computed Columnなら使えるDB多いだろ
SQL標準ならView使えって話かもしれんがViewは管理上のオーバーヘッドが高くなる傾向があるから 使わなくてすむケースならなるべく使わないようにしてる 0228NAME IS NULL2017/05/01(月) 15:15:27.63ID:??? 普通に>>182でいいだろ 0229NAME IS NULL2017/05/01(月) 15:36:01.14ID:??? PostgreSQL有害論 0230NAME IS NULL2017/05/01(月) 16:10:53.74ID:???>>228 会計年度を必要とするたびに繰り返し同じことをするのでよければね 年度別に集計したい場合とかしんどいし俺はごめんだわ 0231NAME IS NULL2017/05/01(月) 16:49:59.51ID:??? 普通に関数でいいと思うんだが、あえて(関数?)オーバーロードって言ってるのはなんで? 0232NAME IS NULL2017/05/01(月) 16:57:59.25ID:???>>230 そういうこと言ってるからいつまでたってもスキルが向上しないんだよ select case when month < 4 then year - 1 else year end as fiscal_year, sum(hoge) from foo group by case when month < 4 then year - 1 else year end 0233NAME IS NULL2017/05/01(月) 17:06:24.57ID:??? つか、いたるところで会計年度を意識するようなシステムなら、会計年度カラムを作っとけばいいよな 0234NAME IS NULL2017/05/01(月) 18:03:32.59ID:???>>232 where句も入れて何回繰り返すのさ 面倒くさいとは思わないの? 単発の作業ならわからんでもないが会計年度みたいなのは1回じゃすまないだろ
>>231 日付型でデータを持ったテーブルがあったり 日付型に徐々に移行したい場合に同じ名前で扱えるとうれしいから 会計年度って概念をDBに反映させる一つの手段 0235NAME IS NULL2017/05/01(月) 18:18:52.43ID:???>>234 > 面倒くさいとは思わないの? いや、まったく >>232レベルのクエリなら10秒もかからずタイプできるだろ 0236NAME IS NULL2017/05/01(月) 18:28:00.19ID:???>>234 > where句も入れて何回繰り返すのさ ストアドでも似たようなもんだろ。 select fiscal_year(year, month), sum(hoge) from fuga group by fiscal_year(year, month) しかもストアド使うと、year, monthにインデックスあっても使われないし。 0237NAME IS NULL2017/05/01(月) 18:37:19.33ID:??? ストアド最強!!!|バカの壁| SQL92以降 0238NAME IS NULL2017/05/01(月) 18:46:32.86ID:??? kantomi@qiita_banned < ストアド!ストアド! 0239NAME IS NULL2017/05/01(月) 18:53:59.52ID:???>>235 面倒くさいと思わないならいいんじゃね
インデックスは必要ならはればいい 0240NAME IS NULL2017/05/01(月) 19:03:28.63ID:???>>233 算出できる情報を別途カラム作って持たせるのは最終手段 0241NAME IS NULL2017/05/01(月) 19:04:19.13ID:???>>180 重み付けの定石 >>182 単年度でしか動かないクソ >>185 意図が分かりやすい >>217 ビジネスロジックをDBMSに持たせる派とアプリに持たせる派で戦争勃発 0242NAME IS NULL2017/05/01(月) 19:33:28.15ID:???>>241 一番馬鹿ww 0243NAME IS NULL2017/05/01(月) 21:25:30.10ID:???>>234 fiscal_year(year, month)って関数自体はまだなにもオーバーロードしてないだろうが。 0244NAME IS NULL2017/05/01(月) 21:52:46.85ID:45FTV8QE>>241のどこが馬鹿なのか論理的に説明できないやついるの? 0245NAME IS NULL2017/05/01(月) 23:12:56.24ID:???>>240 分解せずに日付型で持っていればよかったって事だな 以降>>188へ戻る 0246NAME IS NULL2017/05/02(火) 03:16:15.56ID:??? 管理上のオーバーヘッドってのがユーザ側の話なのかシステム側の話なのかしらんが 関数オーバーロードができたとして、それがビューより管理が重いとか信じられん
会計年度が必要ならそう言うビュー作れ、で終わりじゃないのか 0247NAME IS NULL2017/05/02(火) 08:24:38.84ID:??? 一方ロシアは会計年度カラムを追加した 0248NAME IS NULL2017/05/02(火) 10:00:08.57ID:??? インデックス張るなら、ロシア方式が一番いいよな トリガーで仕掛けておけば気にしなくて済むし 0249NAME IS NULL2017/05/02(火) 10:17:39.11ID:???>>239 > インデックスは必要ならはればいい 本末転倒だな 普通にクエリ書けばインデックス使えるのに、ストアドにしようと思うとさらに何かしないといけなくなる つか、ストアドの結果にインデックス貼れないDBもあるんじゃね? 0250NAME IS NULL2017/05/02(火) 10:22:47.67ID:???>>239 > asで名前つけとけばgroup byでは繰り返す必要ないよ その手段が使えるDBでは、>>232も同じことが言える
> 毎回展開しなきゃいけない状態では全く意味が違うんだけどね 例えば四半期ごとの集計がほしいとか、移動平均がほしいとかいうことになったら、 そのたびにストアド作るのか? 増殖しまくりだな 0251NAME IS NULL2017/05/02(火) 10:26:43.28ID:??? ん? >>232 だとインデックス使われないだろ >>217-218>>185 のような関数だともっと使われない >>182 のように or あると、うまく使ってくれるか怪しい 0252NAME IS NULL2017/05/02(火) 10:38:44.85ID:???>>251 > ん? >>232 だとインデックス使われないだろ where書いてないからね >>232は、集計がしんどいという奴へのレス
>>182 のように or あると、うまく使ってくれるか怪しい 大抵のRDBMSだったらうまく使ってくれるんじゃね? 0253NAME IS NULL2017/05/02(火) 10:44:41.29ID:??? それより決算月が変わる可能性について考えたほうがいいと思う 0254NAME IS NULL2017/05/02(火) 10:45:38.57ID:???>>251 > >>217-218>>185 のような関数だともっと使われない こういうバカ避けのためにわざわざ「性能は知らん」って書いてあるのにバカはそれすら理解できないんだな w インデックス使いたいならdate型にしとけよ 0255NAME IS NULL2017/05/02(火) 10:49:15.47ID:???>>253 会計年度カラム追加で解決。 0256NAME IS NULL2017/05/02(火) 10:51:13.38ID:???>>254 year, monthにインデックス張ればいいだろ アホか 0257NAME IS NULL2017/05/02(火) 11:01:20.42ID:??? ビューのコストが高いというのがparserの話だとしたら、単純なビューなら最近では全く問題にならない まぁ、大抵の場合、クエリ1回につき+1ms未満だろう。 (さらには、直近のparse結果をcacheしている場合もある) 0258NAME IS NULL2017/05/02(火) 11:03:21.36ID:???>>256 > year, monthにインデックス張ればいいだろ
インデックス張っても関数の引数にしちゃったら使われない 0259NAME IS NULL2017/05/02(火) 15:49:34.57ID:???>>256 バカってこれだから... 複数の列に張るより単一の方が有利だろう そんなことも理解できないのかよ w 0260NAME IS NULL2017/05/02(火) 16:00:26.84ID:??? そんな理由だったらオレもアンタをバカ呼ばわりしていいかな 0261NAME IS NULL2017/05/02(火) 16:16:34.86ID:???>>260 理由が書けるならね 0262NAME IS NULL2017/05/02(火) 17:11:25.84ID:??? 不利っつっても、比較が1回か2回かって違いくらいしかないだろ。 0263NAME IS NULL2017/05/02(火) 17:17:06.13ID:??? ここを2つに分けるかどうかの是非はともかく キーが2つになるから絡むつにしようとかおかしいだろw
まあこのケース、月なんて12通りしか無いんだし複合キーで 0264NAME IS NULL2017/05/02(火) 18:48:29.70ID:??? >複数の列に張る
こういう言い方しているところを見ると、複合インデックスの仕組みをわかってないんだろう。 0265NAME IS NULL2017/05/02(火) 18:57:10.84ID:??? yearのインデックスとmonthのインデックスを別々に張りそう 0266NAME IS NULL2017/05/02(火) 19:11:26.98ID:???>>250 >その手段が使えるDBでは、>>232も同じことが言える そんなんわざわざ言わんでもわかっとるがな〜ww