0182NAME IS NULL2017/04/26(水) 22:08:23.58ID:??? (year=2017 and month>=4) or (year=2018 and month<=3)でいいだろ 0183NAME IS NULL2017/04/26(水) 22:54:12.56ID:??? IIf(Month<4,Year-1,Year) AS 会計年度 見たいなカラム持ったクエリ定義しとけよ 01841832017/04/26(水) 22:57:19.84ID:??? あ、なぜかACCESSだと思ってたw 標準的なSQLならCASEでビューか
まあ、わかるだろ 0185NAME IS NULL2017/04/27(木) 04:56:49.99ID:???>>179 性能は知らん where make_date(year, month, 1) between '2017-04-01' and '2018-03-31' 0186NAME IS NULL2017/04/27(木) 07:07:55.94ID:???>>182 自分もこれだな 0187NAME IS NULL2017/04/27(木) 09:29:25.83ID:??? 日付を分割してintに入れる糞実装、未だに存在するのかよ 0188NAME IS NULL2017/04/27(木) 10:38:00.97ID:??? 日付じゃなくて必要なのが月までだからだろ 0189NAME IS NULL2017/04/27(木) 10:55:10.08ID:??? それでも /01 にしてdate型に突っ込むわ 0190NAME IS NULL2017/04/27(木) 12:24:41.45ID:??? どうでもいいけど言うならせめて糞設計だよね 実装てw 0191sage2017/04/27(木) 15:25:55.19ID:JuRKhktP 設計:年・月を保存する 実装:年・月を別カラムにする 0192NAME IS NULL2017/04/27(木) 15:38:14.45ID:??? 質問者への回答と、設計の改善提案は別だろうに 0193NAME IS NULL2017/04/27(木) 16:00:01.62ID:??? number(8)に日付いれるのが好きなフレンズもいるな 0194NAME IS NULL2017/04/27(木) 16:08:50.03ID:???>>193 難点は経過日数計算が大変な 0195NAME IS NULL2017/04/27(木) 17:08:47.17ID:??? 俺は >>180 支持だなぁ 速度的にも見た目的にも 0196NAME IS NULL2017/04/27(木) 18:52:05.48ID:???>>180 会計年度中も指定できるので非常に参考になりました
他の方法も含めご教示ありがとうございます 0197NAME IS NULL2017/04/27(木) 18:59:16.96ID:??? 年月を保持する要件で、データに意味を持たない日の情報が含まれるって、良いのでしょうか
バグを産む可能性を秘めてるような 0198NAME IS NULL2017/04/27(木) 19:31:38.84ID:???>>197 あり得ない月とかを突っ込める方が恐いわ 0199NAME IS NULL2017/04/27(木) 19:39:19.72ID:QZ3/RiVo>>198 そんなもんなんぼでもあるわwお前ビビりすぎw 0200NAME IS NULL2017/04/27(木) 19:54:14.57ID:??? バカが現れた 0201NAME IS NULL2017/04/27(木) 20:18:45.26ID:???>>199のレスの意味がわからなすぎる 0202NAME IS NULL2017/04/27(木) 20:19:31.22ID:??? バグというより、データベースに事実にない情報を含めるとか違和感が 0203NAME IS NULL2017/04/27(木) 20:44:47.72ID:??? numberでもバグを産む可能性を秘めてるし どっちのリスクをとるかだけじゃね 0204NAME IS NULL2017/04/27(木) 21:33:38.32ID:??? 年月のみを管理したいっていう場合に ・日付としての正当性は保証されるけど不要な日の情報を持つ ・日付としての正当性は保証されないけど不要な情報を持たない のどちらがいいか? って話でしょ 個人的にはデータの正当性の方を重視するかな 0205NAME IS NULL2017/04/28(金) 07:06:33.42ID:??? そして2017/4/1と2017/4/2など 同一年月で複数レコードできてしまうのでした 0206NAME IS NULL2017/04/28(金) 07:18:39.77ID:??? 年月情報をユニーク制約を保持する仕様で日付計算のためにdate使ってたら、皆さんはどう思いますか 0207NAME IS NULL2017/04/28(金) 10:47:01.79ID:??? もうUNIQUE制約のある年月列と日付計算用の列を分けろよ 0208NAME IS NULL2017/04/28(金) 11:33:54.87ID:??? レコードの入力時に日付が何入っていようと、1にしてしまえば良いだけだろう 0209NAME IS NULL2017/04/28(金) 12:16:53.71ID:??? そんなもん制約がなければ全く信用できん 本当に頭が悪いなお前ら 0210NAME IS NULL2017/04/28(金) 13:33:21.87ID:???>>205 2017/00 とか 2017/13 とか入ってるのとどっちがいい? 0211NAME IS NULL2017/04/28(金) 15:57:28.27ID:??? DB側の制約がいかに利用されていないか分かるな 0212NAME IS NULL2017/04/28(金) 18:48:18.70ID:??? 1日の0時になっているか確認するcheck制約つければいい 0213NAME IS NULL2017/04/28(金) 20:51:04.78ID:??? そもそもカラムが年と月別なんだからcheck制約でもMonth>=1 and Month<=12でいいから簡単だろ プログラムも同様 まさか日付を変換して1日かとかやるとか? いらない情報付与からして、そんなのうちでは許されないわw 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