板検索:
SQL質疑応答スレ 17問目 (664)
まとめビュー
重複読み込みスレ:このスレは、2重読み込みでレスが重複している可能性があります。修復する場合はこちらをクリックしてください。
1
NAME IS NULL[sage]   投稿日:2016/07/10 22:29:01  ID:???.net(298)
このスレは
「こういうことをやりたいんだけどSQLでどう書くの?」
「こういうSQLを書いたんだけどうまく動きません><」
などの質問を受け付けるスレです。

SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。

質問するときはDBMS名を必ず付記してください。

【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明

前スレ:
SQL質疑応答スレ 16問目
コメント4件


2
NAME IS NULL[sage]   投稿日:2016/07/10 22:29:31  ID:???.net(298)

3
NAME IS NULL[sage]   投稿日:2016/07/10 22:30:30  ID:???.net(298)

4
NAME IS NULL[sage]   投稿日:2016/07/10 22:30:52  ID:???.net(298)
よくある質問1

(問)
ID | DATE     | DATA
--+----------+-----
1 | 2007-11-11 | aaa
2 | 2007-11-11 | bbb
1 | 2007-11-10 | ccc
3 | 2007-11-12 | ddd
3 | 2007-11-11 | eee
4 | 2007-11-10 | fff
1 | 2007-11-12 | ggg

このようなテーブルから、下記のように

1 | 2007-11-12 | ggg
3 | 2007-11-12 | ddd
2 | 2007-11-11 | bbb
4 | 2007-11-10 | fff

各idに対して最新の1件だけ抽出するSQLの書き方を教えてください。

(答)
select A.ID,
    A.DATE,
    A.DATA
from TableName A
   inner join
   (select ID, max(DATE) as MAX_DATE
    from TableName
    group by ID
   ) B
   on A.ID = B.ID
   and A.DATE = B.MAX_DATE
;

5
NAME IS NULL[sage]   投稿日:2016/07/10 22:31:14  ID:???.net(298)
よくある質問2

(問)
key   data
----------------
1     a
1     a
1     b
1     b
1     a
2     b
2     a
2     a

というテーブルから

key   a   b
--------------------
1    3   2
2    2   1

というExcelのピボットの様なデータを取得したいのですが、どういうSQLになりますか?
a,bというのは固定なので、仮にcというデータがあっても無視して構いません。

(答)
SELECT key,
    SUM(CASE data WHEN 'a' THEN 1 END) AS a,
    SUM(CASE data WHEN 'b' THEN 1 END) AS b
FROM table
GROUP BY key
ORDER BY key
;

6
NAME IS NULL[sage]   投稿日:2016/07/10 22:34:14  ID:???.net(298)
よくある質問3

(問)
ID HOGE
01 A
01 B
01 C
02 A
03 B

HOGEをAもBもCも持っている、ID:01だけ取り出すにはどうすればよかですか

(答1)
SELECT id
FROM TableName
WHERE hoge in ('A','B','C')
GROUP BY id
HAVING count(DISTINCT hoge) = 3
;

(答2)
select *
from TableName T1
where not exists (select *
         from (values 'A', 'B', 'C') T2 (HOGE)
         where not exists (select *
                  from TableName T3
                  where T1.ID = T3.ID
                  and T2.HOGE = T3.HOGE
                  )
         )
;
※valuesの部分(Table Value Constructor)はDBMSによって文法がかなり違うので注意

7
NAME IS NULL[sage]   投稿日:2016/07/10 22:34:59  ID:???.net(298)
よくある質問4

(問)
列の数が可変な問合せはどう書きますか?

(答)
標準SQLでは書けません。
pivotという機能を搭載したDBMSなら一見書けそうですが実はやっぱり書けません。
Oracle 11g以降でpivot xmlというキーワードを使用すれば一応可変っぽくはなります。
が、素直にプロシージャを書くかアプリケーションで処理したほうが良いでしょう。

SQL Serverのpivot(2005以降)
http://msdn.microsoft.com/ja-jp/library/ms177410.aspx

Oracleのpivot(11g以降)
http://download.oracle.com/docs/cd/E16338_01/server.112/b56299/statement...#CHDCEJJE
http://www.oracle.com/technetwork/articles/sql/11g-pivot-097235.htm...

8
NAME IS NULL[sage]   投稿日:2016/07/10 22:46:13  ID:???.net(298)
ううむ、ブロックされてしまいました。どうしたらいいだろう。

Why have I been blocked?

This website is using a security service to protect itself from online attacks.
The action you just performed triggered the security solution.
There are several actions that could trigger this block including submitting a
certain word or phrase, a SQL command or malformed data.

9
NAME IS NULL[sage]   投稿日:2016/07/10 22:47:49  ID:???.net(298)
SQLソースの部分は外しておきます。

よくある質問5

(問)
年月(YYYYMM)を指定し、その年月に対応する年月日を取得したい

 例:201006を指定したら、以下の結果を得たい

   20100601
   20100602
    ・
    ・
    ・
   20100630

(答)
SQLでは存在しないデータを生成することはできません。
この問いの場合は素直にカレンダーテーブルを用意しましょう。

どうしてもやりたければ以下のような方法もなくはないですが、
再帰問合せの本来の使い方ではありません。
やめておくことを強くお奨めします。
(PostgreSQLのgenerate_series()関数なら辛うじてセーフかもしれませんが
 賛否の分かれるところでしょう。)


10
NAME IS NULL[sage]   投稿日:2016/07/10 22:49:00  ID:???.net(298)
以上、テンプレ終わり

よくある質問5のSQLソース部分がアタックと受け止められてしまいました。
そのためソースは省略しました。

11
NAME IS NULL[sage]   投稿日:2016/07/14 01:37:12  ID:???.net(298)
ここで募集するのも筋違いだとおもうけど、SQLの文を書いたのを訂正してほしい・・・
中級者には30分ほどでおわる内容かも。
謝礼は7000で、
多分、チョー簡単。
詳しくは
remorse2015@yahoo.co.jp
日曜までとりあえず募集します。
メールで内容確認だけでも良いです/

12
NAME IS NULL[sage]   投稿日:2016/07/14 03:19:38  ID:???.net(298)
ここに内容書けば無料なんだけど
コメント2件

13
NAME IS NULL[sage]   投稿日:2016/07/15 02:26:47  ID:???.net(298)
>12
お願いできないですか?
ワードに見本表と完成表があってコード書かれているんですが、間違えてる文がある感じです。22ページあったんですが16から全然進まなくて、、、
とりあえず、メールお願いします。
ワードファイル添付しておくります。
支払いはすぐやります。

14
NAME IS NULL[sage]   投稿日:2016/07/15 09:39:41  ID:???.net(298)
プレーンテキストでここに貼って

15
NAME IS NULL[sage]   投稿日:2016/07/15 10:18:31  ID:???.net(298)
ワードファイル送りつけられても迷惑メールからのゴミ箱インよ

16
NAME IS NULL[sage]   投稿日:2016/07/15 11:41:49  ID:???.net(298)
SELECT *
FROM 氏名表 AS A
WHERE A.番号=
(SELECT 番号
FROM 成績表
WHERE 点数=479)


SELECT *FROM 氏名表 AS A
WHERE A.番号IN
(SELECT 番号
FROM 成績表
WHERE 点数>=500)
という間違った文があって
SELECT *
FROM 氏名表 AS A
INNER JOIN
(SELECT 番号
FROM 成績表
WHERE 点数=479) AS B
ON A.番号=B.番号

SELECT *
FROM 氏名表 AS A
INNER JOIN
(SELECT 番号
FROM 成績表
WHERE 点数>=500) AS B
ON A.番号=B.番号
を治すというものでこんなのを20個くらいやれば終わりです。
コメント2件

17
NAME IS NULL[sage]   投稿日:2016/07/15 13:52:48  ID:???.net(298)
金もらって引き受けるほどの仕事じゃないようだし
そういう手間かけるくらいなら、ご自身で治した方が良いのでは?

18
NAME IS NULL[sage]   投稿日:2016/07/15 14:14:56  ID:???.net(298)
> SELECT *FROM 氏名表 AS A
> WHERE A.番号IN
> (SELECT 番号
> FROM 成績表
> WHERE 点数>=500)

これは何が間違ってるんだ?
コメント2件

19
NAME IS NULL[sage]   投稿日:2016/07/15 14:20:47  ID:???.net(298)
要件を教えて欲しいのだが。何を直せばいいいんだ?

20
NAME IS NULL[sage]   投稿日:2016/07/15 15:30:39  ID:???.net(298)
>16
inをjoinに置き換えろって話のようにみえるけど
joinしたビュー作っとけばもっと楽かもしれんぞ

そもそもそんなことする必要があるのか
一度inとjoinで実行計画見といた方が良いんじゃね

>18
文法的に間違ってるってなら、番号とINの間に空白がないとかじゃねw

21
NAME IS NULL[]   投稿日:2016/07/15 15:46:23  ID:zBhn779u.net(6)
これについてはインラインビュー(FROM句の副問い合わせ)はやめた方がいいな。

WHERE句で絞った方がいい。
コメント2件

22
NAME IS NULL[sage]   投稿日:2016/07/15 16:18:18  ID:???.net(298)
同感

23
NAME IS NULL[sage]   投稿日:2016/07/15 16:41:58  ID:???.net(298)
実行計画見るまでもないレベルのデータ量な気がするが。
何やっても数百ms程度で戻る気が。
コメント2件

24
NAME IS NULL[sage]   投稿日:2016/07/15 16:57:08  ID:???.net(298)
>21
その理由は?
単なる性能的な話なら、まず実行計画見るよって事だし

whereがどうこうじゃなくて、inの方だと、結果セットに点数含まれないのが問題なんじゃないのか

>23
データ量は示されてないし、実際のテーブルレイアウトがどうなってるかもわからんし
まあ、性能的な問題じゃないと思うけど
コメント6件

25
NAME IS NULL[sage]   投稿日:2016/07/15 17:22:52  ID:???.net(298)
>24
> データ量は示されてないし、実際のテーブルレイアウトがどうなってるかもわからんし
> まあ、性能的な問題じゃないと思うけど
氏名表:1,000レコード未満
成績表:100,000レコード未満
くらいかなと。

まあどんなクエリ書こうがたいしたことないと思うが、性能云々ならindexを貼るくらいでいいのでは。

26
NAME IS NULL[]   投稿日:2016/07/15 18:52:57  ID:OwU9VU0D.net(4)
答えたい気持ちは分かるがお前ら7000円をどうやって分けるつもりなの?
そういう事は最初にキッチリ決めとかないと後々遺恨を残すぜ

27
NAME IS NULL[sage]   投稿日:2016/07/15 19:15:33  ID:???.net(298)
僕のために争ってくれてありがとう。
依頼する人は見つけたから大丈夫だよー
これで単位も一安心

28
NAME IS NULL[]   投稿日:2016/07/15 19:51:07  ID:zBhn779u.net(6)
>24
理由も何もまずはSQLの普通の書き方しろってことだよ。

29
NAME IS NULL[]   投稿日:2016/07/15 19:53:41  ID:zBhn779u.net(6)
>24
INリストには数の制限があるからな。

OR条件の羅列にすぎない。
コメント2件

30
NAME IS NULL[]   投稿日:2016/07/15 20:33:15  ID:OwU9VU0D.net(4)
>29
お前はバカなんだから口を慎しめと何度
コメント2件

31
NAME IS NULL[]   投稿日:2016/07/16 17:02:32  ID:IKSp3mrg.net(4)
>30
どこが間違っているのか教えてください。

32
NAME IS NULL[]   投稿日:2016/07/16 17:08:06  ID:IKSp3mrg.net(4)
↓これ何?

26 NAME IS NULL 2016/07/15(金) 18:52:57.55 ID:OwU9VU0D
答えたい気持ちは分かるがお前ら7000円をどうやって分けるつもりなの?
そういう事は最初にキッチリ決めとかないと後々遺恨を残すぜ

33
NAME IS NULL[]   投稿日:2016/07/17 21:52:20  ID:N1m3wNQ4.net(4)
すみません、以下、質問させてください。

親テーブルAに対して子テーブルBとCがあり、
レコード数がそれぞれ、
A:B = 1:5、A:C = 1:20 の関係です。

この時、A1レコードに対して、
Aに紐付くBとCのレコード全てを最小のIO回数・データ量で取得したいです。

普通にA、B、Cを結合しただけでは
B×Cの組み合わせまで取得してしまい上手く取得できませんでした。
A:B、A:Cと別々に結合して取得するしかないのでしょうか。
DBはOracleです、よろしくお願いします。
コメント2件

34
NAME IS NULL[]   投稿日:2016/07/17 22:41:52  ID:2o6ZRKeT.net(2)
>33
リレーションの説明がありませんので、答えようがありません。
コメント2件

35
NAME IS NULL[sage]   投稿日:2016/07/17 22:58:48  ID:???.net(298)
B×Cの中から自分が欲しいものを条件で絞り込むんだよ。その条件が無いから全部出てくる。

36
NAME IS NULL[]   投稿日:2016/07/17 23:00:32  ID:N1m3wNQ4.net(4)
>34
下のような感じです。
AとB、AとCが主キー項目aでそれぞれ1:5、1:20で紐付きます。

Aテーブル
a C(5)


Bテーブル
a C(5)
b C(5)


Cテーブル
a C(5)
c C(5)

コメント4件

37
NAME IS NULL[]   投稿日:2016/07/17 23:02:11  ID:fmLQHPFo.net(2)
おもしろい展開w

38
NAME IS NULL[sage]   投稿日:2016/07/17 23:41:31  ID:???.net(298)
質問がいまいち理解できん
そもそもIOとか、SQL書いたとおりに実行されるわけじゃないんだが

ほしい結果がABとACの二つあるなら、2回やるしかないわけだが、どんな結果を望んでるんだ
コメント2件

39
NAME IS NULL[]   投稿日:2016/07/18 00:53:22  ID:EKBnHgrJ.net(10)
>38
俺もI/Oについては突っ込みたかったが、そもそもRDBの理論、概念を否定する内容だからスルーしたw
コメント2件


40
NAME IS NULL[]   投稿日:2016/07/18 00:55:52  ID:EKBnHgrJ.net(10)
>36
その"C(5)"って何?

データ型?

41
NAME IS NULL[]   投稿日:2016/07/18 01:03:46  ID:EKBnHgrJ.net(10)
>36
その3つのテーブルをaという列だけで結合すればいい話なのかな?

Aテーブルの1レコードに対して20レコードがセットになればいいの?

42
NAME IS NULL[]   投稿日:2016/07/18 01:12:13  ID:EKBnHgrJ.net(10)
BテーブルとCテーブルにリレーション、関連性があるのかないのかはっきりしてくれ。

AテーブルのとあるレコードはBテーブルに子レコードがあり、Aテーブルの別の種類のレコードはCテーブルに子レコードがあるようにも解釈できる。

どっちなの?

43
NAME IS NULL[sage]   投稿日:2016/07/18 01:17:58  ID:???.net(298)
unionの話じゃないのかい

44
NAME IS NULL[]   投稿日:2016/07/18 03:30:28  ID:Dk5LLrvU.net(4)
>39
RDBの理論が分かってないのはお前な
コメント2件

45
NAME IS NULL[]   投稿日:2016/07/18 06:25:57  ID:EKBnHgrJ.net(10)
>44
それはRDBMSのことであって特定の製品を指しているわけでもない。
コメント2件

46
NAME IS NULL[]   投稿日:2016/07/18 08:25:50  ID:Dk5LLrvU.net(4)
>45
ワケ分からん事言ってないで必死でググって顔真っ赤にして感謝しろよw
今頃もう真っ赤っ赤かなw

47
NAME IS NULL[]   投稿日:2016/07/19 00:50:27  ID:yVILcX3x.net(2)
RDBMSはSQLの処理の方法にRDBMSに任せるのがRDBなんだよ。

どう処理するかの手続きを指定するのはするのはRDBではない。

48
NAME IS NULL[sage]   投稿日:2016/07/19 03:30:05  ID:???.net(298)
とりあえず書き込む前に書こうまず読み直してとりあえず書こう

49
NAME IS NULL[sage]   投稿日:2016/07/19 04:19:10  ID:???.net(298)
慌てないで、落ち着いて

50
NAME IS NULL[]   投稿日:2016/07/20 11:14:56  ID:89VCRaWj.net(2)
【BS11:エンターテイメント】 <関根勤 KADENの深い夜>放送時間:毎週木曜日 よる11時00分〜11時30分 #bs11 http://www.bs11.jp/entertainment/5749/

51
NAME IS NULL[sage]   投稿日:2016/07/24 10:41:37  ID:???.net(298)

52
NAME IS NULL[]   投稿日:2016/07/27 21:37:51  ID:OesecO5v.net(4)
ジョインで連結しまくったクエリに
ORDER BY で並び替えかけると
えらい遅くなるのですが
改善する方法はないのでしょうか?

53
NAME IS NULL[sage]   投稿日:2016/07/27 21:48:05  ID:???.net(298)
ジョインしたかどうかとソートの速度に関係はない
ソートのキーとなる列にインデックスを張っておけばソートが不要になる場合がある
ソートキーが複数のテーブルに跨るとすると話は面倒臭い
VIEWにインデックスを張れるDBMSならそれで解決するのも手
コメント2件

54
NAME IS NULL[sage]   投稿日:2016/07/27 21:58:01  ID:???.net(298)
的確。

55
NAME IS NULL[]   投稿日:2016/07/27 22:33:44  ID:OesecO5v.net(4)
>53
インデックスの貼り方がわるいのか
リレーションに関するカラムを中心に
インデックスはっても遅いんです。
特に GROUP BY と ORDER BY の組みあわせ

56
NAME IS NULL[sage]   投稿日:2016/07/27 22:52:26  ID:???.net(298)
GROUP BYもあるならmaterialized viewにしてインデックス張るしかないかな
メモリをひたすら積んでメモリソートでごり押しという手もあるが

57
NAME IS NULL[sage]   投稿日:2016/07/27 23:13:51  ID:???.net(298)
テーブルレイアウトと実行してるSQL全部書けば
ある程度汎用的なインデックスのアドバイスができるかもしれんが

まあとりあえず実行計画確認しろ

58
NAME IS NULL[sage]   投稿日:2016/07/27 23:27:08  ID:???.net(298)
【質問テンプレ】
・DBMS名とバージョン

この辺も書いておくといいぞ

59
NAME IS NULL[]   投稿日:2016/07/28 00:48:24  ID:Pc5r9mq6.net(2)
テーブルレイアウトって言葉はやめてほしいわ。

60
NAME IS NULL[sage]   投稿日:2016/07/28 10:49:25  ID:???.net(298)
うちのダイニングのテーブルの配置はどう言ったらいいでしょうか

61
NAME IS NULL[sage]   投稿日:2016/07/28 14:59:33  ID:???.net(298)
 
粗大ゴミの回収に出す

62
NAME IS NULL[]   投稿日:2016/07/29 09:54:35  ID:SbaxQ6kv.net(2)
MySQL 5.1.73
次のようなカラムの入ったメインテーブルがあるとします。

T1
|MAIN_ID|NAME|AGE|TITLE_1|COMMENT_1|TITLE_2|COMMENT_2|

で、TITLE と COMMENT の部分は
横持ちになってるのでその部分は別テーブルにして

T2
|ID|MAIN_ID|TITLE|COMMENT|

として、縦持ちにしたいとします。

問題は、この2つのテーブルをどうリレーションさせるかです。
例えば 次のようなレコードが入っているものを次のようにリレーションしようとします。

T1
|MAIN_ID|NAME|AGE|
|1    |田中 |24|



T2
|ID|MAIN_ID|TITLE|COMMENT|
|1 |   1|好きな|うな重 |
|2 |   1|趣味 |バイク |
|3 |   1|嫌いな|しいたけ|
|4 |   2|好きな|グラタン|


FROM
 T1
 LEFT JOIN
 T2
 ON
 T1.MAIN_ID = T2.MAIN_ID

で関連付けられ 

|ID|MAIN_ID|NAME|AGE|TITLE|COMMENT|
|1 |1   |田中 |24|好きな|うな重 |
|1 |1   |田中 |24|趣味 |バイク |
|1 |1   |田中 |24|嫌いな|しいたけ|

この例で行くと田中が3つになります。
また、 WHERE でTITLE、COMMENTが検索対象にできるようになります。

10件表示とか リストで出力すると この例では田中が3つでてきてしまうので
GROUP BY で ID をまとめます。 
その際 ORDER BYをかけると 何千件とかになると
パフォーマンスが非常に落ちてしまいます。
※ ORDER BYがなければパフォーマンスはそれほど問題はありません。

パフォーマンスをなるべく落ちないように
縦持ちカラムを組み合わせるにはどうすればいいでしょうか?

63
NAME IS NULL[sage]   投稿日:2016/07/29 10:09:10  ID:???.net(298)
それだとGROUP BYよりEXISTSのほうがよくね?

select T1のカラム
from T1
where exists (
  select *
  from T2
  where T1.MAIN_ID = T2.MAIN_ID
  and T2の条件
)
order by T1のカラム

64
NAME IS NULL[sage]   投稿日:2016/07/29 14:04:30  ID:???.net(298)
>62
>GROUP BY で ID をまとめます。
それだとIDと1:1に結び付かない項目は全て不定だぞ
つまり結局T1のみselectするのと同じになるわけだが
それならまずはT1のソート項目にインデックス張って見るとか

ああ、またMySqlか
SelectとGruop ByとOrder ByとWhereと全部書いたフルのSQL晒せ

65
NAME IS NULL[]   投稿日:2016/07/30 07:56:46  ID:XyUbordV.net(2)
ない項目のインデックスはどうやって作るのか

66
NAME IS NULL[sage]   投稿日:2016/07/30 08:19:54  ID:???.net(298)
ない項目ってどういう意味だ?
インデックスは項目(の組み合わせ)に対して作るものだぞ

67
NAME IS NULL[sage]   投稿日:2016/07/31 02:18:28  ID:???.net(298)
質問です。
学生メール表 学籍番号 氏名 メールアドレス
教員メール表 教員番号 氏名 メールアドレス
補習予定表 教員番号 授業id 日付 連絡事項
授業名表 授業iD 授業名
授業展開表 教員番号 授業id 学籍番号
これで生徒に知らせる時のER図をつくるとき、
いらない情報はどれですか?
学生メール表⇔授業中展開表⇔授業名表⇔補習予定表
コメント6件

68
NAME IS NULL[sage]   投稿日:2016/07/31 09:46:00  ID:???.net(298)
>67
自分で決める事では

69
NAME IS NULL[]   投稿日:2016/07/31 12:33:09  ID:ea2io0T3.net(2)
>67
必要最低限にしてもいいけど、実際にはいちいち結合しないと取得できないので重複して持つこともある。

70
NAME IS NULL[sage]   投稿日:2016/07/31 14:20:50  ID:???.net(298)
ちなみに>67はおかしいですか?
先生にしらせるときと生徒に知らせる時でER図を書きなさいって問題なんですが

71
NAME IS NULL[sage]   投稿日:2016/07/31 16:02:20  ID:???.net(298)
問題に書いてあることを誤読や読み落とししている気がする。

72
NAME IS NULL[sage]   投稿日:2016/07/31 17:31:55  ID:???.net(298)
宿題を堂々とここに書いて教えろと要求かぁ

73
NAME IS NULL[sage]   投稿日:2016/07/31 21:26:13  ID:???.net(298)
まずER図書いてみろって話だが

エスパーすると授業展開表.教員番号か補習予定表.教員番号

各テーブルの主キーが不明なんでどっちにしろ正確な答えはだぜんぞ

74
NAME IS NULL[sage]   投稿日:2016/08/08 22:56:12  ID:???.net(298)
・DBMS名とバージョン
 SQLServer2014 ent.

・テーブルデータ
 名前 月 欠席日数
 a    1     1
 a    3     1
 b    1     1

・欲しい結果
 名前 月 欠席日数
 a    1     1
 a    2     0
 a    3     1
 b    1     1
 b    2     0
 b    3     0

・説明
 欠けてる月のデータを 0 補完したいと思います。
 「名前」列がなければ例えば下のようなテーブルと外部結合することで解決できるのですが、
 「名前」ごとに「月」と「欠席日数」を補完する方法が分かりません。
 「名前」列を含めて保管用のテーブルを作ることも考えられるのですが、「名前」の数が多い場合に困ります。
 月 欠席日数
 1     0
 2     0
 3     0

お知恵をお貸し下さい。
お願いします。
コメント2件

75
NAME IS NULL[sage]   投稿日:2016/08/08 23:54:36  ID:???.net(298)
名前テーブルも作ってそれと外部結合すりゃいいじゃん。
コメント2件

76
NAME IS NULL[sage]   投稿日:2016/08/09 00:00:01  ID:???.net(298)
id,name
--------
1,aaa
2,bbb
3,ccc

これにdddを1の下に追加して

id,name
--------
1,aaa
4,ddd
2,bbb
3,ccc

という風に出来るデータベースってありませんか? 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

コメント4件

77
NAME IS NULL[sage]   投稿日:2016/08/09 01:13:18  ID:???.net(298)
表示をその順序にしたいと言うなら、
その順序指定になるカラムを追加したら?
コメント2件

78
NAME IS NULL[sage]   投稿日:2016/08/09 08:40:05  ID:???.net(298)
>76
> これにdddを1の下に追加して

できない
上とか下の概念がないから

79
NAME IS NULL[sage]   投稿日:2016/08/09 09:32:25  ID:???.net(298)
mysqlでやってみた

select id , name ,
case name when "aaa" then 1
when "bbb" then 3
when "ddd" then 2
when "ccc" then 4
end as newcol
from hogehoge
order by newcol;

+----+------+---------+
| id | name | newcol |
+----+------+---------+
| 1 | aaa | 1 |
| 4 | ddd | 2 |
| 2 | bbb | 3 |
| 3 | ccc | 4 |
+----+------+---------+

結局は>77さんの通りにやってるだけだし、件数が多ければやってられんw

80
NAME IS NULL[sage]   投稿日:2016/08/09 10:03:52  ID:???.net(298)
select id , name ,
case name
when "aaa" then 1
when "ddd" then 2
else null
end as newcol
from hogehoge
order by newcol is null;

81
NAME IS NULL[sage]   投稿日:2016/08/09 18:34:23  ID:???.net(298)
>74
普通は名前のマスタテーブル用意しとくんじゃね
まあ、なければないで効率とか考えないなら
select distinct 名前 from ...
とかで代用できなくもないけど

>76
すくなくとも、RDBでそれは基本的な考え方から外れてるから無理

データ補完とか、順序付けされてないデータの順序とか、設計考え直せ

82
74[sage]   投稿日:2016/08/09 23:16:58  ID:???.net(298)
>75,81
ありがとう。
75 で言われてハッとして distinct で作った名前の一覧と月の一覧とを掛け合わせて、
これと元のテーブルデータを外部結合して行けました。

83
NAME IS NULL[]   投稿日:2016/08/10 16:43:00  ID:tK4Szt1X.net(2)
SQLと直接関係ないのですが
お名前.comSDサーバーの データベースって
sshで入って dumpコマンドでエクスポートできないので
バックアップを取ることができないのですが
なにかうまく取る方法ないですか?
コメント2件

84
NAME IS NULL[sage]   投稿日:2016/08/10 16:49:54  ID:???.net(298)
>83
お名前.com sdサーバー データベース バックアップ
でググったらすぐに見つかったが?

85
NAME IS NULL[sage]   投稿日:2016/09/24 02:19:33  ID:???.net(298)
○前提
会社id、名前や所在地などが入っている会社テーブルと、
会社id、従業員名、性別などが入っている従業員テーブルがあるとして、
(プログラム側で外部から受け取った)会社idから名前や所在地を得て、かつ、その会社の従業員を列挙表示したい

○質問
こういうとき、DB側、SQL側としては、会社テーブル・従業員テーブルそれぞれ1回ずつ2回SELECT発行するしかないでしょうか
コメント10件

86
NAME IS NULL[sage]   投稿日:2016/09/24 03:18:01  ID:???.net(298)
>85
joinを知らないとか分からないとか、そういうレベル?
とりあえず>1読んで出直して
コメント2件

87
NAME IS NULL[sage]   投稿日:2016/09/24 03:54:37  ID:???.net(298)
>86
joinすると全レコードに>85で言う会社テーブルの名前、所在地などが入ってきませんか
返してもらうデータ量よりクエリ発行回数を気にするべきなんでしょうか

また>85には書いていないことですがjoin対象が複数あったら、など考えるとどう考えたら良いのか
コメント2件

88
NAME IS NULL[sage]   投稿日:2016/09/24 07:52:00  ID:???.net(298)
>join対象が複数あったら、

複数joinすれば?

89
NAME IS NULL[sage]   投稿日:2016/09/24 11:06:44  ID:???.net(298)
深く考える前にやってみればいいんじゃないかな、とか。

90
NAME IS NULL[sage]   投稿日:2016/09/24 18:45:29  ID:???.net(298)
>87
>データ量よりクエリ発行回数を気にするべきなんでしょうか
そんなもんはケースバイケースだからすきにしろ
もともとクエリ発行回数を問題にしたのはお前だろうが

91
NAME IS NULL[sage]   投稿日:2016/09/24 21:03:47  ID:???.net(298)
>85
その前提なら
> 会社テーブル・従業員テーブルそれぞれ1回ずつ2回SELECT発行する
でいいと思う

92
NAME IS NULL[sage]   投稿日:2016/09/24 21:21:17  ID:???.net(298)
いや、1回SELECT発行がいいと思う

93
NAME IS NULL[]   投稿日:2016/09/24 21:23:50  ID:dG2/rE9U.net(2)
この場合それぞれ2回ずつSELECTが正解じゃね?
コメント2件

94
NAME IS NULL[sage]   投稿日:2016/09/25 07:15:27  ID:???.net(298)
従業員に付与される会社情報の多さが気になるなら2回でいいんじゃね
というか自分も2回だね

95
NAME IS NULL[sage]   投稿日:2016/09/25 08:00:17  ID:???.net(298)
>93
2回ずつ?
なんのために?

96
NAME IS NULL[sage]   投稿日:2016/09/25 09:14:27  ID:???.net(298)
>85
〇足りない情報
どんなときに使う処理か(バッチ?それともユーザー操作に対する応答?)
出力はどのような形式か(画面表示?CSVファイル?)
データベースを配置しているサーバーと出力を得るクライアントの構成は?(例:PostgreSQLto
Apacheが同じサーバーにあり、クライアントはWEB表示で結果を得る。サーバーはAWSに配置しており、ネットワークの転送速度は毎秒1MBr程度が期待できる)
レコードは何件あるのか。レコードあたりの容量は?要求されるレスポンスは?(1秒以内に出力完了など)。

97
NAME IS NULL[sage]   投稿日:2016/09/25 09:19:53  ID:???.net(298)
転送速度が極端に遅い場合はローカルにデータベースをもってジョインするのも選択肢としてあり得なくもないが(2層方式も含めて検討だろう)
それだったら出力結果を圧縮して転送だろうな
HTTPで出力する場合は例えばgzip圧縮すりゃ設定いじる程度の工数で済むしな

98
NAME IS NULL[sage]   投稿日:2016/09/25 10:29:39  ID:???.net(298)
富豪アプローチで毎回取得&キャッシュでええやん。

99
NAME IS NULL[sage]   投稿日:2016/09/25 10:40:03  ID:???.net(298)
時間も掛かるし負荷も高いんじゃない?

100
NAME IS NULL[sage]   投稿日:2016/09/25 16:03:47  ID:???.net(298)
月額2000円くらいの予算でvps借りるとしてmysqlで最大どれくらいのトランザクションを捌けるもんなの?

101
NAME IS NULL[sage]   投稿日:2016/09/25 16:07:28  ID:???.net(298)
要件定義してあげるスレが必要

102
NAME IS NULL[sage]   投稿日:2016/09/30 00:05:15  ID:???.net(298)
どこで質問したらわからないんですが総合スレってありませんかね?
コメント2件

103
NAME IS NULL[sage]   投稿日:2016/09/30 14:16:58  ID:???.net(298)


104
NAME IS NULL[]   投稿日:2016/11/09 18:56:03  ID:AtwDWs/+.net(4)
Mysql で 出力データーを
20.00 → 20
21.40 → 21.4
23.05 → 23.05
20.10 → 20.1
みたいに少数以下の語尾のゼロを取ることをMySQL内ですることはできないでしょうか?
コメント2件

105
NAME IS NULL[sage]   投稿日:2016/11/09 19:00:44  ID:???.net(298)
普通付かないだろ
元の値は文字列なのか?
コメント2件

106
NAME IS NULL[]   投稿日:2016/11/09 19:05:31  ID:AtwDWs/+.net(4)
>105
decimal です。

107
NAME IS NULL[sage]   投稿日:2016/11/09 19:39:25  ID:???.net(298)
>104
なぜゼロ取りたいの?

108
NAME IS NULL[]   投稿日:2016/11/14 22:17:52  ID:bmYVZ934.net(2)
truncとかfloorとか
文字ならsubstrみたいなやつで

109
NAME IS NULL[sage]   投稿日:2016/11/18 01:26:39  ID:???.net(298)
アドバイスをいただきたく
CFINFOテーブルのカラムが全てcharでvarcharに変更したい場合のSQLです。
数十件のデータではテストしてOKでしたが、大量のデータだと問題でそうですかね?

alter table CFINFO modify (
CF_GROUP VARCHAR2(10),
CF_NAME VARCHAR2(30),
CF_ID VARCHAR2(50),
CF_PSWD VARCHAR2(50)
)
/
update CFINFO d
set (d.CF_GROUP,d.CF_NAME,d.CF_ID,d.CF_PSWD)
= (
select trim(CF_GROUP),trim(CF_NAME),trim(CF_ID),trim(CF_PSWD)
from CFINFO m
where d.CF_NO = m.CF_NO
)
/
コメント2件

110
NAME IS NULL[]   投稿日:2016/11/21 06:49:29  ID:sXX+G/pS.net(2)
>109
/があるあたりでOracleだと思うが、なんで並列処理化するとか考えないの?

111
NAME IS NULL[sage]   投稿日:2016/11/21 11:05:47  ID:???.net(298)
というか、ふつうにhoge=trim(hoge)で良い気がするんだが
なんで自己結合する必要があるんだ

112
NAME IS NULL[sage]   投稿日:2016/11/21 11:19:03  ID:???.net(298)
それか元のテーブルをRENAMEして
新しいテーブルにINSERT SELECTしたら?
表領域足りんのか

113
NAME IS NULL[]   投稿日:2016/11/21 18:31:53  ID:CmVzeDRz.net(2)
mysqlの質問です

[2016-11-21 18:20:12]のような[yyyy-mm-dd HH:mi:ss]の形の値を持つdatetime型のフィールド、recordがあるのですが、
ここから2016年10月1日〜2016年10月31日の期間の9:00〜12:00のレコードのみを抽出するにはどのような命令を書けば良いでしょうか?
日付のみなら

SELECT * FROM t_open WHERE record BETWEEN '2016-06-01' AND '2016-07-01';

という簡単な形で出せたのですが、時刻を指定する方法が分からず詰まっています。
コメント2件

114
NAME IS NULL[sage]   投稿日:2016/11/21 18:43:05  ID:???.net(298)
>113
and date_format(record, '%H:%i') between '09:00' and '12:00'
コメント4件

115
NAME IS NULL[sage]   投稿日:2016/11/21 19:36:05  ID:???.net(298)
>114
できました!ありがとうございます!
date_format関数について勉強しておきます

116
NAME IS NULL[sage]   投稿日:2016/11/22 17:17:14  ID:???.net(298)
>114
こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか?
コメント2件

117
NAME IS NULL[sage]   投稿日:2016/11/22 18:14:09  ID:???.net(298)
>116
> こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか?
本読まないでしょ。
初心者でも入門書を2,3冊こなせば書けると思うよ。
コメント2件

118
NAME IS NULL[sage]   投稿日:2016/11/22 18:28:47  ID:???.net(298)
短いやつをちょっとずつ書けば慣れるけど
MySQLの方言だからねえ、、、

119
NAME IS NULL[]   投稿日:2016/11/22 19:27:21  ID:sjSydgSv.net(2)
確かにここのレスを見ただけだとササっと書いてるように思うのも仕方がないだろう
だけど……裏では必死でググってんだぜオレたち 👀
Rock54: Caution(BBR-MD5:8368d31ad5c810f9ab23ea9fefa156d2)

120
NAME IS NULL[sage]   投稿日:2016/11/22 20:04:48  ID:???.net(298)
>117
入門書を二冊も読んだら上級者でしょ?
それもかなり上のクラスの
コメント2件

121
NAME IS NULL[sage]   投稿日:2016/11/24 15:48:27  ID:???.net(298)
sql初心者で2、3行程度の簡単なsqlしか実行した事がないんですが、世の中では何百行、何千行のsqlを実行する事もありますか?
コメント4件

122
NAME IS NULL[sage]   投稿日:2016/11/24 16:33:30  ID:???.net(298)
>120
上級者のハードル低いね
コメント2件

123
NAME IS NULL[sage]   投稿日:2016/11/24 16:40:02  ID:???.net(298)
100行程度なら描いたことがある
メンテナンス性を考えると
あまり長くしないようがいいように思う

124
NAME IS NULL[sage]   投稿日:2016/11/24 16:49:13  ID:???.net(298)
>122
相対的には上級者になるのかもねw
絶対的にはもちろん違うけど
コメント2件

125
NAME IS NULL[sage]   投稿日:2016/11/24 17:00:52  ID:???.net(298)
>124
自分がかなり上のクラスの上級者であると自己判定していて、自分のクラスになるには入門書2冊が必要だった、ということかも

126
NAME IS NULL[sage]   投稿日:2016/11/24 17:17:01  ID:???.net(298)
入門書を何冊読んでも入門書レベルの知識しかつかないという、ごくあたりまえの話

127
NAME IS NULL[sage]   投稿日:2016/11/24 20:22:40  ID:???.net(298)
>121
そんな複雑なやつを書く前にストアドとかビューを組み合わせるとかを検討する
そんなの書いたら検証がえらいことになる

128
NAME IS NULL[sage]   投稿日:2016/11/24 21:42:31  ID:???.net(298)
聞いた話でそれを見たことはないけど、1000行くらいのが出来上がったとかなんとか。
見たくもない(ある証券系のシステムでのお話)

129
NAME IS NULL[sage]   投稿日:2016/11/25 19:24:44  ID:???.net(298)
問い合わせ文じゃなくて、ややこしいストアド書くなら数百は余裕であり得るだろうけど

130
NAME IS NULL[sage]   投稿日:2016/11/25 21:18:31  ID:???.net(298)
行が増えざるを得ない状況がストアド開発には多すぎるからなぁ
つまり複雑度はなぜ行が多いのか次第

131
NAME IS NULL[]   投稿日:2016/11/25 21:23:23  ID:riZyA4Jk.net(2)
>121
カラム数が多くて、改行してたらあっという間。
コメント2件

132
NAME IS NULL[sage]   投稿日:2016/11/25 22:45:32  ID:???.net(298)
>131
> カラム数が多くて
それはそれでどうかと思うが...

133
NAME IS NULL[sage]   投稿日:2016/11/28 10:24:40  ID:???.net(298)
データ抽出用のビュー作るとカラム数数百とかなる

134
NAME IS NULL[sage]   投稿日:2016/11/28 11:06:13  ID:???.net(298)
二つのテーブルをjoinし、マスターをそれぞれ5個joinすると、
select t1.hoge, -- t1のデータで10行
...
t2.fuga, -- t2のデータで10行
join hoge_master -- マスター系テーブルのjoinで3行
on ...
and ...
これだけで、10 + 10 + 3 * 5 * 2 = 50行
それにwhere句とsub queryがつき、さらにunionで3ブロックほど結合すれば簡単に200行とかいく。
コメント2件

135
NAME IS NULL[]   投稿日:2016/11/28 19:58:42  ID:3f+IloFY.net(2)
カラム数はシステムが古かったり、考え方が古いひとが作ったものをだったりするとコントロールできない。

136
NAME IS NULL[sage]   投稿日:2016/11/28 20:54:44  ID:???.net(298)
何か列と行がグチャグチャ

137
NAME IS NULL[sage]   投稿日:2016/11/28 21:16:32  ID:???.net(298)
わざわざ1カラム1行でクエリ書いて行数多くてメンテナンス性落ちるなら本末転倒
コメント4件

138
NAME IS NULL[]   投稿日:2016/11/28 22:25:17  ID:PzYguHzt.net(2)
>137
はあ?

139
NAME IS NULL[sage]   投稿日:2016/11/29 10:41:34  ID:???.net(298)
>137
>134みたいなケースで言うと、行数が多くてメンテナンス性が落ちるということはない。
逆に、1行に複数カラムを羅列される方がメンテナンス性が落ちる。

140
NAME IS NULL[sage]   投稿日:2016/11/29 12:22:04  ID:???.net(298)
お前らの言うメンテナンス性ってテキストの編集しやすさの事だったんかw
コメント2件

141
NAME IS NULL[]   投稿日:2016/11/29 12:34:20  ID:W7hPtk8B.net(4)
>140
保守、仕様変更でSQLの構文が書き直されるようなのは馬鹿のやることだろ。

リスク高すぎ。
コメント2件

142
NAME IS NULL[sage]   投稿日:2016/11/29 12:41:50  ID:???.net(298)
可読性が低くてメンテナンス性は高いという状況が思いつかない

143
NAME IS NULL[sage]   投稿日:2016/11/29 13:04:43  ID:???.net(298)
>141
>保守、仕様変更で

手を入れないといけないときは
なるべくSQL(ストアド)の変更だけで留めようと努力するけど違うのか
コメント4件

144
NAME IS NULL[]   投稿日:2016/11/29 13:17:16  ID:W7hPtk8B.net(4)
>143
ストアドだって同じだろw

145
NAME IS NULL[sage]   投稿日:2016/11/29 13:44:04  ID:???.net(298)
>143
> なるべくSQL(ストアド)の変更だけで留めようと努力するけど違うのか
QiitaをkickされたSQLおじさん信者か何かか?
コメント2件

146
NAME IS NULL[sage]   投稿日:2016/11/29 21:15:59  ID:???.net(298)
>145
SQLおじさんってどなた?
ORMおじさんは知ってたけど
コメント2件

147
NAME IS NULL[sage]   投稿日:2016/11/30 10:30:54  ID:???.net(298)
>146
SQLおじさん、Qiitaに炎上記事投稿 周囲の反応と垢BANまでの流れ
http://togetter.com/li/1047474
コメント2件

148
NAME IS NULL[sage]   投稿日:2016/11/30 11:36:29  ID:???.net(298)
>147
ありがとう、同一人物だった

149
NAME IS NULL[sage]   投稿日:2016/12/14 16:14:32  ID:???.net(298)
TBS

150
NAME IS NULL[]   投稿日:2016/12/17 00:34:45  ID:L7Q4LZyG.net(4)
教えてください
アクセスを使ってます

INSERT INTO 日時(日付,時刻)
SELECT 日付,時刻 FROM 日付,時刻
WHERE (日付,時刻) NOT IN(SELECT 日付,時刻 FROM 日時)

データをクロス結合して重複分を排除しつつ日時テーブルに書込みをしたいのですが、
上のSQLではエラーとなってしまいます
自分でも調べてはいるのですがどうにも分からず頼らせてもらえればと思います
よろしくお願いします

151
NAME IS NULL[]   投稿日:2016/12/17 01:19:14  ID:L7Q4LZyG.net(4)
150です

自己解決しました。失礼しました。

152
NAME IS NULL[sage]   投稿日:2016/12/23 14:37:04  ID:???.net(298)
それクロス集計じゃなくてただの直積じゃないのか…?

153
NAME IS NULL[sage]   投稿日:2016/12/24 04:08:40  ID:???.net(298)
クロス結合とクロス集計って違うよ

154
NAME IS NULL[sage]   投稿日:2016/12/26 23:30:53  ID:???.net(298)
すみません、教えていただけますでしょうか。
ACCESSなのですが、

【テーブルA】
ID、商品名
10.90.10、鉛筆赤
10.90.20、鉛筆青
20.800.101、はさみ青
20.800.102、はさみ緑
305.001、のり青
305.005.100、のり黒


【テーブルB】
ID、値段
10.90、100円
20.800、200円
305、500円


というテーブルがあったとします。
テーブルBのIDを取得し、テーブルAから、テーブルBのIDの文字列にて始まるIDを取得し、テーブルAに値段列を付加するSQLを
作成しようとしているのですが、作成方法がいまいちわかりません。

例えば、
【抽出したい結果】
ID、商品名、テーブルBの値段
10.90.10、鉛筆赤、100円
10.90.20、鉛筆青、100円
20.800.101、はさみ青、200円
20.800.102、はさみ緑、200円
305.001、のり青、500円
305.005.100、のり黒、500円
のような感じです。

おそらく、テーブルAとテーブルBをleft joinする形になると思うのですが、
よい方法があれば教えていただけないでしょうか。
コメント2件

155
NAME IS NULL[sage]   投稿日:2016/12/27 02:49:52  ID:???.net(298)
>154
もしかして"10.90.10"で一つの項目に入っていて
そのうちの"10.90"と突き合わせたいとかいう話?

leftとmid組み合わせるとかinstr使うとかlike使うとか、いくつかやり方は思いつくけど
悪いことは言わないからまずDB設計見直せ
コメント2件

156
NAME IS NULL[sage]   投稿日:2016/12/27 07:38:43  ID:???.net(298)
>155 早速のレス、ありがとうございます。

>>もしかして

157
NAME IS NULL[sage]   投稿日:2016/12/27 07:39:20  ID:???.net(298)
すみません、なぜか切れてしまいました。

>>もしかして"10.90.10"で一つの項目に入っていてそのうちの"10.90"と突き合わせたいとかいう話?
はい、そういうことをやりたいと考えています。IDの例があまりよくなかったので、サンプルを変更します。

【テーブルA】
ID、商品名
abc-10、鉛筆赤
abc-20、鉛筆青
ef-101、はさみ青
ef-102、はさみ緑
abdzz-001、のり青
abdzz-100、のり黒

【テーブルB】
ID、値段
abc、100円
ef、200円
abdzz、500円

【抽出したい結果】
ID、商品名、テーブルBの値段
abc-10、鉛筆赤、100円
abc-20、鉛筆青、100円
ef-101、はさみ青、200円
ef-102、はさみ緑、200円
abdzz-001、のり青、500円
abdzz-100、のり黒、500円
のような感じです。

データベース設計を見直したいのですが、もうシステムが動いてしまっていて、
変更がちょっと難しい状態なのです、、、
社内用のシステムでお客様で使っているものではないのが救いなのですが。
コメント4件

158
NAME IS NULL[sage]   投稿日:2016/12/27 10:42:43  ID:???.net(298)
テーブルAに一列追加して
B用のキーを追加した方がいいぞ
キー列が変わることなんざ無いだろうし、insertするとこだけ弄ればいい
既にある列も30分もありゃ出きるやろ
そしたら普通にインナージョインで処理できる
コメント2件

159
NAME IS NULL[sage]   投稿日:2016/12/27 11:54:27  ID:???.net(298)
>158
それselect * してるやつがいたらこける可能性ある
コメント2件

160
NAME IS NULL[sage]   投稿日:2016/12/27 12:00:38  ID:???.net(298)
>社内用のシステムでお客様で使っているものではないのが救い

社内システムには直すお金がかけられないとかあるあるだけど
それ救いじゃなくて呪い(負債)だからな

161
NAME IS NULL[sage]   投稿日:2016/12/27 12:16:08  ID:???.net(298)
>159
Accessの場合大分こけないはず
フォームとかではいちいちフィールド名指定するし
Select * のフィールド数不一致でエラー吐くパターンがむしろ想像できん

ソースは小規模Accessをフィールド建て増ししまくって用途10倍以上に増やした俺

まぁ、
A inner join B On A.ID like B.ID & '*'
でも動くだろうけど、ミスによるバグがクッソ増えそうだし嫌だわ

162
NAME IS NULL[sage]   投稿日:2016/12/27 14:28:17  ID:???.net(298)
わざわざ abczz じゃなく abdzz にしてる意図が気になるな
コメント2件

163
NAME IS NULL[sage]   投稿日:2016/12/27 15:14:12  ID:???.net(298)
>162
likeしたときに
abc-とabcde-だと被るからじゃない?

164
NAME IS NULL[sage]   投稿日:2016/12/27 16:49:49  ID:???.net(298)
苦しすぎるw

165
NAME IS NULL[sage]   投稿日:2016/12/27 17:12:37  ID:???.net(298)
>157
> データベース設計を見直したいのですが、もうシステムが動いてしまっていて、
> 変更がちょっと難しい状態なのです、、、

正しいデータベース設計後、古いテーブルと同じ形式のViewを作ることができれば、
現行システムに影響を与えることなくデータベースの変更が可能。
コメント8件

166
NAME IS NULL[sage]   投稿日:2016/12/27 19:31:30  ID:???.net(298)
>165
view賛成
ま、弊社の場合はviewだらけで訳が分からなくなってるけどね(笑

167
NAME IS NULL[sage]   投稿日:2016/12/27 21:09:16  ID:???.net(298)
>165
ソレダ

168
NAME IS NULL[sage]   投稿日:2016/12/27 21:13:35  ID:???.net(298)
>157
クエリ追加したいってことは、少なくとも何らかの変更/追加があるわけで
そのうえでそのテーブルレイアウトで自分でクエリ書けないんだろ
だったらテーブルレイアウト直すべきだと思うけどね
ま、動いてて変えられんとかいう状況ならそのシステムに似たような事してるとこあるだろ

>165-166
普通のDBMSならビューで逃げる手はあるけど、ACCESSって結構テーブルとクエリで扱い方に差があるからなぁ

169
NAME IS NULL[sage]   投稿日:2016/12/28 06:24:05  ID:???.net(298)
>165
accessで困ってる初心者に追加可能な選択クエリとか書けるかっていう疑問はあるけど出来たらそれで良いかもね

170
NAME IS NULL[sage]   投稿日:2016/12/29 07:14:51  ID:???.net(298)
viewじゃ更新できないカラムのsqlあったらどうすんの

171
NAME IS NULL[sage]   投稿日:2017/01/04 10:49:09  ID:???.net(298)
トリガー作るしか無いかなあ

172
NAME IS NULL[sage]   投稿日:2017/01/29 14:56:15  ID:???.net(298)
oracleのmergeについて質問です。
oracleは11gを使っています。


とあるテーブルにmergeを使ってpkのレコードが無ければレコード追加、レコードがあれば何もしないというsqlがありました。

このようなsqlで行が無い場合はinsertと同じようにロックを取得すると思うのですが、
既に行がある場合ってロックは取得されるのでしょうか?

リファレンスを見ると細かいケースに言及せず、mergeの表ロックモードはsxとあるので、更新処理の有無に関わらずforupdateと同様にロックされるのかなぁと思っているのですが、、

173
NAME IS NULL[sage]   投稿日:2017/03/14 22:41:55  ID:???.net(298)
【質問テンプレ】
・DBMS名とバージョン
Access?(Excel2013のデータ接続機能のところに書いて使いたいです)

・テーブルデータ
ID |Price|Name
-----------------
1001 100 ガム
1002 200 あめ
1002 300 チョコ
1003 400 クッキー
1003 500 ポテチ
1003 600 ポテチ

・欲しい結果
ID |Price|Name
-----------------
1001 100 ガム
1002 500 あめ,チョコ
1003 1500 クッキー,ポテチ,ポテチ

・説明
ID毎にPriceを合計してNameの値を結合したいです。
よろしくお願いします。

174
NAME IS NULL[sage]   投稿日:2017/03/15 00:45:52  ID:???.net(298)
主キーも何も無いのこれw
コメント2件

175
NAME IS NULL[sage]   投稿日:2017/03/15 14:25:20  ID:???.net(298)
Nameの結合の順番は決まってんの?

176
NAME IS NULL[sage]   投稿日:2017/03/15 18:49:35  ID:???.net(298)
group_concat()があれば簡単なのに

Access用にはDJoinという関数を作って公開してる人がいたみたいだけど
ページが消えてる

177
NAME IS NULL[sage]   投稿日:2017/03/15 20:10:02  ID:???.net(298)
AccessならVBAでID受け取ってNameをカンマ連結した文字列返す関数作ればできんじゃね

178
173[sage]   投稿日:2017/03/17 23:41:34  ID:???.net(298)
>174-177
返信おそくなってすみません
質問に不足してた部分があったので
また質問しなおしたいと思います

どうもありがとうございました

179
NAME IS NULL[sage]   投稿日:2017/04/26 20:40:34  ID:???.net(298)
・Postgresql 8.4

・テーブルデータ
|year|month
-----------------
2017 4
2017 6
2018 3
2018 4

・欲しい結果
|year|month
-----------------
2017 4
2017 6
2018 3

・説明
integerの列year、monthに年、月が書かれており、2017年4月〜2018年3月までの会計年度の行を取りたいのですが、そのようなことは可能でしょうか お願いします
コメント6件

180
NAME IS NULL[sage]   投稿日:2017/04/26 21:37:32  ID:???.net(298)
select * from table where year*100+month between 201704 and 201803;

じゃだめか?
コメント14件

181
NAME IS NULL[]   投稿日:2017/04/26 21:56:03  ID:yyy4jyWJ.net(2)
俺じゃダメか?

182
NAME IS NULL[sage]   投稿日:2017/04/26 22:08:23  ID:???.net(298)
(year=2017 and month>=4) or (year=2018 and month<=3)でいいだろ
コメント20件

183
NAME IS NULL[sage]   投稿日:2017/04/26 22:54:12  ID:???.net(298)
IIf(Month<4,Year-1,Year) AS 会計年度
見たいなカラム持ったクエリ定義しとけよ

184
183[sage]   投稿日:2017/04/26 22:57:19  ID:???.net(298)
あ、なぜかACCESSだと思ってたw
標準的なSQLならCASEでビューか

まあ、わかるだろ

185
NAME IS NULL[sage]   投稿日:2017/04/27 04:56:49  ID:???.net(298)
>179
性能は知らん
where make_date(year, month, 1) between '2017-04-01' and '2018-03-31'
コメント6件

186
NAME IS NULL[sage]   投稿日:2017/04/27 07:07:55  ID:???.net(298)
>182
自分もこれだな

187
NAME IS NULL[sage]   投稿日:2017/04/27 09:29:25  ID:???.net(298)
日付を分割してintに入れる糞実装、未だに存在するのかよ

188
NAME IS NULL[sage]   投稿日:2017/04/27 10:38:00  ID:???.net(298)
日付じゃなくて必要なのが月までだからだろ
コメント2件

189
NAME IS NULL[sage]   投稿日:2017/04/27 10:55:10  ID:???.net(298)
それでも /01 にしてdate型に突っ込むわ

190
NAME IS NULL[sage]   投稿日:2017/04/27 12:24:41  ID:???.net(298)
どうでもいいけど言うならせめて糞設計だよね
実装てw

191
sage[]   投稿日:2017/04/27 15:25:55  ID:JuRKhktP.net(2)
設計:年・月を保存する
実装:年・月を別カラムにする

192
NAME IS NULL[sage]   投稿日:2017/04/27 15:38:14  ID:???.net(298)
質問者への回答と、設計の改善提案は別だろうに

193
NAME IS NULL[sage]   投稿日:2017/04/27 16:00:01
number(8)に日付いれるのが好きなフレンズもいるな
コメント2件

194
NAME IS NULL[sage]   投稿日:2017/04/27 16:08:50
>193
難点は経過日数計算が大変な

195
NAME IS NULL[sage]   投稿日:2017/04/27 17:08:47
俺は >180 支持だなぁ
速度的にも見た目的にも

196
NAME IS NULL[sage]   投稿日:2017/04/27 18:52:05
>180
会計年度中も指定できるので非常に参考になりました

他の方法も含めご教示ありがとうございます

197
NAME IS NULL[sage]   投稿日:2017/04/27 18:59:16
年月を保持する要件で、データに意味を持たない日の情報が含まれるって、良いのでしょうか

バグを産む可能性を秘めてるような
コメント2件

198
NAME IS NULL[sage]   投稿日:2017/04/27 19:31:38
>197
あり得ない月とかを突っ込める方が恐いわ
コメント2件

199
NAME IS NULL[]   投稿日:2017/04/27 19:39:19
>198
そんなもんなんぼでもあるわwお前ビビりすぎw
コメント2件

200
NAME IS NULL[sage]   投稿日:2017/04/27 19:54:14
バカが現れた

201
NAME IS NULL[sage]   投稿日:2017/04/27 20:18:45
>199のレスの意味がわからなすぎる

202
NAME IS NULL[sage]   投稿日:2017/04/27 20:19:31
バグというより、データベースに事実にない情報を含めるとか違和感が

203
NAME IS NULL[sage]   投稿日:2017/04/27 20:44:47
numberでもバグを産む可能性を秘めてるし
どっちのリスクをとるかだけじゃね

204
NAME IS NULL[sage]   投稿日:2017/04/27 21:33:38
年月のみを管理したいっていう場合に
・日付としての正当性は保証されるけど不要な日の情報を持つ
・日付としての正当性は保証されないけど不要な情報を持たない
のどちらがいいか?
って話でしょ
個人的にはデータの正当性の方を重視するかな

205
NAME IS NULL[sage]   投稿日:2017/04/28 07:06:33
そして2017/4/1と2017/4/2など
同一年月で複数レコードできてしまうのでした
コメント2件

206
NAME IS NULL[sage]   投稿日:2017/04/28 07:18:39
年月情報をユニーク制約を保持する仕様で日付計算のためにdate使ってたら、皆さんはどう思いますか

207
NAME IS NULL[sage]   投稿日:2017/04/28 10:47:01
もうUNIQUE制約のある年月列と日付計算用の列を分けろよ

208
NAME IS NULL[sage]   投稿日:2017/04/28 11:33:54
レコードの入力時に日付が何入っていようと、1にしてしまえば良いだけだろう

209
NAME IS NULL[sage]   投稿日:2017/04/28 12:16:53
そんなもん制約がなければ全く信用できん
本当に頭が悪いなお前ら

210
NAME IS NULL[sage]   投稿日:2017/04/28 13:33:21
>205
2017/00 とか 2017/13 とか入ってるのとどっちがいい?

211
NAME IS NULL[sage]   投稿日:2017/04/28 15:57:28
DB側の制約がいかに利用されていないか分かるな

212
NAME IS NULL[sage]   投稿日:2017/04/28 18:48:18
1日の0時になっているか確認するcheck制約つければいい

213
NAME IS NULL[sage]   投稿日:2017/04/28 20:51:04
そもそもカラムが年と月別なんだからcheck制約でもMonth>=1 and Month<=12でいいから簡単だろ
プログラムも同様
まさか日付を変換して1日かとかやるとか?
いらない情報付与からして、そんなのうちでは許されないわw

214
NAME IS NULL[sage]   投稿日:2017/04/30 03:36:41
>182
後の人間を苦しめるコードをまき散らすのは止めよう
コメント2件

215
NAME IS NULL[]   投稿日:2017/04/30 19:54:54
>214
馬鹿の苦しみなんか気にしてられんわw

216
NAME IS NULL[sage]   投稿日:2017/04/30 20:56:47
3年分取ってきてと言われて初めて問題に気付くパターンや

217
NAME IS NULL[sage]   投稿日:2017/04/30 23:19:56
where fiscal_year(year, month) = 2017
みたいな感じで関数使うかビュー使うほうがロジックが一箇所に集まっていい気がする
パフォーマンス気にするレベルならcalender yearとは別にfiscal yearをデータに持たせるかな
コメント6件

218
NAME IS NULL[sage]   投稿日:2017/04/30 23:33:29
あと fiscal_year(date) みたいにオーバーロードしとけば
インターフェースが統一されて使いやすい

219
NAME IS NULL[sage]   投稿日:2017/05/01 09:41:38
SQLにオーバーロードあるんですか?どんなRDB?

220
NAME IS NULL[sage]   投稿日:2017/05/01 10:54:41
え、、、普通にあるでしょ
むしろできないDBってどれよ
コメント2件

221
NAME IS NULL[sage]   投稿日:2017/05/01 13:48:49
>220
できないやつ多数でしょ

222
NAME IS NULL[sage]   投稿日:2017/05/01 14:14:22
そうなんか、OracleとPostgreSQLで出来てるから普通なのかと・・・

223
NAME IS NULL[sage]   投稿日:2017/05/01 14:29:03
まーた、俺様の「普通」が炸裂しとる

224
NAME IS NULL[sage]   投稿日:2017/05/01 14:33:46
Oracleは特例
いいね?

225
NAME IS NULL[sage]   投稿日:2017/05/01 15:03:51
てか、そもそもOracleでも単純なオーバーロードってあったっけ?

226
NAME IS NULL[sage]   投稿日:2017/05/01 15:05:03
packageを使ったオーバーロードはあるが・・・
http://www.shift-the-oracle.com/plsql/overloading-subprogram-name.html

227
NAME IS NULL[sage]   投稿日:2017/05/01 15:07:37
このケースはComputed Columnが使えればそれがいいと思うけど
Postgresでは使えないから関数オーバーロードしとくって話
Computed Columnなら使えるDB多いだろ

SQL標準ならView使えって話かもしれんがViewは管理上のオーバーヘッドが高くなる傾向があるから
使わなくてすむケースならなるべく使わないようにしてる

228
NAME IS NULL[sage]   投稿日:2017/05/01 15:15:27
普通に>182でいいだろ
コメント2件

229
NAME IS NULL[sage]   投稿日:2017/05/01 15:36:01
PostgreSQL有害論

230
NAME IS NULL[sage]   投稿日:2017/05/01 16:10:53
>228
会計年度を必要とするたびに繰り返し同じことをするのでよければね
年度別に集計したい場合とかしんどいし俺はごめんだわ
コメント2件

231
NAME IS NULL[sage]   投稿日:2017/05/01 16:49:59
普通に関数でいいと思うんだが、あえて(関数?)オーバーロードって言ってるのはなんで?
コメント2件

232
NAME IS NULL[sage]   投稿日:2017/05/01 16:57:59
>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
コメント14件

233
NAME IS NULL[sage]   投稿日:2017/05/01 17:06:24
つか、いたるところで会計年度を意識するようなシステムなら、会計年度カラムを作っとけばいいよな
コメント2件

234
NAME IS NULL[sage]   投稿日:2017/05/01 18:03:32
>232
where句も入れて何回繰り返すのさ
面倒くさいとは思わないの?
単発の作業ならわからんでもないが会計年度みたいなのは1回じゃすまないだろ

>231
日付型でデータを持ったテーブルがあったり
日付型に徐々に移行したい場合に同じ名前で扱えるとうれしいから
会計年度って概念をDBに反映させる一つの手段
コメント6件

235
NAME IS NULL[sage]   投稿日:2017/05/01 18:18:52
>234
> 面倒くさいとは思わないの?
いや、まったく
>232レベルのクエリなら10秒もかからずタイプできるだろ
コメント2件

236
NAME IS NULL[sage]   投稿日:2017/05/01 18:28:00
>234
> where句も入れて何回繰り返すのさ
ストアドでも似たようなもんだろ。
select fiscal_year(year, month), sum(hoge) from fuga group by fiscal_year(year, month)
しかもストアド使うと、year, monthにインデックスあっても使われないし。
コメント2件

237
NAME IS NULL[sage]   投稿日:2017/05/01 18:37:19
ストアド最強!!!|バカの壁| SQL92以降

238
NAME IS NULL[sage]   投稿日:2017/05/01 18:46:32
kantomi@qiita_banned < ストアド!ストアド!

239
NAME IS NULL[sage]   投稿日:2017/05/01 18:53:59
>235
面倒くさいと思わないならいいんじゃね

>236
asで名前つけとけばgroup byでは繰り返す必要ないよ
たとえ繰り返しが必要だったとしても概念をその名前で直接扱える状態と
毎回展開しなきゃいけない状態では全く意味が違うんだけどね

インデックスは必要ならはればいい
コメント4件

240
NAME IS NULL[sage]   投稿日:2017/05/01 19:03:28
>233
算出できる情報を別途カラム作って持たせるのは最終手段
コメント2件

241
NAME IS NULL[sage]   投稿日:2017/05/01 19:04:19
>180 重み付けの定石
>182 単年度でしか動かないクソ
>185 意図が分かりやすい
>217 ビジネスロジックをDBMSに持たせる派とアプリに持たせる派で戦争勃発
コメント4件

242
NAME IS NULL[sage]   投稿日:2017/05/01 19:33:28
>241
一番馬鹿ww

243
NAME IS NULL[sage]   投稿日:2017/05/01 21:25:30
>234
fiscal_year(year, month)って関数自体はまだなにもオーバーロードしてないだろうが。

244
NAME IS NULL[]   投稿日:2017/05/01 21:52:46
>241のどこが馬鹿なのか論理的に説明できないやついるの?

245
NAME IS NULL[sage]   投稿日:2017/05/01 23:12:56
>240
分解せずに日付型で持っていればよかったって事だな
以降>188へ戻る

246
NAME IS NULL[sage]   投稿日:2017/05/02 03:16:15
管理上のオーバーヘッドってのがユーザ側の話なのかシステム側の話なのかしらんが
関数オーバーロードができたとして、それがビューより管理が重いとか信じられん

会計年度が必要ならそう言うビュー作れ、で終わりじゃないのか
コメント2件

247
NAME IS NULL[sage]   投稿日:2017/05/02 08:24:38
一方ロシアは会計年度カラムを追加した

248
NAME IS NULL[sage]   投稿日:2017/05/02 10:00:08
インデックス張るなら、ロシア方式が一番いいよな
トリガーで仕掛けておけば気にしなくて済むし

249
NAME IS NULL[sage]   投稿日:2017/05/02 10:17:39
>239
> インデックスは必要ならはればいい
本末転倒だな
普通にクエリ書けばインデックス使えるのに、ストアドにしようと思うとさらに何かしないといけなくなる
つか、ストアドの結果にインデックス貼れないDBもあるんじゃね?

250
NAME IS NULL[sage]   投稿日:2017/05/02 10:22:47
>239
> asで名前つけとけばgroup byでは繰り返す必要ないよ
その手段が使えるDBでは、>232も同じことが言える

> 毎回展開しなきゃいけない状態では全く意味が違うんだけどね
例えば四半期ごとの集計がほしいとか、移動平均がほしいとかいうことになったら、
そのたびにストアド作るのか?
増殖しまくりだな
コメント2件

251
NAME IS NULL[sage]   投稿日:2017/05/02 10:26:43
ん? >232 だとインデックス使われないだろ
>217-218 >185 のような関数だともっと使われない
>182 のように or あると、うまく使ってくれるか怪しい
コメント4件

252
NAME IS NULL[sage]   投稿日:2017/05/02 10:38:44
>251
> ん? >232 だとインデックス使われないだろ
where書いてないからね
>232は、集計がしんどいという奴へのレス

>182 のように or あると、うまく使ってくれるか怪しい
大抵のRDBMSだったらうまく使ってくれるんじゃね?

253
NAME IS NULL[sage]   投稿日:2017/05/02 10:44:41
それより決算月が変わる可能性について考えたほうがいいと思う
コメント2件

254
NAME IS NULL[sage]   投稿日:2017/05/02 10:45:38
>251
> >217-218 >185 のような関数だともっと使われない
こういうバカ避けのためにわざわざ「性能は知らん」って書いてあるのにバカはそれすら理解できないんだな w
インデックス使いたいならdate型にしとけよ
コメント2件

255
NAME IS NULL[sage]   投稿日:2017/05/02 10:49:15
>253
会計年度カラム追加で解決。

256
NAME IS NULL[sage]   投稿日:2017/05/02 10:51:13
>254
year, monthにインデックス張ればいいだろ
アホか
コメント4件

257
NAME IS NULL[sage]   投稿日:2017/05/02 11:01:20
ビューのコストが高いというのがparserの話だとしたら、単純なビューなら最近では全く問題にならない
まぁ、大抵の場合、クエリ1回につき+1ms未満だろう。
(さらには、直近のparse結果をcacheしている場合もある)

258
NAME IS NULL[sage]   投稿日:2017/05/02 11:03:21
>256
> year, monthにインデックス張ればいいだろ

インデックス張っても関数の引数にしちゃったら使われない

259
NAME IS NULL[sage]   投稿日:2017/05/02 15:49:34
>256
バカってこれだから...
複数の列に張るより単一の方が有利だろう
そんなことも理解できないのかよ w
コメント2件

260
NAME IS NULL[sage]   投稿日:2017/05/02 16:00:26
そんな理由だったらオレもアンタをバカ呼ばわりしていいかな
コメント2件

261
NAME IS NULL[sage]   投稿日:2017/05/02 16:16:34
>260
理由が書けるならね

262
NAME IS NULL[sage]   投稿日:2017/05/02 17:11:25
不利っつっても、比較が1回か2回かって違いくらいしかないだろ。

263
NAME IS NULL[sage]   投稿日:2017/05/02 17:17:06
ここを2つに分けるかどうかの是非はともかく
キーが2つになるから絡むつにしようとかおかしいだろw

まあこのケース、月なんて12通りしか無いんだし複合キーで

264
NAME IS NULL[sage]   投稿日:2017/05/02 18:48:29
>複数の列に張る

こういう言い方しているところを見ると、複合インデックスの仕組みをわかってないんだろう。
コメント4件

265
NAME IS NULL[sage]   投稿日:2017/05/02 18:57:10
yearのインデックスとmonthのインデックスを別々に張りそう

266
NAME IS NULL[sage]   投稿日:2017/05/02 19:11:26
>250
>その手段が使えるDBでは、>232も同じことが言える
そんなんわざわざ言わんでもわかっとるがな〜ww

>増殖しまくりだな
増殖して何か問題あるの?

267
NAME IS NULL[sage]   投稿日:2017/05/02 21:48:44
>246
システム側の話
組織構造なんかも大きく影響するから環境による
導出列はビューを使うっていう規約があってそれに従ってるようなところならオーバーヘッドも少ないだろうね
ただ関数よりビューのほうが管理の厳格度というか管理レベルが高いのは一般的じゃないのかな?
管理レベルが高ければその分のオーバーヘッドはかかる

それに同じような年・月で持ってるテーブルが10個に増えたら10個ビューを追加することになる
そういうのが嫌だからComputed Column的な機能があるDBが多いと思ってる
コメント2件

268
NAME IS NULL[sage]   投稿日:2017/05/02 22:51:26
>264
お前こそわかってないだろ w
>180, >182 みたいに複合インデックスの各々の列を別々に大小比較で使うとインデックス使えないぞ
コメント2件

269
NAME IS NULL[sage]   投稿日:2017/05/02 23:17:09
使われないインデックスと、使えないお前らの脳ミソ達。

270
NAME IS NULL[sage]   投稿日:2017/05/03 00:11:51
>182は(orは別として)yearとmonthの複合インデックスの教科書的な例だと思うが。
つか、>180>182を同列に並べている時点でお里が知れる。
コメント4件

271
NAME IS NULL[sage]   投稿日:2017/05/03 04:36:48
>267
管理レベルってのがなんだかわからんが
ビューの方がより厳密に適用される分、問い合わせ時のシステム的なオーバーヘッドは小さいだろ
実行計画もより最適化できる
つか、ユーザー側/システム側って切り分けが、どっちも人員の切り分けだと思ってる?

>それに同じような年・月で持ってるテーブルが10個に増えたら
同じものが分散して存在してたら、その時点でテーブル設計が間違ってるわ

272
NAME IS NULL[sage]   投稿日:2017/05/03 07:59:56
馬鹿はなぜ無駄に未来の心配ばかりするのか

273
NAME IS NULL[sage]   投稿日:2017/05/03 09:25:30
>270
実行計画見てみ
複合インデックスの仕組み知ってたらそんなアホな発想はできないよ

274
NAME IS NULL[sage]   投稿日:2017/05/03 10:39:56
おまえこそ見てみろと言いたいが。

念のためだが、ヘボいオプティマイザがorのせいでスキャン範囲の限定に失敗するのは
「複合インデックスの各々の列を別々に大小比較で使うとインデックス使えない」てのとは
関係ないからな。
コメント4件

275
NAME IS NULL[sage]   投稿日:2017/05/03 11:04:58
>274
> orのせいで
バカを晒すのはほどほどにしろよ

276
NAME IS NULL[sage]   投稿日:2017/05/03 12:06:11
>274
複合インデックスから任意の1つの列を選んで使う事はできないので、 データベースはインデックスを使いません。
インデックスの構造をより深く見ていくと、この理由がはっきりします。
http://use-the-index-luke.com/ja/sql/where-clause/the-equals-operator/conca...
コメント2件

277
NAME IS NULL[sage]   投稿日:2017/05/03 12:40:47
今どきは>182でも(year,month)のインデックスがあれば
(そしてそれを使ったほうが速いとDBMSが判断すれば)
使うDBMSのほうが多いと思う

パフォーマンスに関しては昔の定石を今はあまり気にしなくても
良くなっていることが多いので必ず実機で試してから語ったほうがいい

278
NAME IS NULL[sage]   投稿日:2017/05/03 13:06:33
>276
それはyearを使わずにmonthだけだった場合だな。こんな初歩的な勘違いしてたのか。
コメント2件

279
NAME IS NULL[sage]   投稿日:2017/05/03 13:34:58
>278
バカはこれだから...
わざわざ
> インデックスの構造をより深く見ていくと、この理由がはっきりします。
って言うところまで引用してるだからその下読めよ
理解できるかどうかは知らんけど w

280
NAME IS NULL[sage]   投稿日:2017/05/03 14:38:41
アホなレス量産してるやつは約1名だけっぽいな

281
NAME IS NULL[sage]   投稿日:2017/05/03 17:44:08
year, monthにインデックスの件だけど、PostgreSQLなら使われるけどなぁ
ほかのDBだと使われなかったりするのか?
コメント2件

282
NAME IS NULL[sage]   投稿日:2017/05/03 17:47:31
create table hoge (year integer, month integer, amount integer);
create index hoge_idx on hoge(year, month);

select year, month, sum(amount)
from hoge where (year = 2017 and month > 3) or (year = 2018 and month < 4)
group by year, month;

実行計画:
https://explain.depesz.com/s/rwx
コメント10件

283
NAME IS NULL[sage]   投稿日:2017/05/03 18:26:59
使われないDBがあると思ってるのは約1名だけだぞ

284
NAME IS NULL[sage]   投稿日:2017/05/03 18:31:37
実行計画見るような人なら当然わかっているだろうけど、統計情報がとられていなかったり
選択されるレコードの割合ががテーブル全体に対して大きい場合はインデックススキャンが
選択されないから注意な。

285
NAME IS NULL[sage]   投稿日:2017/05/03 18:42:36
インデックス使われないマン =
オーバーロードマン =
Computed Columnマン
コメント2件

286
NAME IS NULL[sage]   投稿日:2017/05/03 18:49:07
=管理レベルマン

287
NAME IS NULL[sage]   投稿日:2017/05/03 19:48:53
>281-282
ああPostgreSQLはデータが少ない時はBit Map展開するのか
http://use-the-index-luke.com/ja/sql/explain-plan/postgresql/operations
それを一般的な話にされても困るな
コメント10件

288
NAME IS NULL[sage]   投稿日:2017/05/03 19:56:46
まさか今どき、インデックスがあれば必ず使うとか思ってるんだろうか
ルールベースとコストベースの違いも分かってない?
コメント6件

289
NAME IS NULL[sage]   投稿日:2017/05/03 20:03:06
「使われない場合もある」に方向転換w

290
NAME IS NULL[sage]   投稿日:2017/05/03 20:30:25
>285
おいこら
インデックス使われないマンと一緒するなよw

291
NAME IS NULL[sage]   投稿日:2017/05/03 20:42:23
>288
>270 辺りに言ってやれよ
コメント2件

292
NAME IS NULL[sage]   投稿日:2017/05/03 20:49:46
>291
インデックス使われないマンちぃーす

293
NAME IS NULL[]   投稿日:2017/05/03 21:10:30
お前らが馬鹿なのは使う必要のないインデックスについて延々と話してることだけどな

294
NAME IS NULL[sage]   投稿日:2017/05/03 22:00:09
>288
「使う場合もある」に方向転換w

295
NAME IS NULL[sage]   投稿日:2017/05/03 22:14:57
>282
それ >287 が書いてる通り Bit Map Index Scanだよ
URL読めばわかると思うけど

> ビットマップスキャンは、一度に全てのタプルへのポインタをインデックスから取り出し、
----
インメモリな「ビットマップ」データ構造を使ってソートし
----
> 物理的なタプル位置の順にテーブルのタプルにアクセスします。

つまりyearとmonthに対して個別にインデックス張っときゃソートなんて要らない
要するに >264-265 をディスってるだけなんだが w
コメント6件

296
NAME IS NULL[sage]   投稿日:2017/05/03 22:20:18
結論

>year, monthにインデックス張ればいいだろ
>アホか

297
NAME IS NULL[sage]   投稿日:2017/05/03 22:20:54
まあ、日付型とか言ってる奴は決算月の考慮どうするんだろうと思うわ
コメント2件

298
NAME IS NULL[sage]   投稿日:2017/05/03 22:51:38
またドヤ顔で恥の上塗り

299
NAME IS NULL[sage]   投稿日:2017/05/03 22:56:01
具体的に説明できない奴がわらわら沸いてるw

300
NAME IS NULL[sage]   投稿日:2017/05/03 23:01:34
>297
決算月と日付型との間に問題があるなら後学のために披露しては?
それか質問なら>1読んでからどうぞ

301
NAME IS NULL[sage]   投稿日:2017/05/04 09:47:10
結論だけ言ってて根拠が無ければそれはただの推論

302
NAME IS NULL[sage]   投稿日:2017/05/04 10:19:56
妄想の可能性も...

303
NAME IS NULL[sage]   投稿日:2017/05/04 11:07:26
>287
データ量が多いというのは1億レコードとかそんな単位?
>282は100万件だったけど、1000万件でも同じだよ。

>288
そういう話じゃない。
ストアド作って、where fiscal_year(year, month) = 2017とやると通常はインデックスは使われないが、
普通にクエリ書けば、適切な場面でインデックスが使われるという話だ。

> ルールベースとコストベースの違いも分かってない?
PostgreSQLの話になるが、PostgreSQLにはルールベースのオプティマイザはないよ。

>295
コメントの意図がわからないんだが。

> つまりyearとmonthに対して個別にインデックス張っときゃソートなんて要らない
それ、monthに対するインデックスの意味ないよね。
コメント2件

304
NAME IS NULL[sage]   投稿日:2017/05/04 11:16:06
>303
> データ量が多いというのは1億レコードとかそんな単位?
> >282は100万件だったけど、1000万件でも同じだよ。
マジで仕組みを理解してないんだな w
そっちのデータ量じゃなくてインデックスの方
要するに年と月の数の話

> それ、monthに対するインデックスの意味ないよね。
ないと本気で思ってるなら真面目にもう少し勉強した方がいいと思う
コメント2件

305
NAME IS NULL[sage]   投稿日:2017/05/04 11:33:25
>304
> マジで仕組みを理解してないんだな w
わかるような単語使いましょう。ちゃんと用意されてるんだから。

> 要するに年と月の数の話
カーディナリね。

> ないと本気で思ってるなら真面目にもう少し勉強した方がいいと思う
どういう意味があるんだ?
コメント2件

306
NAME IS NULL[sage]   投稿日:2017/05/04 13:11:20
>305
> カーディナリね。
それを言うならカーディナリティな

> わかるような単語使いましょう。
でかいブーメラン乙 w
きちんと理解せずに背伸びするからそう言う間違いをしちゃうんだよ

> どういう意味があるんだ?
普通にインデックスとして使われるだけだが?
なぜmonthは使われないと思ったんだ?
コメント2件

307
NAME IS NULL[sage]   投稿日:2017/05/04 13:46:35
>306
> それを言うならカーディナリティな
知ってるなら最初から使おうな。

> なぜmonthは使われないと思ったんだ?
使われないから意味ないんだよ。
まぁ、monthを軸にした検索をすれば使われるだろうが、今回の流れとは関係ないね。

俺がコメントを続けた意味が理解できてないようだから、再説明しとこう。

>295
>282
> それ >287 が書いてる通り Bit Map Index Scanだよ
> URL読めばわかると思うけど
これが意味不明なんだが。
bitmap index scanだから何?
コメント2件

308
NAME IS NULL[sage]   投稿日:2017/05/04 14:11:42
脇道の細かい議論しても仕方がないから、論点を絞ろう。

君が主張したいのはこれか?
>259
> 複数の列に張るより単一の方が有利だろう

それに対する俺の主張は、「year, monthに複合インデックス貼る方が有利」。
理由は、
・インデックスが全くない場合は、seq scanになり、論外
・yearのみにインデックスを張った場合、「2017年度」のデータを参照するとき、2年分のデータを読み1年分のデータを捨てる必要がある
・monthのみのインデックスには意味がない
・year, monthにインデックスを張れば、>179のような会計年度別集計などの場合にインデックスが使われる(もちろん、使った方がコスト的に有利な場合)

・(おまけ)year, monthにインデックス張っても、where fiscal_year(year, month) = 2017などとするとインデックスが使われなくなる
・(さらにおまけ)PostgreSQLには、関数インデックスという機能があり「fiscal_year(year, month)」に対してインデックスを貼ることができる
・(蛇足)そこまでするなら、普通にクエリ書け
コメント2件

309
NAME IS NULL[sage]   投稿日:2017/05/04 16:35:58
>307
> 知ってるなら最初から使おうな。
ちゃんとした知識持ってる奴なら >287 のリンク先読めばわかるし
それでわからんような奴にカーディナリティとか言ってもしょうがないだろ
さすがに中途半端にカーディナリとか言う知ったかさんの存在までは想定しとらん

> 使われないから意味ないんだよ。
なぜ使われないんだ?
に対して「使われないから」って日本語大丈夫か?

> まぁ、monthを軸にした検索をすれば使われるだろうが、今回の流れとは関係ないね。
>> (year=2017 and month>=4) or (year=2018 and month<=3)
で関係ないと考える奴にどう説明しろと?

> bitmap index scanだから何?
>287 のリンク先読めよ
それでもわからないと言うから >295 でも説明してる
さらにそれでもわからんと言うならわからない箇所を引用してくれ

すごく中途半端な知識で語ってるようだからどこがわからんのか予測できないし
コメント2件

310
NAME IS NULL[sage]   投稿日:2017/05/04 16:47:15
>308
> ・year, monthにインデックスを張れば、>179のような会計年度別集計などの場合にインデックスが使われる(もちろん、使った方がコスト的に有利な場合)
複合インデックスの話だよね?
それならBit Map Index Scanになるから実行時にインデックスデータについてソート処理が走るんだよ?
そこ理解してる?
ちなみに俺は
> インデックス使いたいならdate型にしとけよ
って言ってるから普通にIndex Scanするだけなのでソート処理なんて要らんから
コメント2件

311
NAME IS NULL[sage]   投稿日:2017/05/04 17:13:18
なんでBit Map Index Scanになるのが当然のような言い方なんだか。
コメント2件

312
NAME IS NULL[sage]   投稿日:2017/05/04 17:21:33
>311
他の方法があると言うなら示してみて

313
NAME IS NULL[sage]   投稿日:2017/05/04 17:22:38
そろそろ結論出して終わりにしてください
結論がまとまらないなら、両論併記で良いと思います

314
NAME IS NULL[sage]   投稿日:2017/05/04 17:28:28
お互い相手のことを馬鹿だと思っているなら
馬鹿相手にムキになっている自分を恥じたほうがいいと思うが
コメント2件

315
NAME IS NULL[sage]   投稿日:2017/05/04 17:48:27
いや既に結論出てるけど理解できない人が食い下がってるだけ

316
NAME IS NULL[sage]   投稿日:2017/05/04 18:23:25
>180で答え出てるから後は設計スレでしてくれ
閑古鳥鳴いてるからウェルカムだぞ
コメント2件

317
NAME IS NULL[sage]   投稿日:2017/05/05 11:22:05
せめて年月から会計年度を返す関数化してくれ

318
NAME IS NULL[sage]   投稿日:2017/05/09 13:37:10
>310
> それならBit Map Index Scanになるから実行時にインデックスデータについてソート処理が走るんだよ?
> そこ理解してる?
その「ソート処理」は、計画ノード種別の「ソート」じゃなくて、Bitmap Index Scanのアルゴリズム上、実装コードで
ソートが必要だということじゃないの?
実際、>282の実行計画には、「ソート」はないわけで。
で、アルゴリズム上、ソートが必要だとして、何か問題でも?

> > インデックス使いたいならdate型にしとけよ
> って言ってるから普通にIndex Scanするだけなのでソート処理なんて要らんから
Index Scanの場合も、aggregateするときに、実装コードでソートが必要な気がするが。
(ソートせずに何回もループしてもいいが、多分ソートするんじゃないかと思う)

319
NAME IS NULL[sage]   投稿日:2017/05/09 13:48:09
ケースバイケース

320
NAME IS NULL[sage]   投稿日:2017/05/09 13:48:27
>309
> なぜ使われないんだ?
なぜもクソも使わないんだよ。

> >> (year=2017 and month>=4) or (year=2018 and month<=3)
> で関係ないと考える奴にどう説明しろと?
関係ないね。
関係あるというなら、テストデータ作って実行計画出してみな。

> すごく中途半端な知識で語ってるようだからどこがわからんのか予測できないし
俺がお前に言いたい言葉だな。

321
NAME IS NULL[sage]   投稿日:2017/05/09 14:10:30
親切なので、year, monthに個別にindexを張った場合の実行計画を取ってみた。
https://explain.depesz.com/s/UapJ

書き忘れたが、
> インデックス使いたいならdate型にしとけよ
大本の話は会計年度で集計するときの話。
date型なら会計年度を取得して集計する必要があって、そこでストアドやビルトイン関数使うと
日付カラムにindexあっても使われないって話な。

さらに言えば、会計年度カラム追加しろとかいう話なら、今のままで複合インデックスつけて普通に
検索しろってこった。
(何度ループするんだよ)

322
NAME IS NULL[sage]   投稿日:2017/05/09 14:24:55
さらにおまけ。

# \d fuga
テーブル "public.fuga"
列 | 型 | 修飾語
--------+---------+--------
dt | date |
amount | integer |
インデックス:
"fuga_idx" btree (dt)

explain analyze verbose select sum(amount) from fuga where dt between '2013-04-01' and '2014-03-31';

実行計画:
https://explain.depesz.com/s/533s
Bitmap Index Scanになってますが。

323
NAME IS NULL[sage]   投稿日:2017/05/09 14:55:26
これにもレスしとこう。

前提として、seq scanではパフォーマンス的に問題があるレベルのレコード数の場合。
>316
> >180で答え出てるから後は設計スレでしてくれ

whereで式を使うと、そのカラムにインデックスがあっても使われない。
> Seq Scan on public.hoge (cost=0.00..30406.00 rows=5000 width=12) (actual time=0.028..253.216 rows=100600 loops=1)
> Output: year, month, amount
> Filter: ((((hoge.year * 100) + hoge.month) >= 201604) AND (((hoge.year * 100) + hoge.month) <= 201703))
> Rows Removed by Filter: 899400
> Execution time: 288.702 ms

なお、PostgreSQLには式インデックスという機能があって、それを作ればインデックスが使われる。
create index hoge_calc_idx on hoge((year*100+month));
> Bitmap Index Scan on hoge_calc_idx (cost=0.00..106.42 rows=5000 width=0) (actual time=13.776..13.776 rows=100600 loops=1)
> Index Cond: ((((hoge.year * 100) + hoge.month) >= 201604) AND (((hoge.year * 100) + hoge.month) <= 201703))
> Execution time: 74.346 ms
コメント2件

324
NAME IS NULL[sage]   投稿日:2017/05/09 18:45:08

325
NAME IS NULL[sage]   投稿日:2017/05/10 10:29:23
>324
まあ、微粒子レベルで俺が間違ってる可能性があるからな
コメント2件

326
NAME IS NULL[sage]   投稿日:2017/05/10 10:41:42
>325
お前が>323なら、おかしいのはお前の相手の方だから心配すんな
>268からずっとおかしい
相手するだけ無駄

327
NAME IS NULL[sage]   投稿日:2017/05/10 10:55:53
今時、コストベースがどうこうとか言う奴だからな。
10年以上前にちょろっとDB触ったレベルの奴じゃね?

328
NAME IS NULL[sage]   投稿日:2017/05/10 14:06:04
・ストアドにしてオーバーロードしろ
・インデックス使いたいならdate型にしろ
・date型にしないなら個別インデックスにしろ
・Bit Map Indexガー
・ソートガー

全部同じやつでしょ
最初からおかしい

329
NAME IS NULL[sage]   投稿日:2017/05/10 17:35:34
今更というかやっと式インデックスが出てくる脱力感
コメント2件

330
NAME IS NULL[sage]   投稿日:2017/05/10 18:21:15
>329
式なんか使わずに普通にクエリ書けと何度言ったら

331
NAME IS NULL[]   投稿日:2017/05/15 18:17:10
Local and global coordinate system

332
NAME IS NULL[sage]   投稿日:2016/07/10 22:29:01  ID:???.net(298)
このスレは
「こういうことをやりたいんだけどSQLでどう書くの?」
「こういうSQLを書いたんだけどうまく動きません><」
などの質問を受け付けるスレです。

SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。

質問するときはDBMS名を必ず付記してください。

【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明

前スレ:
SQL質疑応答スレ 16問目

333
NAME IS NULL[sage]   投稿日:2016/07/10 22:29:31  ID:???.net(298)

334
NAME IS NULL[sage]   投稿日:2016/07/10 22:30:30  ID:???.net(298)

335
NAME IS NULL[sage]   投稿日:2016/07/10 22:30:52  ID:???.net(298)
よくある質問1

(問)
ID | DATE     | DATA
--+----------+-----
1 | 2007-11-11 | aaa
2 | 2007-11-11 | bbb
1 | 2007-11-10 | ccc
3 | 2007-11-12 | ddd
3 | 2007-11-11 | eee
4 | 2007-11-10 | fff
1 | 2007-11-12 | ggg

このようなテーブルから、下記のように

1 | 2007-11-12 | ggg
3 | 2007-11-12 | ddd
2 | 2007-11-11 | bbb
4 | 2007-11-10 | fff

各idに対して最新の1件だけ抽出するSQLの書き方を教えてください。

(答)
select A.ID,
    A.DATE,
    A.DATA
from TableName A
   inner join
   (select ID, max(DATE) as MAX_DATE
    from TableName
    group by ID
   ) B
   on A.ID = B.ID
   and A.DATE = B.MAX_DATE
;

336
NAME IS NULL[sage]   投稿日:2016/07/10 22:31:14  ID:???.net(298)
よくある質問2

(問)
key   data
----------------
1     a
1     a
1     b
1     b
1     a
2     b
2     a
2     a

というテーブルから

key   a   b
--------------------
1    3   2
2    2   1

というExcelのピボットの様なデータを取得したいのですが、どういうSQLになりますか?
a,bというのは固定なので、仮にcというデータがあっても無視して構いません。

(答)
SELECT key,
    SUM(CASE data WHEN 'a' THEN 1 END) AS a,
    SUM(CASE data WHEN 'b' THEN 1 END) AS b
FROM table
GROUP BY key
ORDER BY key
;

337
NAME IS NULL[sage]   投稿日:2016/07/10 22:34:14  ID:???.net(298)
よくある質問3

(問)
ID HOGE
01 A
01 B
01 C
02 A
03 B

HOGEをAもBもCも持っている、ID:01だけ取り出すにはどうすればよかですか

(答1)
SELECT id
FROM TableName
WHERE hoge in ('A','B','C')
GROUP BY id
HAVING count(DISTINCT hoge) = 3
;

(答2)
select *
from TableName T1
where not exists (select *
         from (values 'A', 'B', 'C') T2 (HOGE)
         where not exists (select *
                  from TableName T3
                  where T1.ID = T3.ID
                  and T2.HOGE = T3.HOGE
                  )
         )
;
※valuesの部分(Table Value Constructor)はDBMSによって文法がかなり違うので注意

338
NAME IS NULL[sage]   投稿日:2016/07/10 22:34:59  ID:???.net(298)
よくある質問4

(問)
列の数が可変な問合せはどう書きますか?

(答)
標準SQLでは書けません。
pivotという機能を搭載したDBMSなら一見書けそうですが実はやっぱり書けません。
Oracle 11g以降でpivot xmlというキーワードを使用すれば一応可変っぽくはなります。
が、素直にプロシージャを書くかアプリケーションで処理したほうが良いでしょう。

SQL Serverのpivot(2005以降)
http://msdn.microsoft.com/ja-jp/library/ms177410.aspx

Oracleのpivot(11g以降)
http://download.oracle.com/docs/cd/E16338_01/server.112/b56299/statement...#CHDCEJJE
http://www.oracle.com/technetwork/articles/sql/11g-pivot-097235.htm...

339
NAME IS NULL[sage]   投稿日:2016/07/10 22:46:13  ID:???.net(298)
ううむ、ブロックされてしまいました。どうしたらいいだろう。

Why have I been blocked?

This website is using a security service to protect itself from online attacks.
The action you just performed triggered the security solution.
There are several actions that could trigger this block including submitting a
certain word or phrase, a SQL command or malformed data.

340
NAME IS NULL[sage]   投稿日:2016/07/10 22:47:49  ID:???.net(298)
SQLソースの部分は外しておきます。

よくある質問5

(問)
年月(YYYYMM)を指定し、その年月に対応する年月日を取得したい

 例:201006を指定したら、以下の結果を得たい

   20100601
   20100602
    ・
    ・
    ・
   20100630

(答)
SQLでは存在しないデータを生成することはできません。
この問いの場合は素直にカレンダーテーブルを用意しましょう。

どうしてもやりたければ以下のような方法もなくはないですが、
再帰問合せの本来の使い方ではありません。
やめておくことを強くお奨めします。
(PostgreSQLのgenerate_series()関数なら辛うじてセーフかもしれませんが
 賛否の分かれるところでしょう。)

341
NAME IS NULL[sage]   投稿日:2016/07/10 22:49:00  ID:???.net(298)
以上、テンプレ終わり

よくある質問5のSQLソース部分がアタックと受け止められてしまいました。
そのためソースは省略しました。

342
NAME IS NULL[sage]   投稿日:2016/07/14 01:37:12  ID:???.net(298)
ここで募集するのも筋違いだとおもうけど、SQLの文を書いたのを訂正してほしい・・・
中級者には30分ほどでおわる内容かも。
謝礼は7000で、
多分、チョー簡単。
詳しくは
remorse2015@yahoo.co.jp
日曜までとりあえず募集します。
メールで内容確認だけでも良いです/

343
NAME IS NULL[sage]   投稿日:2016/07/14 03:19:38  ID:???.net(298)
ここに内容書けば無料なんだけど

344
NAME IS NULL[sage]   投稿日:2016/07/15 02:26:47  ID:???.net(298)
>12
お願いできないですか?
ワードに見本表と完成表があってコード書かれているんですが、間違えてる文がある感じです。22ページあったんですが16から全然進まなくて、、、
とりあえず、メールお願いします。
ワードファイル添付しておくります。
支払いはすぐやります。

345
NAME IS NULL[sage]   投稿日:2016/07/15 09:39:41  ID:???.net(298)
プレーンテキストでここに貼って

346
NAME IS NULL[sage]   投稿日:2016/07/15 10:18:31  ID:???.net(298)
ワードファイル送りつけられても迷惑メールからのゴミ箱インよ

347
NAME IS NULL[sage]   投稿日:2016/07/15 11:41:49  ID:???.net(298)
SELECT *
FROM 氏名表 AS A
WHERE A.番号=
(SELECT 番号
FROM 成績表
WHERE 点数=479)


SELECT *FROM 氏名表 AS A
WHERE A.番号IN
(SELECT 番号
FROM 成績表
WHERE 点数>=500)
という間違った文があって
SELECT *
FROM 氏名表 AS A
INNER JOIN
(SELECT 番号
FROM 成績表
WHERE 点数=479) AS B
ON A.番号=B.番号

SELECT *
FROM 氏名表 AS A
INNER JOIN
(SELECT 番号
FROM 成績表
WHERE 点数>=500) AS B
ON A.番号=B.番号
を治すというものでこんなのを20個くらいやれば終わりです。

348
NAME IS NULL[sage]   投稿日:2016/07/15 13:52:48  ID:???.net(298)
金もらって引き受けるほどの仕事じゃないようだし
そういう手間かけるくらいなら、ご自身で治した方が良いのでは?

349
NAME IS NULL[sage]   投稿日:2016/07/15 14:14:56  ID:???.net(298)
> SELECT *FROM 氏名表 AS A
> WHERE A.番号IN
> (SELECT 番号
> FROM 成績表
> WHERE 点数>=500)

これは何が間違ってるんだ?

350
NAME IS NULL[sage]   投稿日:2016/07/15 14:20:47  ID:???.net(298)
要件を教えて欲しいのだが。何を直せばいいいんだ?

351
NAME IS NULL[sage]   投稿日:2016/07/15 15:30:39  ID:???.net(298)
>16
inをjoinに置き換えろって話のようにみえるけど
joinしたビュー作っとけばもっと楽かもしれんぞ

そもそもそんなことする必要があるのか
一度inとjoinで実行計画見といた方が良いんじゃね

>18
文法的に間違ってるってなら、番号とINの間に空白がないとかじゃねw

352
NAME IS NULL[]   投稿日:2016/07/15 15:46:23  ID:zBhn779u.net(6)
これについてはインラインビュー(FROM句の副問い合わせ)はやめた方がいいな。

WHERE句で絞った方がいい。

353
NAME IS NULL[sage]   投稿日:2016/07/15 16:18:18  ID:???.net(298)
同感

354
NAME IS NULL[sage]   投稿日:2016/07/15 16:41:58  ID:???.net(298)
実行計画見るまでもないレベルのデータ量な気がするが。
何やっても数百ms程度で戻る気が。

355
NAME IS NULL[sage]   投稿日:2016/07/15 16:57:08  ID:???.net(298)
>21
その理由は?
単なる性能的な話なら、まず実行計画見るよって事だし

whereがどうこうじゃなくて、inの方だと、結果セットに点数含まれないのが問題なんじゃないのか

>23
データ量は示されてないし、実際のテーブルレイアウトがどうなってるかもわからんし
まあ、性能的な問題じゃないと思うけど

356
NAME IS NULL[sage]   投稿日:2016/07/15 17:22:52  ID:???.net(298)
>24
> データ量は示されてないし、実際のテーブルレイアウトがどうなってるかもわからんし
> まあ、性能的な問題じゃないと思うけど
氏名表:1,000レコード未満
成績表:100,000レコード未満
くらいかなと。

まあどんなクエリ書こうがたいしたことないと思うが、性能云々ならindexを貼るくらいでいいのでは。

357
NAME IS NULL[]   投稿日:2016/07/15 18:52:57  ID:OwU9VU0D.net(4)
答えたい気持ちは分かるがお前ら7000円をどうやって分けるつもりなの?
そういう事は最初にキッチリ決めとかないと後々遺恨を残すぜ

358
NAME IS NULL[sage]   投稿日:2016/07/15 19:15:33  ID:???.net(298)
僕のために争ってくれてありがとう。
依頼する人は見つけたから大丈夫だよー
これで単位も一安心

359
NAME IS NULL[]   投稿日:2016/07/15 19:51:07  ID:zBhn779u.net(6)
>24
理由も何もまずはSQLの普通の書き方しろってことだよ。

360
NAME IS NULL[]   投稿日:2016/07/15 19:53:41  ID:zBhn779u.net(6)
>24
INリストには数の制限があるからな。

OR条件の羅列にすぎない。

361
NAME IS NULL[]   投稿日:2016/07/15 20:33:15  ID:OwU9VU0D.net(4)
>29
お前はバカなんだから口を慎しめと何度

362
NAME IS NULL[]   投稿日:2016/07/16 17:02:32  ID:IKSp3mrg.net(4)
>30
どこが間違っているのか教えてください。

363
NAME IS NULL[]   投稿日:2016/07/16 17:08:06  ID:IKSp3mrg.net(4)
↓これ何?

26 NAME IS NULL 2016/07/15(金) 18:52:57.55 ID:OwU9VU0D
答えたい気持ちは分かるがお前ら7000円をどうやって分けるつもりなの?
そういう事は最初にキッチリ決めとかないと後々遺恨を残すぜ

364
NAME IS NULL[]   投稿日:2016/07/17 21:52:20  ID:N1m3wNQ4.net(4)
すみません、以下、質問させてください。

親テーブルAに対して子テーブルBとCがあり、
レコード数がそれぞれ、
A:B = 1:5、A:C = 1:20 の関係です。

この時、A1レコードに対して、
Aに紐付くBとCのレコード全てを最小のIO回数・データ量で取得したいです。

普通にA、B、Cを結合しただけでは
B×Cの組み合わせまで取得してしまい上手く取得できませんでした。
A:B、A:Cと別々に結合して取得するしかないのでしょうか。
DBはOracleです、よろしくお願いします。

365
NAME IS NULL[]   投稿日:2016/07/17 22:41:52  ID:2o6ZRKeT.net(2)
>33
リレーションの説明がありませんので、答えようがありません。

366
NAME IS NULL[sage]   投稿日:2016/07/17 22:58:48  ID:???.net(298)
B×Cの中から自分が欲しいものを条件で絞り込むんだよ。その条件が無いから全部出てくる。

367
NAME IS NULL[]   投稿日:2016/07/17 23:00:32  ID:N1m3wNQ4.net(4)
>34
下のような感じです。
AとB、AとCが主キー項目aでそれぞれ1:5、1:20で紐付きます。

Aテーブル
a C(5)


Bテーブル
a C(5)
b C(5)


Cテーブル
a C(5)
c C(5)

368
NAME IS NULL[]   投稿日:2016/07/17 23:02:11  ID:fmLQHPFo.net(2)
おもしろい展開w

369
NAME IS NULL[sage]   投稿日:2016/07/17 23:41:31  ID:???.net(298)
質問がいまいち理解できん
そもそもIOとか、SQL書いたとおりに実行されるわけじゃないんだが

ほしい結果がABとACの二つあるなら、2回やるしかないわけだが、どんな結果を望んでるんだ

370
NAME IS NULL[]   投稿日:2016/07/18 00:53:22  ID:EKBnHgrJ.net(10)
>38
俺もI/Oについては突っ込みたかったが、そもそもRDBの理論、概念を否定する内容だからスルーしたw

371
NAME IS NULL[]   投稿日:2016/07/18 00:55:52  ID:EKBnHgrJ.net(10)
>36
その"C(5)"って何?

データ型?

372
NAME IS NULL[]   投稿日:2016/07/18 01:03:46  ID:EKBnHgrJ.net(10)
>36
その3つのテーブルをaという列だけで結合すればいい話なのかな?

Aテーブルの1レコードに対して20レコードがセットになればいいの?

373
NAME IS NULL[]   投稿日:2016/07/18 01:12:13  ID:EKBnHgrJ.net(10)
BテーブルとCテーブルにリレーション、関連性があるのかないのかはっきりしてくれ。

AテーブルのとあるレコードはBテーブルに子レコードがあり、Aテーブルの別の種類のレコードはCテーブルに子レコードがあるようにも解釈できる。

どっちなの?

374
NAME IS NULL[sage]   投稿日:2016/07/18 01:17:58  ID:???.net(298)
unionの話じゃないのかい

375
NAME IS NULL[]   投稿日:2016/07/18 03:30:28  ID:Dk5LLrvU.net(4)
>39
RDBの理論が分かってないのはお前な


376
NAME IS NULL[]   投稿日:2016/07/18 06:25:57  ID:EKBnHgrJ.net(10)
>44
それはRDBMSのことであって特定の製品を指しているわけでもない。

377
NAME IS NULL[]   投稿日:2016/07/18 08:25:50  ID:Dk5LLrvU.net(4)
>45
ワケ分からん事言ってないで必死でググって顔真っ赤にして感謝しろよw
今頃もう真っ赤っ赤かなw

378
NAME IS NULL[]   投稿日:2016/07/19 00:50:27  ID:yVILcX3x.net(2)
RDBMSはSQLの処理の方法にRDBMSに任せるのがRDBなんだよ。

どう処理するかの手続きを指定するのはするのはRDBではない。

379
NAME IS NULL[sage]   投稿日:2016/07/19 03:30:05  ID:???.net(298)
とりあえず書き込む前に書こうまず読み直してとりあえず書こう

380
NAME IS NULL[sage]   投稿日:2016/07/19 04:19:10  ID:???.net(298)
慌てないで、落ち着いて

381
NAME IS NULL[]   投稿日:2016/07/20 11:14:56  ID:89VCRaWj.net(2)
【BS11:エンターテイメント】 <関根勤 KADENの深い夜>放送時間:毎週木曜日 よる11時00分〜11時30分 #bs11 http://www.bs11.jp/entertainment/5749/

382
NAME IS NULL[sage]   投稿日:2016/07/24 10:41:37  ID:???.net(298)

383
NAME IS NULL[]   投稿日:2016/07/27 21:37:51  ID:OesecO5v.net(4)
ジョインで連結しまくったクエリに
ORDER BY で並び替えかけると
えらい遅くなるのですが
改善する方法はないのでしょうか?

384
NAME IS NULL[sage]   投稿日:2016/07/27 21:48:05  ID:???.net(298)
ジョインしたかどうかとソートの速度に関係はない
ソートのキーとなる列にインデックスを張っておけばソートが不要になる場合がある
ソートキーが複数のテーブルに跨るとすると話は面倒臭い
VIEWにインデックスを張れるDBMSならそれで解決するのも手

385
NAME IS NULL[sage]   投稿日:2016/07/27 21:58:01  ID:???.net(298)
的確。

386
NAME IS NULL[]   投稿日:2016/07/27 22:33:44  ID:OesecO5v.net(4)
>53
インデックスの貼り方がわるいのか
リレーションに関するカラムを中心に
インデックスはっても遅いんです。
特に GROUP BY と ORDER BY の組みあわせ

387
NAME IS NULL[sage]   投稿日:2016/07/27 22:52:26  ID:???.net(298)
GROUP BYもあるならmaterialized viewにしてインデックス張るしかないかな
メモリをひたすら積んでメモリソートでごり押しという手もあるが

388
NAME IS NULL[sage]   投稿日:2016/07/27 23:13:51  ID:???.net(298)
テーブルレイアウトと実行してるSQL全部書けば
ある程度汎用的なインデックスのアドバイスができるかもしれんが

まあとりあえず実行計画確認しろ

389
NAME IS NULL[sage]   投稿日:2016/07/27 23:27:08  ID:???.net(298)
【質問テンプレ】
・DBMS名とバージョン

この辺も書いておくといいぞ

390
NAME IS NULL[]   投稿日:2016/07/28 00:48:24  ID:Pc5r9mq6.net(2)
テーブルレイアウトって言葉はやめてほしいわ。

391
NAME IS NULL[sage]   投稿日:2016/07/28 10:49:25  ID:???.net(298)
うちのダイニングのテーブルの配置はどう言ったらいいでしょうか

392
NAME IS NULL[sage]   投稿日:2016/07/28 14:59:33  ID:???.net(298)
 
粗大ゴミの回収に出す

393
NAME IS NULL[]   投稿日:2016/07/29 09:54:35  ID:SbaxQ6kv.net(2)
MySQL 5.1.73
次のようなカラムの入ったメインテーブルがあるとします。

T1
|MAIN_ID|NAME|AGE|TITLE_1|COMMENT_1|TITLE_2|COMMENT_2|

で、TITLE と COMMENT の部分は
横持ちになってるのでその部分は別テーブルにして

T2
|ID|MAIN_ID|TITLE|COMMENT|

として、縦持ちにしたいとします。

問題は、この2つのテーブルをどうリレーションさせるかです。
例えば 次のようなレコードが入っているものを次のようにリレーションしようとします。

T1
|MAIN_ID|NAME|AGE|
|1    |田中 |24|



T2
|ID|MAIN_ID|TITLE|COMMENT|
|1 |   1|好きな|うな重 |
|2 |   1|趣味 |バイク |
|3 |   1|嫌いな|しいたけ|
|4 |   2|好きな|グラタン|


FROM
 T1
 LEFT JOIN
 T2
 ON
 T1.MAIN_ID = T2.MAIN_ID

で関連付けられ 

|ID|MAIN_ID|NAME|AGE|TITLE|COMMENT|
|1 |1   |田中 |24|好きな|うな重 |
|1 |1   |田中 |24|趣味 |バイク |
|1 |1   |田中 |24|嫌いな|しいたけ|

この例で行くと田中が3つになります。
また、 WHERE でTITLE、COMMENTが検索対象にできるようになります。

10件表示とか リストで出力すると この例では田中が3つでてきてしまうので
GROUP BY で ID をまとめます。 
その際 ORDER BYをかけると 何千件とかになると
パフォーマンスが非常に落ちてしまいます。
※ ORDER BYがなければパフォーマンスはそれほど問題はありません。

パフォーマンスをなるべく落ちないように
縦持ちカラムを組み合わせるにはどうすればいいでしょうか?

394
NAME IS NULL[sage]   投稿日:2016/07/29 10:09:10  ID:???.net(298)
それだとGROUP BYよりEXISTSのほうがよくね?

select T1のカラム
from T1
where exists (
  select *
  from T2
  where T1.MAIN_ID = T2.MAIN_ID
  and T2の条件
)
order by T1のカラム

395
NAME IS NULL[sage]   投稿日:2016/07/29 14:04:30  ID:???.net(298)
>62
>GROUP BY で ID をまとめます。
それだとIDと1:1に結び付かない項目は全て不定だぞ
つまり結局T1のみselectするのと同じになるわけだが
それならまずはT1のソート項目にインデックス張って見るとか

ああ、またMySqlか
SelectとGruop ByとOrder ByとWhereと全部書いたフルのSQL晒せ

396
NAME IS NULL[]   投稿日:2016/07/30 07:56:46  ID:XyUbordV.net(2)
ない項目のインデックスはどうやって作るのか

397
NAME IS NULL[sage]   投稿日:2016/07/30 08:19:54  ID:???.net(298)
ない項目ってどういう意味だ?
インデックスは項目(の組み合わせ)に対して作るものだぞ

398
NAME IS NULL[sage]   投稿日:2016/07/31 02:18:28  ID:???.net(298)
質問です。
学生メール表 学籍番号 氏名 メールアドレス
教員メール表 教員番号 氏名 メールアドレス
補習予定表 教員番号 授業id 日付 連絡事項
授業名表 授業iD 授業名
授業展開表 教員番号 授業id 学籍番号
これで生徒に知らせる時のER図をつくるとき、
いらない情報はどれですか?
学生メール表⇔授業中展開表⇔授業名表⇔補習予定表

399
NAME IS NULL[sage]   投稿日:2016/07/31 09:46:00  ID:???.net(298)
>67
自分で決める事では

400
NAME IS NULL[]   投稿日:2016/07/31 12:33:09  ID:ea2io0T3.net(2)
>67
必要最低限にしてもいいけど、実際にはいちいち結合しないと取得できないので重複して持つこともある。

401
NAME IS NULL[sage]   投稿日:2016/07/31 14:20:50  ID:???.net(298)
ちなみに>67はおかしいですか?
先生にしらせるときと生徒に知らせる時でER図を書きなさいって問題なんですが

402
NAME IS NULL[sage]   投稿日:2016/07/31 16:02:20  ID:???.net(298)
問題に書いてあることを誤読や読み落とししている気がする。

403
NAME IS NULL[sage]   投稿日:2016/07/31 17:31:55  ID:???.net(298)
宿題を堂々とここに書いて教えろと要求かぁ

404
NAME IS NULL[sage]   投稿日:2016/07/31 21:26:13  ID:???.net(298)
まずER図書いてみろって話だが

エスパーすると授業展開表.教員番号か補習予定表.教員番号

各テーブルの主キーが不明なんでどっちにしろ正確な答えはだぜんぞ

405
NAME IS NULL[sage]   投稿日:2016/08/08 22:56:12  ID:???.net(298)
・DBMS名とバージョン
 SQLServer2014 ent.

・テーブルデータ
 名前 月 欠席日数
 a    1     1
 a    3     1
 b    1     1

・欲しい結果
 名前 月 欠席日数
 a    1     1
 a    2     0
 a    3     1
 b    1     1
 b    2     0
 b    3     0

・説明
 欠けてる月のデータを 0 補完したいと思います。
 「名前」列がなければ例えば下のようなテーブルと外部結合することで解決できるのですが、
 「名前」ごとに「月」と「欠席日数」を補完する方法が分かりません。
 「名前」列を含めて保管用のテーブルを作ることも考えられるのですが、「名前」の数が多い場合に困ります。
 月 欠席日数
 1     0
 2     0
 3     0

お知恵をお貸し下さい。
お願いします。

406
NAME IS NULL[sage]   投稿日:2016/08/08 23:54:36  ID:???.net(298)
名前テーブルも作ってそれと外部結合すりゃいいじゃん。

407
NAME IS NULL[sage]   投稿日:2016/08/09 00:00:01  ID:???.net(298)
id,name
--------
1,aaa
2,bbb
3,ccc

これにdddを1の下に追加して

id,name
--------
1,aaa
4,ddd
2,bbb
3,ccc

という風に出来るデータベースってありませんか? 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

408
NAME IS NULL[sage]   投稿日:2016/08/09 01:13:18  ID:???.net(298)
表示をその順序にしたいと言うなら、
その順序指定になるカラムを追加したら?

409
NAME IS NULL[sage]   投稿日:2016/08/09 08:40:05  ID:???.net(298)
>76
> これにdddを1の下に追加して

できない
上とか下の概念がないから

410
NAME IS NULL[sage]   投稿日:2016/08/09 09:32:25  ID:???.net(298)
mysqlでやってみた

select id , name ,
case name when "aaa" then 1
when "bbb" then 3
when "ddd" then 2
when "ccc" then 4
end as newcol
from hogehoge
order by newcol;

+----+------+---------+
| id | name | newcol |
+----+------+---------+
| 1 | aaa | 1 |
| 4 | ddd | 2 |
| 2 | bbb | 3 |
| 3 | ccc | 4 |
+----+------+---------+

結局は>77さんの通りにやってるだけだし、件数が多ければやってられんw

411
NAME IS NULL[sage]   投稿日:2016/08/09 10:03:52  ID:???.net(298)
select id , name ,
case name
when "aaa" then 1
when "ddd" then 2
else null
end as newcol
from hogehoge
order by newcol is null;

412
NAME IS NULL[sage]   投稿日:2016/08/09 18:34:23  ID:???.net(298)
>74
普通は名前のマスタテーブル用意しとくんじゃね
まあ、なければないで効率とか考えないなら
select distinct 名前 from ...
とかで代用できなくもないけど

>76
すくなくとも、RDBでそれは基本的な考え方から外れてるから無理

データ補完とか、順序付けされてないデータの順序とか、設計考え直せ

413
74[sage]   投稿日:2016/08/09 23:16:58  ID:???.net(298)
>75,81
ありがとう。
75 で言われてハッとして distinct で作った名前の一覧と月の一覧とを掛け合わせて、
これと元のテーブルデータを外部結合して行けました。

414
NAME IS NULL[]   投稿日:2016/08/10 16:43:00  ID:tK4Szt1X.net(2)
SQLと直接関係ないのですが
お名前.comSDサーバーの データベースって
sshで入って dumpコマンドでエクスポートできないので
バックアップを取ることができないのですが
なにかうまく取る方法ないですか?

415
NAME IS NULL[sage]   投稿日:2016/08/10 16:49:54  ID:???.net(298)
>83
お名前.com sdサーバー データベース バックアップ
でググったらすぐに見つかったが?

416
NAME IS NULL[sage]   投稿日:2016/09/24 02:19:33  ID:???.net(298)
○前提
会社id、名前や所在地などが入っている会社テーブルと、
会社id、従業員名、性別などが入っている従業員テーブルがあるとして、
(プログラム側で外部から受け取った)会社idから名前や所在地を得て、かつ、その会社の従業員を列挙表示したい

○質問
こういうとき、DB側、SQL側としては、会社テーブル・従業員テーブルそれぞれ1回ずつ2回SELECT発行するしかないでしょうか

417
NAME IS NULL[sage]   投稿日:2016/09/24 03:18:01  ID:???.net(298)
>85
joinを知らないとか分からないとか、そういうレベル?
とりあえず>1読んで出直して

418
NAME IS NULL[sage]   投稿日:2016/09/24 03:54:37  ID:???.net(298)
>86
joinすると全レコードに>85で言う会社テーブルの名前、所在地などが入ってきませんか
返してもらうデータ量よりクエリ発行回数を気にするべきなんでしょうか

また>85には書いていないことですがjoin対象が複数あったら、など考えるとどう考えたら良いのか

419
NAME IS NULL[sage]   投稿日:2016/09/24 07:52:00  ID:???.net(298)
>join対象が複数あったら、

複数joinすれば?

420
NAME IS NULL[sage]   投稿日:2016/09/24 11:06:44  ID:???.net(298)
深く考える前にやってみればいいんじゃないかな、とか。

421
NAME IS NULL[sage]   投稿日:2016/09/24 18:45:29  ID:???.net(298)
>87
>データ量よりクエリ発行回数を気にするべきなんでしょうか
そんなもんはケースバイケースだからすきにしろ
もともとクエリ発行回数を問題にしたのはお前だろうが

422
NAME IS NULL[sage]   投稿日:2016/09/24 21:03:47  ID:???.net(298)
>85
その前提なら
> 会社テーブル・従業員テーブルそれぞれ1回ずつ2回SELECT発行する
でいいと思う

423
NAME IS NULL[sage]   投稿日:2016/09/24 21:21:17  ID:???.net(298)
いや、1回SELECT発行がいいと思う

424
NAME IS NULL[]   投稿日:2016/09/24 21:23:50  ID:dG2/rE9U.net(2)
この場合それぞれ2回ずつSELECTが正解じゃね?

425
NAME IS NULL[sage]   投稿日:2016/09/25 07:15:27  ID:???.net(298)
従業員に付与される会社情報の多さが気になるなら2回でいいんじゃね
というか自分も2回だね

426
NAME IS NULL[sage]   投稿日:2016/09/25 08:00:17  ID:???.net(298)
>93
2回ずつ?
なんのために?

427
NAME IS NULL[sage]   投稿日:2016/09/25 09:14:27  ID:???.net(298)
>85
〇足りない情報
どんなときに使う処理か(バッチ?それともユーザー操作に対する応答?)
出力はどのような形式か(画面表示?CSVファイル?)
データベースを配置しているサーバーと出力を得るクライアントの構成は?(例:PostgreSQLto
Apacheが同じサーバーにあり、クライアントはWEB表示で結果を得る。サーバーはAWSに配置しており、ネットワークの転送速度は毎秒1MBr程度が期待できる)
レコードは何件あるのか。レコードあたりの容量は?要求されるレスポンスは?(1秒以内に出力完了など)。

428
NAME IS NULL[sage]   投稿日:2016/09/25 09:19:53  ID:???.net(298)
転送速度が極端に遅い場合はローカルにデータベースをもってジョインするのも選択肢としてあり得なくもないが(2層方式も含めて検討だろう)
それだったら出力結果を圧縮して転送だろうな
HTTPで出力する場合は例えばgzip圧縮すりゃ設定いじる程度の工数で済むしな

429
NAME IS NULL[sage]   投稿日:2016/09/25 10:29:39  ID:???.net(298)
富豪アプローチで毎回取得&キャッシュでええやん。

430
NAME IS NULL[sage]   投稿日:2016/09/25 10:40:03  ID:???.net(298)
時間も掛かるし負荷も高いんじゃない?

431
NAME IS NULL[sage]   投稿日:2016/09/25 16:03:47  ID:???.net(298)
月額2000円くらいの予算でvps借りるとしてmysqlで最大どれくらいのトランザクションを捌けるもんなの?

432
NAME IS NULL[sage]   投稿日:2016/09/25 16:07:28  ID:???.net(298)
要件定義してあげるスレが必要

433
NAME IS NULL[sage]   投稿日:2016/09/30 00:05:15  ID:???.net(298)
どこで質問したらわからないんですが総合スレってありませんかね?

434
NAME IS NULL[sage]   投稿日:2016/09/30 14:16:58  ID:???.net(298)

435
NAME IS NULL[]   投稿日:2016/11/09 18:56:03  ID:AtwDWs/+.net(4)
Mysql で 出力データーを
20.00 → 20
21.40 → 21.4
23.05 → 23.05
20.10 → 20.1
みたいに少数以下の語尾のゼロを取ることをMySQL内ですることはできないでしょうか?

436
NAME IS NULL[sage]   投稿日:2016/11/09 19:00:44  ID:???.net(298)
普通付かないだろ
元の値は文字列なのか?

437
NAME IS NULL[]   投稿日:2016/11/09 19:05:31  ID:AtwDWs/+.net(4)
>105
decimal です。

438
NAME IS NULL[sage]   投稿日:2016/11/09 19:39:25  ID:???.net(298)
>104
なぜゼロ取りたいの?

439
NAME IS NULL[]   投稿日:2016/11/14 22:17:52  ID:bmYVZ934.net(2)
truncとかfloorとか
文字ならsubstrみたいなやつで

440
NAME IS NULL[sage]   投稿日:2016/11/18 01:26:39  ID:???.net(298)
アドバイスをいただきたく
CFINFOテーブルのカラムが全てcharでvarcharに変更したい場合のSQLです。
数十件のデータではテストしてOKでしたが、大量のデータだと問題でそうですかね?

alter table CFINFO modify (
CF_GROUP VARCHAR2(10),
CF_NAME VARCHAR2(30),
CF_ID VARCHAR2(50),
CF_PSWD VARCHAR2(50)
)
/
update CFINFO d
set (d.CF_GROUP,d.CF_NAME,d.CF_ID,d.CF_PSWD)
= (
select trim(CF_GROUP),trim(CF_NAME),trim(CF_ID),trim(CF_PSWD)
from CFINFO m
where d.CF_NO = m.CF_NO
)
/

441
NAME IS NULL[]   投稿日:2016/11/21 06:49:29  ID:sXX+G/pS.net(2)
>109
/があるあたりでOracleだと思うが、なんで並列処理化するとか考えないの?

442
NAME IS NULL[sage]   投稿日:2016/11/21 11:05:47  ID:???.net(298)
というか、ふつうにhoge=trim(hoge)で良い気がするんだが
なんで自己結合する必要があるんだ

443
NAME IS NULL[sage]   投稿日:2016/11/21 11:19:03  ID:???.net(298)
それか元のテーブルをRENAMEして
新しいテーブルにINSERT SELECTしたら?
表領域足りんのか

444
NAME IS NULL[]   投稿日:2016/11/21 18:31:53  ID:CmVzeDRz.net(2)
mysqlの質問です

[2016-11-21 18:20:12]のような[yyyy-mm-dd HH:mi:ss]の形の値を持つdatetime型のフィールド、recordがあるのですが、
ここから2016年10月1日〜2016年10月31日の期間の9:00〜12:00のレコードのみを抽出するにはどのような命令を書けば良いでしょうか?
日付のみなら

SELECT * FROM t_open WHERE record BETWEEN '2016-06-01' AND '2016-07-01';

という簡単な形で出せたのですが、時刻を指定する方法が分からず詰まっています。

445
NAME IS NULL[sage]   投稿日:2016/11/21 18:43:05  ID:???.net(298)
>113
and date_format(record, '%H:%i') between '09:00' and '12:00'

446
NAME IS NULL[sage]   投稿日:2016/11/21 19:36:05  ID:???.net(298)
>114
できました!ありがとうございます!
date_format関数について勉強しておきます

447
NAME IS NULL[sage]   投稿日:2016/11/22 17:17:14  ID:???.net(298)
>114
こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか?

448
NAME IS NULL[sage]   投稿日:2016/11/22 18:14:09  ID:???.net(298)
>116
> こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか?
本読まないでしょ。
初心者でも入門書を2,3冊こなせば書けると思うよ。

449
NAME IS NULL[sage]   投稿日:2016/11/22 18:28:47  ID:???.net(298)
短いやつをちょっとずつ書けば慣れるけど
MySQLの方言だからねえ、、、

450
NAME IS NULL[]   投稿日:2016/11/22 19:27:21  ID:sjSydgSv.net(2)
確かにここのレスを見ただけだとササっと書いてるように思うのも仕方がないだろう
だけど……裏では必死でググってんだぜオレたち 👀
Rock54: Caution(BBR-MD5:8368d31ad5c810f9ab23ea9fefa156d2)

451
NAME IS NULL[sage]   投稿日:2016/11/22 20:04:48  ID:???.net(298)
>117
入門書を二冊も読んだら上級者でしょ?
それもかなり上のクラスの

452
NAME IS NULL[sage]   投稿日:2016/11/24 15:48:27  ID:???.net(298)
sql初心者で2、3行程度の簡単なsqlしか実行した事がないんですが、世の中では何百行、何千行のsqlを実行する事もありますか?

453
NAME IS NULL[sage]   投稿日:2016/11/24 16:33:30  ID:???.net(298)
>120
上級者のハードル低いね

454
NAME IS NULL[sage]   投稿日:2016/11/24 16:40:02  ID:???.net(298)
100行程度なら描いたことがある
メンテナンス性を考えると
あまり長くしないようがいいように思う

455
NAME IS NULL[sage]   投稿日:2016/11/24 16:49:13  ID:???.net(298)
>122
相対的には上級者になるのかもねw
絶対的にはもちろん違うけど

456
NAME IS NULL[sage]   投稿日:2016/11/24 17:00:52  ID:???.net(298)
>124
自分がかなり上のクラスの上級者であると自己判定していて、自分のクラスになるには入門書2冊が必要だった、ということかも

457
NAME IS NULL[sage]   投稿日:2016/11/24 17:17:01  ID:???.net(298)
入門書を何冊読んでも入門書レベルの知識しかつかないという、ごくあたりまえの話

458
NAME IS NULL[sage]   投稿日:2016/11/24 20:22:40  ID:???.net(298)
>121
そんな複雑なやつを書く前にストアドとかビューを組み合わせるとかを検討する
そんなの書いたら検証がえらいことになる

459
NAME IS NULL[sage]   投稿日:2016/11/24 21:42:31  ID:???.net(298)
聞いた話でそれを見たことはないけど、1000行くらいのが出来上がったとかなんとか。
見たくもない(ある証券系のシステムでのお話)

460
NAME IS NULL[sage]   投稿日:2016/11/25 19:24:44  ID:???.net(298)
問い合わせ文じゃなくて、ややこしいストアド書くなら数百は余裕であり得るだろうけど

461
NAME IS NULL[sage]   投稿日:2016/11/25 21:18:31  ID:???.net(298)
行が増えざるを得ない状況がストアド開発には多すぎるからなぁ
つまり複雑度はなぜ行が多いのか次第

462
NAME IS NULL[]   投稿日:2016/11/25 21:23:23  ID:riZyA4Jk.net(2)
>121
カラム数が多くて、改行してたらあっという間。

463
NAME IS NULL[sage]   投稿日:2016/11/25 22:45:32  ID:???.net(298)
>131
> カラム数が多くて
それはそれでどうかと思うが...

464
NAME IS NULL[sage]   投稿日:2016/11/28 10:24:40  ID:???.net(298)
データ抽出用のビュー作るとカラム数数百とかなる

465
NAME IS NULL[sage]   投稿日:2016/11/28 11:06:13  ID:???.net(298)
二つのテーブルをjoinし、マスターをそれぞれ5個joinすると、
select t1.hoge, -- t1のデータで10行
...
t2.fuga, -- t2のデータで10行
join hoge_master -- マスター系テーブルのjoinで3行
on ...
and ...
これだけで、10 + 10 + 3 * 5 * 2 = 50行
それにwhere句とsub queryがつき、さらにunionで3ブロックほど結合すれば簡単に200行とかいく。

466
NAME IS NULL[]   投稿日:2016/11/28 19:58:42  ID:3f+IloFY.net(2)
カラム数はシステムが古かったり、考え方が古いひとが作ったものをだったりするとコントロールできない。

467
NAME IS NULL[sage]   投稿日:2016/11/28 20:54:44  ID:???.net(298)
何か列と行がグチャグチャ

468
NAME IS NULL[sage]   投稿日:2016/11/28 21:16:32  ID:???.net(298)
わざわざ1カラム1行でクエリ書いて行数多くてメンテナンス性落ちるなら本末転倒

469
NAME IS NULL[]   投稿日:2016/11/28 22:25:17  ID:PzYguHzt.net(2)
>137
はあ?

470
NAME IS NULL[sage]   投稿日:2016/11/29 10:41:34  ID:???.net(298)
>137
>134みたいなケースで言うと、行数が多くてメンテナンス性が落ちるということはない。
逆に、1行に複数カラムを羅列される方がメンテナンス性が落ちる。

471
NAME IS NULL[sage]   投稿日:2016/11/29 12:22:04  ID:???.net(298)
お前らの言うメンテナンス性ってテキストの編集しやすさの事だったんかw

472
NAME IS NULL[]   投稿日:2016/11/29 12:34:20  ID:W7hPtk8B.net(4)
>140
保守、仕様変更でSQLの構文が書き直されるようなのは馬鹿のやることだろ。

リスク高すぎ。

473
NAME IS NULL[sage]   投稿日:2016/11/29 12:41:50  ID:???.net(298)
可読性が低くてメンテナンス性は高いという状況が思いつかない

474
NAME IS NULL[sage]   投稿日:2016/11/29 13:04:43  ID:???.net(298)
>141
>保守、仕様変更で

手を入れないといけないときは
なるべくSQL(ストアド)の変更だけで留めようと努力するけど違うのか

475
NAME IS NULL[]   投稿日:2016/11/29 13:17:16  ID:W7hPtk8B.net(4)
>143
ストアドだって同じだろw

476
NAME IS NULL[sage]   投稿日:2016/11/29 13:44:04  ID:???.net(298)
>143
> なるべくSQL(ストアド)の変更だけで留めようと努力するけど違うのか
QiitaをkickされたSQLおじさん信者か何かか?

477
NAME IS NULL[sage]   投稿日:2016/11/29 21:15:59  ID:???.net(298)
>145
SQLおじさんってどなた?
ORMおじさんは知ってたけど

478
NAME IS NULL[sage]   投稿日:2016/11/30 10:30:54  ID:???.net(298)
>146
SQLおじさん、Qiitaに炎上記事投稿 周囲の反応と垢BANまでの流れ
http://togetter.com/li/1047474

479
NAME IS NULL[sage]   投稿日:2016/11/30 11:36:29  ID:???.net(298)
>147
ありがとう、同一人物だった

480
NAME IS NULL[sage]   投稿日:2016/12/14 16:14:32  ID:???.net(298)
TBS

481
NAME IS NULL[]   投稿日:2016/12/17 00:34:45  ID:L7Q4LZyG.net(4)
教えてください
アクセスを使ってます

INSERT INTO 日時(日付,時刻)
SELECT 日付,時刻 FROM 日付,時刻
WHERE (日付,時刻) NOT IN(SELECT 日付,時刻 FROM 日時)

データをクロス結合して重複分を排除しつつ日時テーブルに書込みをしたいのですが、
上のSQLではエラーとなってしまいます
自分でも調べてはいるのですがどうにも分からず頼らせてもらえればと思います
よろしくお願いします

482
NAME IS NULL[]   投稿日:2016/12/17 01:19:14  ID:L7Q4LZyG.net(4)
150です

自己解決しました。失礼しました。

483
NAME IS NULL[sage]   投稿日:2016/12/23 14:37:04  ID:???.net(298)
それクロス集計じゃなくてただの直積じゃないのか…?

484
NAME IS NULL[sage]   投稿日:2016/12/24 04:08:40  ID:???.net(298)
クロス結合とクロス集計って違うよ

485
NAME IS NULL[sage]   投稿日:2016/12/26 23:30:53  ID:???.net(298)
すみません、教えていただけますでしょうか。
ACCESSなのですが、

【テーブルA】
ID、商品名
10.90.10、鉛筆赤
10.90.20、鉛筆青
20.800.101、はさみ青
20.800.102、はさみ緑
305.001、のり青
305.005.100、のり黒


【テーブルB】
ID、値段
10.90、100円
20.800、200円
305、500円


というテーブルがあったとします。
テーブルBのIDを取得し、テーブルAから、テーブルBのIDの文字列にて始まるIDを取得し、テーブルAに値段列を付加するSQLを
作成しようとしているのですが、作成方法がいまいちわかりません。

例えば、
【抽出したい結果】
ID、商品名、テーブルBの値段
10.90.10、鉛筆赤、100円
10.90.20、鉛筆青、100円
20.800.101、はさみ青、200円
20.800.102、はさみ緑、200円
305.001、のり青、500円
305.005.100、のり黒、500円
のような感じです。

おそらく、テーブルAとテーブルBをleft joinする形になると思うのですが、
よい方法があれば教えていただけないでしょうか。

486
NAME IS NULL[sage]   投稿日:2016/12/27 02:49:52  ID:???.net(298)
>154
もしかして"10.90.10"で一つの項目に入っていて
そのうちの"10.90"と突き合わせたいとかいう話?

leftとmid組み合わせるとかinstr使うとかlike使うとか、いくつかやり方は思いつくけど
悪いことは言わないからまずDB設計見直せ

487
NAME IS NULL[sage]   投稿日:2016/12/27 07:38:43  ID:???.net(298)
>155 早速のレス、ありがとうございます。

>>もしかして

488
NAME IS NULL[sage]   投稿日:2016/12/27 07:39:20  ID:???.net(298)
すみません、なぜか切れてしまいました。

>>もしかして"10.90.10"で一つの項目に入っていてそのうちの"10.90"と突き合わせたいとかいう話?
はい、そういうことをやりたいと考えています。IDの例があまりよくなかったので、サンプルを変更します。

【テーブルA】
ID、商品名
abc-10、鉛筆赤
abc-20、鉛筆青
ef-101、はさみ青
ef-102、はさみ緑
abdzz-001、のり青
abdzz-100、のり黒

【テーブルB】
ID、値段
abc、100円
ef、200円
abdzz、500円

【抽出したい結果】
ID、商品名、テーブルBの値段
abc-10、鉛筆赤、100円
abc-20、鉛筆青、100円
ef-101、はさみ青、200円
ef-102、はさみ緑、200円
abdzz-001、のり青、500円
abdzz-100、のり黒、500円
のような感じです。

データベース設計を見直したいのですが、もうシステムが動いてしまっていて、
変更がちょっと難しい状態なのです、、、
社内用のシステムでお客様で使っているものではないのが救いなのですが。

489
NAME IS NULL[sage]   投稿日:2016/12/27 10:42:43  ID:???.net(298)
テーブルAに一列追加して
B用のキーを追加した方がいいぞ
キー列が変わることなんざ無いだろうし、insertするとこだけ弄ればいい
既にある列も30分もありゃ出きるやろ
そしたら普通にインナージョインで処理できる

490
NAME IS NULL[sage]   投稿日:2016/12/27 11:54:27  ID:???.net(298)
>158
それselect * してるやつがいたらこける可能性ある

491
NAME IS NULL[sage]   投稿日:2016/12/27 12:00:38  ID:???.net(298)
>社内用のシステムでお客様で使っているものではないのが救い

社内システムには直すお金がかけられないとかあるあるだけど
それ救いじゃなくて呪い(負債)だからな

492
NAME IS NULL[sage]   投稿日:2016/12/27 12:16:08  ID:???.net(298)
>159
Accessの場合大分こけないはず
フォームとかではいちいちフィールド名指定するし
Select * のフィールド数不一致でエラー吐くパターンがむしろ想像できん

ソースは小規模Accessをフィールド建て増ししまくって用途10倍以上に増やした俺

まぁ、
A inner join B On A.ID like B.ID & '*'
でも動くだろうけど、ミスによるバグがクッソ増えそうだし嫌だわ

493
NAME IS NULL[sage]   投稿日:2016/12/27 14:28:17  ID:???.net(298)
わざわざ abczz じゃなく abdzz にしてる意図が気になるな

494
NAME IS NULL[sage]   投稿日:2016/12/27 15:14:12  ID:???.net(298)
>162
likeしたときに
abc-とabcde-だと被るからじゃない?

495
NAME IS NULL[sage]   投稿日:2016/12/27 16:49:49  ID:???.net(298)
苦しすぎるw

496
NAME IS NULL[sage]   投稿日:2016/12/27 17:12:37  ID:???.net(298)
>157
> データベース設計を見直したいのですが、もうシステムが動いてしまっていて、
> 変更がちょっと難しい状態なのです、、、

正しいデータベース設計後、古いテーブルと同じ形式のViewを作ることができれば、
現行システムに影響を与えることなくデータベースの変更が可能。

497
NAME IS NULL[sage]   投稿日:2016/12/27 19:31:30  ID:???.net(298)
>165
view賛成
ま、弊社の場合はviewだらけで訳が分からなくなってるけどね(笑

498
NAME IS NULL[sage]   投稿日:2016/12/27 21:09:16  ID:???.net(298)
>165
ソレダ

499
NAME IS NULL[sage]   投稿日:2016/12/27 21:13:35  ID:???.net(298)
>157
クエリ追加したいってことは、少なくとも何らかの変更/追加があるわけで
そのうえでそのテーブルレイアウトで自分でクエリ書けないんだろ
だったらテーブルレイアウト直すべきだと思うけどね
ま、動いてて変えられんとかいう状況ならそのシステムに似たような事してるとこあるだろ

>165-166
普通のDBMSならビューで逃げる手はあるけど、ACCESSって結構テーブルとクエリで扱い方に差があるからなぁ

500
NAME IS NULL[sage]   投稿日:2016/12/28 06:24:05  ID:???.net(298)
>165
accessで困ってる初心者に追加可能な選択クエリとか書けるかっていう疑問はあるけど出来たらそれで良いかもね

501
NAME IS NULL[sage]   投稿日:2016/12/29 07:14:51  ID:???.net(298)
viewじゃ更新できないカラムのsqlあったらどうすんの

502
NAME IS NULL[sage]   投稿日:2017/01/04 10:49:09  ID:???.net(298)
トリガー作るしか無いかなあ

503
NAME IS NULL[sage]   投稿日:2017/01/29 14:56:15  ID:???.net(298)
oracleのmergeについて質問です。
oracleは11gを使っています。


とあるテーブルにmergeを使ってpkのレコードが無ければレコード追加、レコードがあれば何もしないというsqlがありました。

このようなsqlで行が無い場合はinsertと同じようにロックを取得すると思うのですが、
既に行がある場合ってロックは取得されるのでしょうか?

リファレンスを見ると細かいケースに言及せず、mergeの表ロックモードはsxとあるので、更新処理の有無に関わらずforupdateと同様にロックされるのかなぁと思っているのですが、、

504
NAME IS NULL[sage]   投稿日:2017/03/14 22:41:55  ID:???.net(298)
【質問テンプレ】
・DBMS名とバージョン
Access?(Excel2013のデータ接続機能のところに書いて使いたいです)

・テーブルデータ
ID |Price|Name
-----------------
1001 100 ガム
1002 200 あめ
1002 300 チョコ
1003 400 クッキー
1003 500 ポテチ
1003 600 ポテチ

・欲しい結果
ID |Price|Name
-----------------
1001 100 ガム
1002 500 あめ,チョコ
1003 1500 クッキー,ポテチ,ポテチ

・説明
ID毎にPriceを合計してNameの値を結合したいです。
よろしくお願いします。

505
NAME IS NULL[sage]   投稿日:2017/03/15 00:45:52  ID:???.net(298)
主キーも何も無いのこれw

506
NAME IS NULL[sage]   投稿日:2017/03/15 14:25:20  ID:???.net(298)
Nameの結合の順番は決まってんの?

507
NAME IS NULL[sage]   投稿日:2017/03/15 18:49:35  ID:???.net(298)
group_concat()があれば簡単なのに

Access用にはDJoinという関数を作って公開してる人がいたみたいだけど
ページが消えてる

508
NAME IS NULL[sage]   投稿日:2017/03/15 20:10:02  ID:???.net(298)
AccessならVBAでID受け取ってNameをカンマ連結した文字列返す関数作ればできんじゃね

509
173[sage]   投稿日:2017/03/17 23:41:34  ID:???.net(298)
>174-177
返信おそくなってすみません
質問に不足してた部分があったので
また質問しなおしたいと思います

どうもありがとうございました

510
NAME IS NULL[sage]   投稿日:2017/04/26 20:40:34  ID:???.net(298)
・Postgresql 8.4

・テーブルデータ
|year|month
-----------------
2017 4
2017 6
2018 3
2018 4

・欲しい結果
|year|month
-----------------
2017 4
2017 6
2018 3

・説明
integerの列year、monthに年、月が書かれており、2017年4月〜2018年3月までの会計年度の行を取りたいのですが、そのようなことは可能でしょうか お願いします

511
NAME IS NULL[sage]   投稿日:2017/04/26 21:37:32  ID:???.net(298)
select * from table where year*100+month between 201704 and 201803;

じゃだめか?

512
NAME IS NULL[]   投稿日:2017/04/26 21:56:03  ID:yyy4jyWJ.net(2)
俺じゃダメか?

513
NAME IS NULL[sage]   投稿日:2017/04/26 22:08:23  ID:???.net(298)
(year=2017 and month>=4) or (year=2018 and month<=3)でいいだろ

514
NAME IS NULL[sage]   投稿日:2017/04/26 22:54:12  ID:???.net(298)
IIf(Month<4,Year-1,Year) AS 会計年度
見たいなカラム持ったクエリ定義しとけよ

515
183[sage]   投稿日:2017/04/26 22:57:19  ID:???.net(298)
あ、なぜかACCESSだと思ってたw
標準的なSQLならCASEでビューか

まあ、わかるだろ

516
NAME IS NULL[sage]   投稿日:2017/04/27 04:56:49  ID:???.net(298)
>179
性能は知らん
where make_date(year, month, 1) between '2017-04-01' and '2018-03-31'

517
NAME IS NULL[sage]   投稿日:2017/04/27 07:07:55  ID:???.net(298)
>182
自分もこれだな

518
NAME IS NULL[sage]   投稿日:2017/04/27 09:29:25  ID:???.net(298)
日付を分割してintに入れる糞実装、未だに存在するのかよ

519
NAME IS NULL[sage]   投稿日:2017/04/27 10:38:00  ID:???.net(298)
日付じゃなくて必要なのが月までだからだろ

520
NAME IS NULL[sage]   投稿日:2017/04/27 10:55:10  ID:???.net(298)
それでも /01 にしてdate型に突っ込むわ

521
NAME IS NULL[sage]   投稿日:2017/04/27 12:24:41  ID:???.net(298)
どうでもいいけど言うならせめて糞設計だよね
実装てw

522
sage[]   投稿日:2017/04/27 15:25:55  ID:JuRKhktP.net(2)
設計:年・月を保存する
実装:年・月を別カラムにする

523
NAME IS NULL[sage]   投稿日:2017/04/27 15:38:14  ID:???.net(298)
質問者への回答と、設計の改善提案は別だろうに

524
NAME IS NULL[sage]   投稿日:2017/04/27 16:00:01
number(8)に日付いれるのが好きなフレンズもいるな

525
NAME IS NULL[sage]   投稿日:2017/04/27 16:08:50
>193
難点は経過日数計算が大変な

526
NAME IS NULL[sage]   投稿日:2017/04/27 17:08:47
俺は >180 支持だなぁ
速度的にも見た目的にも

527
NAME IS NULL[sage]   投稿日:2017/04/27 18:52:05
>180
会計年度中も指定できるので非常に参考になりました

他の方法も含めご教示ありがとうございます

528
NAME IS NULL[sage]   投稿日:2017/04/27 18:59:16
年月を保持する要件で、データに意味を持たない日の情報が含まれるって、良いのでしょうか

バグを産む可能性を秘めてるような

529
NAME IS NULL[sage]   投稿日:2017/04/27 19:31:38
>197
あり得ない月とかを突っ込める方が恐いわ

530
NAME IS NULL[]   投稿日:2017/04/27 19:39:19
>198
そんなもんなんぼでもあるわwお前ビビりすぎw

531
NAME IS NULL[sage]   投稿日:2017/04/27 19:54:14
バカが現れた

532
NAME IS NULL[sage]   投稿日:2017/04/27 20:18:45
>199のレスの意味がわからなすぎる

533
NAME IS NULL[sage]   投稿日:2017/04/27 20:19:31
バグというより、データベースに事実にない情報を含めるとか違和感が

534
NAME IS NULL[sage]   投稿日:2017/04/27 20:44:47
numberでもバグを産む可能性を秘めてるし
どっちのリスクをとるかだけじゃね

535
NAME IS NULL[sage]   投稿日:2017/04/27 21:33:38
年月のみを管理したいっていう場合に
・日付としての正当性は保証されるけど不要な日の情報を持つ
・日付としての正当性は保証されないけど不要な情報を持たない
のどちらがいいか?
って話でしょ
個人的にはデータの正当性の方を重視するかな

536
NAME IS NULL[sage]   投稿日:2017/04/28 07:06:33
そして2017/4/1と2017/4/2など
同一年月で複数レコードできてしまうのでした

537
NAME IS NULL[sage]   投稿日:2017/04/28 07:18:39
年月情報をユニーク制約を保持する仕様で日付計算のためにdate使ってたら、皆さんはどう思いますか

538
NAME IS NULL[sage]   投稿日:2017/04/28 10:47:01
もうUNIQUE制約のある年月列と日付計算用の列を分けろよ

539
NAME IS NULL[sage]   投稿日:2017/04/28 11:33:54
レコードの入力時に日付が何入っていようと、1にしてしまえば良いだけだろう

540
NAME IS NULL[sage]   投稿日:2017/04/28 12:16:53
そんなもん制約がなければ全く信用できん
本当に頭が悪いなお前ら

541
NAME IS NULL[sage]   投稿日:2017/04/28 13:33:21
>205
2017/00 とか 2017/13 とか入ってるのとどっちがいい?

542
NAME IS NULL[sage]   投稿日:2017/04/28 15:57:28
DB側の制約がいかに利用されていないか分かるな

543
NAME IS NULL[sage]   投稿日:2017/04/28 18:48:18
1日の0時になっているか確認するcheck制約つければいい

544
NAME IS NULL[sage]   投稿日:2017/04/28 20:51:04
そもそもカラムが年と月別なんだからcheck制約でもMonth>=1 and Month<=12でいいから簡単だろ
プログラムも同様
まさか日付を変換して1日かとかやるとか?
いらない情報付与からして、そんなのうちでは許されないわw

545
NAME IS NULL[sage]   投稿日:2017/04/30 03:36:41
>182
後の人間を苦しめるコードをまき散らすのは止めよう

546
NAME IS NULL[]   投稿日:2017/04/30 19:54:54
>214
馬鹿の苦しみなんか気にしてられんわw

547
NAME IS NULL[sage]   投稿日:2017/04/30 20:56:47
3年分取ってきてと言われて初めて問題に気付くパターンや

548
NAME IS NULL[sage]   投稿日:2017/04/30 23:19:56
where fiscal_year(year, month) = 2017
みたいな感じで関数使うかビュー使うほうがロジックが一箇所に集まっていい気がする
パフォーマンス気にするレベルならcalender yearとは別にfiscal yearをデータに持たせるかな

549
NAME IS NULL[sage]   投稿日:2017/04/30 23:33:29
あと fiscal_year(date) みたいにオーバーロードしとけば
インターフェースが統一されて使いやすい

550
NAME IS NULL[sage]   投稿日:2017/05/01 09:41:38
SQLにオーバーロードあるんですか?どんなRDB?

551
NAME IS NULL[sage]   投稿日:2017/05/01 10:54:41
え、、、普通にあるでしょ
むしろできないDBってどれよ

552
NAME IS NULL[sage]   投稿日:2017/05/01 13:48:49
>220
できないやつ多数でしょ

553
NAME IS NULL[sage]   投稿日:2017/05/01 14:14:22
そうなんか、OracleとPostgreSQLで出来てるから普通なのかと・・・

554
NAME IS NULL[sage]   投稿日:2017/05/01 14:29:03
まーた、俺様の「普通」が炸裂しとる

555
NAME IS NULL[sage]   投稿日:2017/05/01 14:33:46
Oracleは特例
いいね?

556
NAME IS NULL[sage]   投稿日:2017/05/01 15:03:51
てか、そもそもOracleでも単純なオーバーロードってあったっけ?

557
NAME IS NULL[sage]   投稿日:2017/05/01 15:05:03
packageを使ったオーバーロードはあるが・・・
http://www.shift-the-oracle.com/plsql/overloading-subprogram-name.html

558
NAME IS NULL[sage]   投稿日:2017/05/01 15:07:37
このケースはComputed Columnが使えればそれがいいと思うけど
Postgresでは使えないから関数オーバーロードしとくって話
Computed Columnなら使えるDB多いだろ

SQL標準ならView使えって話かもしれんがViewは管理上のオーバーヘッドが高くなる傾向があるから
使わなくてすむケースならなるべく使わないようにしてる

559
NAME IS NULL[sage]   投稿日:2017/05/01 15:15:27
普通に>182でいいだろ

560
NAME IS NULL[sage]   投稿日:2017/05/01 15:36:01
PostgreSQL有害論

561
NAME IS NULL[sage]   投稿日:2017/05/01 16:10:53
>228
会計年度を必要とするたびに繰り返し同じことをするのでよければね
年度別に集計したい場合とかしんどいし俺はごめんだわ

562
NAME IS NULL[sage]   投稿日:2017/05/01 16:49:59
普通に関数でいいと思うんだが、あえて(関数?)オーバーロードって言ってるのはなんで?

563
NAME IS NULL[sage]   投稿日:2017/05/01 16:57:59
>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

564
NAME IS NULL[sage]   投稿日:2017/05/01 17:06:24
つか、いたるところで会計年度を意識するようなシステムなら、会計年度カラムを作っとけばいいよな

565
NAME IS NULL[sage]   投稿日:2017/05/01 18:03:32
>232
where句も入れて何回繰り返すのさ
面倒くさいとは思わないの?
単発の作業ならわからんでもないが会計年度みたいなのは1回じゃすまないだろ

>231
日付型でデータを持ったテーブルがあったり
日付型に徐々に移行したい場合に同じ名前で扱えるとうれしいから
会計年度って概念をDBに反映させる一つの手段


566
NAME IS NULL[sage]   投稿日:2017/05/01 18:18:52
>234
> 面倒くさいとは思わないの?
いや、まったく
>232レベルのクエリなら10秒もかからずタイプできるだろ

567
NAME IS NULL[sage]   投稿日:2017/05/01 18:28:00
>234
> where句も入れて何回繰り返すのさ
ストアドでも似たようなもんだろ。
select fiscal_year(year, month), sum(hoge) from fuga group by fiscal_year(year, month)
しかもストアド使うと、year, monthにインデックスあっても使われないし。

568
NAME IS NULL[sage]   投稿日:2017/05/01 18:37:19
ストアド最強!!!|バカの壁| SQL92以降

569
NAME IS NULL[sage]   投稿日:2017/05/01 18:46:32
kantomi@qiita_banned < ストアド!ストアド!

570
NAME IS NULL[sage]   投稿日:2017/05/01 18:53:59
>235
面倒くさいと思わないならいいんじゃね

>236
asで名前つけとけばgroup byでは繰り返す必要ないよ
たとえ繰り返しが必要だったとしても概念をその名前で直接扱える状態と
毎回展開しなきゃいけない状態では全く意味が違うんだけどね

インデックスは必要ならはればいい

571
NAME IS NULL[sage]   投稿日:2017/05/01 19:03:28
>233
算出できる情報を別途カラム作って持たせるのは最終手段

572
NAME IS NULL[sage]   投稿日:2017/05/01 19:04:19
>180 重み付けの定石
>182 単年度でしか動かないクソ
>185 意図が分かりやすい
>217 ビジネスロジックをDBMSに持たせる派とアプリに持たせる派で戦争勃発

573
NAME IS NULL[sage]   投稿日:2017/05/01 19:33:28
>241
一番馬鹿ww

574
NAME IS NULL[sage]   投稿日:2017/05/01 21:25:30
>234
fiscal_year(year, month)って関数自体はまだなにもオーバーロードしてないだろうが。

575
NAME IS NULL[]   投稿日:2017/05/01 21:52:46
>241のどこが馬鹿なのか論理的に説明できないやついるの?

576
NAME IS NULL[sage]   投稿日:2017/05/01 23:12:56
>240
分解せずに日付型で持っていればよかったって事だな
以降>188へ戻る

577
NAME IS NULL[sage]   投稿日:2017/05/02 03:16:15
管理上のオーバーヘッドってのがユーザ側の話なのかシステム側の話なのかしらんが
関数オーバーロードができたとして、それがビューより管理が重いとか信じられん

会計年度が必要ならそう言うビュー作れ、で終わりじゃないのか

578
NAME IS NULL[sage]   投稿日:2017/05/02 08:24:38
一方ロシアは会計年度カラムを追加した

579
NAME IS NULL[sage]   投稿日:2017/05/02 10:00:08
インデックス張るなら、ロシア方式が一番いいよな
トリガーで仕掛けておけば気にしなくて済むし

580
NAME IS NULL[sage]   投稿日:2017/05/02 10:17:39
>239
> インデックスは必要ならはればいい
本末転倒だな
普通にクエリ書けばインデックス使えるのに、ストアドにしようと思うとさらに何かしないといけなくなる
つか、ストアドの結果にインデックス貼れないDBもあるんじゃね?

581
NAME IS NULL[sage]   投稿日:2017/05/02 10:22:47
>239
> asで名前つけとけばgroup byでは繰り返す必要ないよ
その手段が使えるDBでは、>232も同じことが言える

> 毎回展開しなきゃいけない状態では全く意味が違うんだけどね
例えば四半期ごとの集計がほしいとか、移動平均がほしいとかいうことになったら、
そのたびにストアド作るのか?
増殖しまくりだな

582
NAME IS NULL[sage]   投稿日:2017/05/02 10:26:43
ん? >232 だとインデックス使われないだろ
>217-218 >185 のような関数だともっと使われない
>182 のように or あると、うまく使ってくれるか怪しい

583
NAME IS NULL[sage]   投稿日:2017/05/02 10:38:44
>251
> ん? >232 だとインデックス使われないだろ
where書いてないからね
>232は、集計がしんどいという奴へのレス

>182 のように or あると、うまく使ってくれるか怪しい
大抵のRDBMSだったらうまく使ってくれるんじゃね?

584
NAME IS NULL[sage]   投稿日:2017/05/02 10:44:41
それより決算月が変わる可能性について考えたほうがいいと思う

585
NAME IS NULL[sage]   投稿日:2017/05/02 10:45:38
>251
> >217-218 >185 のような関数だともっと使われない
こういうバカ避けのためにわざわざ「性能は知らん」って書いてあるのにバカはそれすら理解できないんだな w
インデックス使いたいならdate型にしとけよ

586
NAME IS NULL[sage]   投稿日:2017/05/02 10:49:15
>253
会計年度カラム追加で解決。

587
NAME IS NULL[sage]   投稿日:2017/05/02 10:51:13
>254
year, monthにインデックス張ればいいだろ
アホか

588
NAME IS NULL[sage]   投稿日:2017/05/02 11:01:20
ビューのコストが高いというのがparserの話だとしたら、単純なビューなら最近では全く問題にならない
まぁ、大抵の場合、クエリ1回につき+1ms未満だろう。
(さらには、直近のparse結果をcacheしている場合もある)

589
NAME IS NULL[sage]   投稿日:2017/05/02 11:03:21
>256
> year, monthにインデックス張ればいいだろ

インデックス張っても関数の引数にしちゃったら使われない

590
NAME IS NULL[sage]   投稿日:2017/05/02 15:49:34
>256
バカってこれだから...
複数の列に張るより単一の方が有利だろう
そんなことも理解できないのかよ w

591
NAME IS NULL[sage]   投稿日:2017/05/02 16:00:26
そんな理由だったらオレもアンタをバカ呼ばわりしていいかな

592
NAME IS NULL[sage]   投稿日:2017/05/02 16:16:34
>260
理由が書けるならね

593
NAME IS NULL[sage]   投稿日:2017/05/02 17:11:25
不利っつっても、比較が1回か2回かって違いくらいしかないだろ。

594
NAME IS NULL[sage]   投稿日:2017/05/02 17:17:06
ここを2つに分けるかどうかの是非はともかく
キーが2つになるから絡むつにしようとかおかしいだろw

まあこのケース、月なんて12通りしか無いんだし複合キーで

595
NAME IS NULL[sage]   投稿日:2017/05/02 18:48:29
>複数の列に張る

こういう言い方しているところを見ると、複合インデックスの仕組みをわかってないんだろう。

596
NAME IS NULL[sage]   投稿日:2017/05/02 18:57:10
yearのインデックスとmonthのインデックスを別々に張りそう

597
NAME IS NULL[sage]   投稿日:2017/05/02 19:11:26
>250
>その手段が使えるDBでは、>232も同じことが言える
そんなんわざわざ言わんでもわかっとるがな〜ww

>増殖しまくりだな
増殖して何か問題あるの?

598
NAME IS NULL[sage]   投稿日:2017/05/02 21:48:44
>246
システム側の話
組織構造なんかも大きく影響するから環境による
導出列はビューを使うっていう規約があってそれに従ってるようなところならオーバーヘッドも少ないだろうね
ただ関数よりビューのほうが管理の厳格度というか管理レベルが高いのは一般的じゃないのかな?
管理レベルが高ければその分のオーバーヘッドはかかる

それに同じような年・月で持ってるテーブルが10個に増えたら10個ビューを追加することになる
そういうのが嫌だからComputed Column的な機能があるDBが多いと思ってる

599
NAME IS NULL[sage]   投稿日:2017/05/02 22:51:26
>264
お前こそわかってないだろ w
>180, >182 みたいに複合インデックスの各々の列を別々に大小比較で使うとインデックス使えないぞ

600
NAME IS NULL[sage]   投稿日:2017/05/02 23:17:09
使われないインデックスと、使えないお前らの脳ミソ達。

601
NAME IS NULL[sage]   投稿日:2017/05/03 00:11:51
>182は(orは別として)yearとmonthの複合インデックスの教科書的な例だと思うが。
つか、>180>182を同列に並べている時点でお里が知れる。

602
NAME IS NULL[sage]   投稿日:2017/05/03 04:36:48
>267
管理レベルってのがなんだかわからんが
ビューの方がより厳密に適用される分、問い合わせ時のシステム的なオーバーヘッドは小さいだろ
実行計画もより最適化できる
つか、ユーザー側/システム側って切り分けが、どっちも人員の切り分けだと思ってる?

>それに同じような年・月で持ってるテーブルが10個に増えたら
同じものが分散して存在してたら、その時点でテーブル設計が間違ってるわ

603
NAME IS NULL[sage]   投稿日:2017/05/03 07:59:56
馬鹿はなぜ無駄に未来の心配ばかりするのか

604
NAME IS NULL[sage]   投稿日:2017/05/03 09:25:30
>270
実行計画見てみ
複合インデックスの仕組み知ってたらそんなアホな発想はできないよ

605
NAME IS NULL[sage]   投稿日:2017/05/03 10:39:56
おまえこそ見てみろと言いたいが。

念のためだが、ヘボいオプティマイザがorのせいでスキャン範囲の限定に失敗するのは
「複合インデックスの各々の列を別々に大小比較で使うとインデックス使えない」てのとは
関係ないからな。

606
NAME IS NULL[sage]   投稿日:2017/05/03 11:04:58
>274
> orのせいで
バカを晒すのはほどほどにしろよ

607
NAME IS NULL[sage]   投稿日:2017/05/03 12:06:11
>274
複合インデックスから任意の1つの列を選んで使う事はできないので、 データベースはインデックスを使いません。
インデックスの構造をより深く見ていくと、この理由がはっきりします。
http://use-the-index-luke.com/ja/sql/where-clause/the-equals-operator/conca...

608
NAME IS NULL[sage]   投稿日:2017/05/03 12:40:47
今どきは>182でも(year,month)のインデックスがあれば
(そしてそれを使ったほうが速いとDBMSが判断すれば)
使うDBMSのほうが多いと思う

パフォーマンスに関しては昔の定石を今はあまり気にしなくても
良くなっていることが多いので必ず実機で試してから語ったほうがいい

609
NAME IS NULL[sage]   投稿日:2017/05/03 13:06:33
>276
それはyearを使わずにmonthだけだった場合だな。こんな初歩的な勘違いしてたのか。

610
NAME IS NULL[sage]   投稿日:2017/05/03 13:34:58
>278
バカはこれだから...
わざわざ
> インデックスの構造をより深く見ていくと、この理由がはっきりします。
って言うところまで引用してるだからその下読めよ
理解できるかどうかは知らんけど w

611
NAME IS NULL[sage]   投稿日:2017/05/03 14:38:41
アホなレス量産してるやつは約1名だけっぽいな

612
NAME IS NULL[sage]   投稿日:2017/05/03 17:44:08
year, monthにインデックスの件だけど、PostgreSQLなら使われるけどなぁ
ほかのDBだと使われなかったりするのか?

613
NAME IS NULL[sage]   投稿日:2017/05/03 17:47:31
create table hoge (year integer, month integer, amount integer);
create index hoge_idx on hoge(year, month);

select year, month, sum(amount)
from hoge where (year = 2017 and month > 3) or (year = 2018 and month < 4)
group by year, month;

実行計画:
https://explain.depesz.com/s/rwx

614
NAME IS NULL[sage]   投稿日:2017/05/03 18:26:59
使われないDBがあると思ってるのは約1名だけだぞ

615
NAME IS NULL[sage]   投稿日:2017/05/03 18:31:37
実行計画見るような人なら当然わかっているだろうけど、統計情報がとられていなかったり
選択されるレコードの割合ががテーブル全体に対して大きい場合はインデックススキャンが
選択されないから注意な。

616
NAME IS NULL[sage]   投稿日:2017/05/03 18:42:36
インデックス使われないマン =
オーバーロードマン =
Computed Columnマン

617
NAME IS NULL[sage]   投稿日:2017/05/03 18:49:07
=管理レベルマン

618
NAME IS NULL[sage]   投稿日:2017/05/03 19:48:53
>281-282
ああPostgreSQLはデータが少ない時はBit Map展開するのか
http://use-the-index-luke.com/ja/sql/explain-plan/postgresql/operations
それを一般的な話にされても困るな

619
NAME IS NULL[sage]   投稿日:2017/05/03 19:56:46
まさか今どき、インデックスがあれば必ず使うとか思ってるんだろうか
ルールベースとコストベースの違いも分かってない?


620
NAME IS NULL[sage]   投稿日:2017/05/03 20:03:06
「使われない場合もある」に方向転換w

621
NAME IS NULL[sage]   投稿日:2017/05/03 20:30:25
>285
おいこら
インデックス使われないマンと一緒するなよw

622
NAME IS NULL[sage]   投稿日:2017/05/03 20:42:23
>288
>270 辺りに言ってやれよ

623
NAME IS NULL[sage]   投稿日:2017/05/03 20:49:46
>291
インデックス使われないマンちぃーす

624
NAME IS NULL[]   投稿日:2017/05/03 21:10:30
お前らが馬鹿なのは使う必要のないインデックスについて延々と話してることだけどな

625
NAME IS NULL[sage]   投稿日:2017/05/03 22:00:09
>288
「使う場合もある」に方向転換w

626
NAME IS NULL[sage]   投稿日:2017/05/03 22:14:57
>282
それ >287 が書いてる通り Bit Map Index Scanだよ
URL読めばわかると思うけど

> ビットマップスキャンは、一度に全てのタプルへのポインタをインデックスから取り出し、
----
インメモリな「ビットマップ」データ構造を使ってソートし
----
> 物理的なタプル位置の順にテーブルのタプルにアクセスします。

つまりyearとmonthに対して個別にインデックス張っときゃソートなんて要らない
要するに >264-265 をディスってるだけなんだが w

627
NAME IS NULL[sage]   投稿日:2017/05/03 22:20:18
結論

>year, monthにインデックス張ればいいだろ
>アホか

628
NAME IS NULL[sage]   投稿日:2017/05/03 22:20:54
まあ、日付型とか言ってる奴は決算月の考慮どうするんだろうと思うわ

629
NAME IS NULL[sage]   投稿日:2017/05/03 22:51:38
またドヤ顔で恥の上塗り

630
NAME IS NULL[sage]   投稿日:2017/05/03 22:56:01
具体的に説明できない奴がわらわら沸いてるw

631
NAME IS NULL[sage]   投稿日:2017/05/03 23:01:34
>297
決算月と日付型との間に問題があるなら後学のために披露しては?
それか質問なら>1読んでからどうぞ

632
NAME IS NULL[sage]   投稿日:2017/05/04 09:47:10
結論だけ言ってて根拠が無ければそれはただの推論

633
NAME IS NULL[sage]   投稿日:2017/05/04 10:19:56
妄想の可能性も...

634
NAME IS NULL[sage]   投稿日:2017/05/04 11:07:26
>287
データ量が多いというのは1億レコードとかそんな単位?
>282は100万件だったけど、1000万件でも同じだよ。

>288
そういう話じゃない。
ストアド作って、where fiscal_year(year, month) = 2017とやると通常はインデックスは使われないが、
普通にクエリ書けば、適切な場面でインデックスが使われるという話だ。

> ルールベースとコストベースの違いも分かってない?
PostgreSQLの話になるが、PostgreSQLにはルールベースのオプティマイザはないよ。

>295
コメントの意図がわからないんだが。

> つまりyearとmonthに対して個別にインデックス張っときゃソートなんて要らない
それ、monthに対するインデックスの意味ないよね。

635
NAME IS NULL[sage]   投稿日:2017/05/04 11:16:06
>303
> データ量が多いというのは1億レコードとかそんな単位?
> >282は100万件だったけど、1000万件でも同じだよ。
マジで仕組みを理解してないんだな w
そっちのデータ量じゃなくてインデックスの方
要するに年と月の数の話

> それ、monthに対するインデックスの意味ないよね。
ないと本気で思ってるなら真面目にもう少し勉強した方がいいと思う

636
NAME IS NULL[sage]   投稿日:2017/05/04 11:33:25
>304
> マジで仕組みを理解してないんだな w
わかるような単語使いましょう。ちゃんと用意されてるんだから。

> 要するに年と月の数の話
カーディナリね。

> ないと本気で思ってるなら真面目にもう少し勉強した方がいいと思う
どういう意味があるんだ?

637
NAME IS NULL[sage]   投稿日:2017/05/04 13:11:20
>305
> カーディナリね。
それを言うならカーディナリティな

> わかるような単語使いましょう。
でかいブーメラン乙 w
きちんと理解せずに背伸びするからそう言う間違いをしちゃうんだよ

> どういう意味があるんだ?
普通にインデックスとして使われるだけだが?
なぜmonthは使われないと思ったんだ?

638
NAME IS NULL[sage]   投稿日:2017/05/04 13:46:35
>306
> それを言うならカーディナリティな
知ってるなら最初から使おうな。

> なぜmonthは使われないと思ったんだ?
使われないから意味ないんだよ。
まぁ、monthを軸にした検索をすれば使われるだろうが、今回の流れとは関係ないね。

俺がコメントを続けた意味が理解できてないようだから、再説明しとこう。

>295
>282
> それ >287 が書いてる通り Bit Map Index Scanだよ
> URL読めばわかると思うけど
これが意味不明なんだが。
bitmap index scanだから何?

639
NAME IS NULL[sage]   投稿日:2017/05/04 14:11:42
脇道の細かい議論しても仕方がないから、論点を絞ろう。

君が主張したいのはこれか?
>259
> 複数の列に張るより単一の方が有利だろう

それに対する俺の主張は、「year, monthに複合インデックス貼る方が有利」。
理由は、
・インデックスが全くない場合は、seq scanになり、論外
・yearのみにインデックスを張った場合、「2017年度」のデータを参照するとき、2年分のデータを読み1年分のデータを捨てる必要がある
・monthのみのインデックスには意味がない
・year, monthにインデックスを張れば、>179のような会計年度別集計などの場合にインデックスが使われる(もちろん、使った方がコスト的に有利な場合)

・(おまけ)year, monthにインデックス張っても、where fiscal_year(year, month) = 2017などとするとインデックスが使われなくなる
・(さらにおまけ)PostgreSQLには、関数インデックスという機能があり「fiscal_year(year, month)」に対してインデックスを貼ることができる
・(蛇足)そこまでするなら、普通にクエリ書け

640
NAME IS NULL[sage]   投稿日:2017/05/04 16:35:58
>307
> 知ってるなら最初から使おうな。
ちゃんとした知識持ってる奴なら >287 のリンク先読めばわかるし
それでわからんような奴にカーディナリティとか言ってもしょうがないだろ
さすがに中途半端にカーディナリとか言う知ったかさんの存在までは想定しとらん

> 使われないから意味ないんだよ。
なぜ使われないんだ?
に対して「使われないから」って日本語大丈夫か?

> まぁ、monthを軸にした検索をすれば使われるだろうが、今回の流れとは関係ないね。
>> (year=2017 and month>=4) or (year=2018 and month<=3)
で関係ないと考える奴にどう説明しろと?

> bitmap index scanだから何?
>287 のリンク先読めよ
それでもわからないと言うから >295 でも説明してる
さらにそれでもわからんと言うならわからない箇所を引用してくれ

すごく中途半端な知識で語ってるようだからどこがわからんのか予測できないし

641
NAME IS NULL[sage]   投稿日:2017/05/04 16:47:15
>308
> ・year, monthにインデックスを張れば、>179のような会計年度別集計などの場合にインデックスが使われる(もちろん、使った方がコスト的に有利な場合)
複合インデックスの話だよね?
それならBit Map Index Scanになるから実行時にインデックスデータについてソート処理が走るんだよ?
そこ理解してる?
ちなみに俺は
> インデックス使いたいならdate型にしとけよ
って言ってるから普通にIndex Scanするだけなのでソート処理なんて要らんから

642
NAME IS NULL[sage]   投稿日:2017/05/04 17:13:18
なんでBit Map Index Scanになるのが当然のような言い方なんだか。

643
NAME IS NULL[sage]   投稿日:2017/05/04 17:21:33
>311
他の方法があると言うなら示してみて

644
NAME IS NULL[sage]   投稿日:2017/05/04 17:22:38
そろそろ結論出して終わりにしてください
結論がまとまらないなら、両論併記で良いと思います

645
NAME IS NULL[sage]   投稿日:2017/05/04 17:28:28
お互い相手のことを馬鹿だと思っているなら
馬鹿相手にムキになっている自分を恥じたほうがいいと思うが

646
NAME IS NULL[sage]   投稿日:2017/05/04 17:48:27
いや既に結論出てるけど理解できない人が食い下がってるだけ

647
NAME IS NULL[sage]   投稿日:2017/05/04 18:23:25
>180で答え出てるから後は設計スレでしてくれ
閑古鳥鳴いてるからウェルカムだぞ

648
NAME IS NULL[sage]   投稿日:2017/05/05 11:22:05
せめて年月から会計年度を返す関数化してくれ

649
NAME IS NULL[sage]   投稿日:2017/05/09 13:37:10
>310
> それならBit Map Index Scanになるから実行時にインデックスデータについてソート処理が走るんだよ?
> そこ理解してる?
その「ソート処理」は、計画ノード種別の「ソート」じゃなくて、Bitmap Index Scanのアルゴリズム上、実装コードで
ソートが必要だということじゃないの?
実際、>282の実行計画には、「ソート」はないわけで。
で、アルゴリズム上、ソートが必要だとして、何か問題でも?

> > インデックス使いたいならdate型にしとけよ
> って言ってるから普通にIndex Scanするだけなのでソート処理なんて要らんから
Index Scanの場合も、aggregateするときに、実装コードでソートが必要な気がするが。
(ソートせずに何回もループしてもいいが、多分ソートするんじゃないかと思う)

650
NAME IS NULL[sage]   投稿日:2017/05/09 13:48:09
ケースバイケース

651
NAME IS NULL[sage]   投稿日:2017/05/09 13:48:27
>309
> なぜ使われないんだ?
なぜもクソも使わないんだよ。

> >> (year=2017 and month>=4) or (year=2018 and month<=3)
> で関係ないと考える奴にどう説明しろと?
関係ないね。
関係あるというなら、テストデータ作って実行計画出してみな。

> すごく中途半端な知識で語ってるようだからどこがわからんのか予測できないし
俺がお前に言いたい言葉だな。

652
NAME IS NULL[sage]   投稿日:2017/05/09 14:10:30
親切なので、year, monthに個別にindexを張った場合の実行計画を取ってみた。
https://explain.depesz.com/s/UapJ

書き忘れたが、
> インデックス使いたいならdate型にしとけよ
大本の話は会計年度で集計するときの話。
date型なら会計年度を取得して集計する必要があって、そこでストアドやビルトイン関数使うと
日付カラムにindexあっても使われないって話な。

さらに言えば、会計年度カラム追加しろとかいう話なら、今のままで複合インデックスつけて普通に
検索しろってこった。
(何度ループするんだよ)

653
NAME IS NULL[sage]   投稿日:2017/05/09 14:24:55
さらにおまけ。

# \d fuga
テーブル "public.fuga"
列 | 型 | 修飾語
--------+---------+--------
dt | date |
amount | integer |
インデックス:
"fuga_idx" btree (dt)

explain analyze verbose select sum(amount) from fuga where dt between '2013-04-01' and '2014-03-31';

実行計画:
https://explain.depesz.com/s/533s
Bitmap Index Scanになってますが。

654
NAME IS NULL[sage]   投稿日:2017/05/09 14:55:26
これにもレスしとこう。

前提として、seq scanではパフォーマンス的に問題があるレベルのレコード数の場合。
>316
> >180で答え出てるから後は設計スレでしてくれ

whereで式を使うと、そのカラムにインデックスがあっても使われない。
> Seq Scan on public.hoge (cost=0.00..30406.00 rows=5000 width=12) (actual time=0.028..253.216 rows=100600 loops=1)
> Output: year, month, amount
> Filter: ((((hoge.year * 100) + hoge.month) >= 201604) AND (((hoge.year * 100) + hoge.month) <= 201703))
> Rows Removed by Filter: 899400
> Execution time: 288.702 ms

なお、PostgreSQLには式インデックスという機能があって、それを作ればインデックスが使われる。
create index hoge_calc_idx on hoge((year*100+month));
> Bitmap Index Scan on hoge_calc_idx (cost=0.00..106.42 rows=5000 width=0) (actual time=13.776..13.776 rows=100600 loops=1)
> Index Cond: ((((hoge.year * 100) + hoge.month) >= 201604) AND (((hoge.year * 100) + hoge.month) <= 201703))
> Execution time: 74.346 ms

655
NAME IS NULL[sage]   投稿日:2017/05/09 18:45:08

656
NAME IS NULL[sage]   投稿日:2017/05/10 10:29:23
>324
まあ、微粒子レベルで俺が間違ってる可能性があるからな

657
NAME IS NULL[sage]   投稿日:2017/05/10 10:41:42
>325
お前が>323なら、おかしいのはお前の相手の方だから心配すんな
>268からずっとおかしい
相手するだけ無駄

658
NAME IS NULL[sage]   投稿日:2017/05/10 10:55:53
今時、コストベースがどうこうとか言う奴だからな。
10年以上前にちょろっとDB触ったレベルの奴じゃね?

659
NAME IS NULL[sage]   投稿日:2017/05/10 14:06:04
・ストアドにしてオーバーロードしろ
・インデックス使いたいならdate型にしろ
・date型にしないなら個別インデックスにしろ
・Bit Map Indexガー
・ソートガー

全部同じやつでしょ
最初からおかしい

660
NAME IS NULL[sage]   投稿日:2017/05/10 17:35:34
今更というかやっと式インデックスが出てくる脱力感

661
NAME IS NULL[sage]   投稿日:2017/05/10 18:21:15
>329
式なんか使わずに普通にクエリ書けと何度言ったら

662
NAME IS NULL[]   投稿日:2017/05/15 18:17:10
Local and global coordinate system

663
gわずに普通にクエリ書けと何度言ったら []   投稿日:0000/00/00 00:00:00

664
NAME IS NULL[]   投稿日:2017/05/15 18:17:10  ID:/ZtiK+kF.net
Local and global coordinate system
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

データベース板 タイトル検索

このスレッドが人気です(実況系)
実況 ◆ テレビ朝日 48021 (317)テレ朝実況
NHK総合を常に実況し続けるスレ 134295 ギョギョ (673)NHK実況
[再]昼顔〜平日午後3時の恋人たち〜 #09 (526)フジ実況
バイキングとグッディ★4 (938)フジ実況
連続テレビ小説 ひよっこ★99 (764)NHK実況
実況 ◆ 日本テレビ 55334 (575)NTV実況
実況 ◆ フジテレビ 83495 (806)フジ実況
ごごナマ おしゃべり日和「壇蜜さん 魅惑の壇蜜ワールドで夢心地…」 (492)NHK実況
このスレッドが人気です(ニュース系)
【芸能】<松本人志を批判した中田敦彦に反響!> 吉本の社長らが「謝れ!」 ★3 (510)音楽・芸能ニュース
【出会い系バー出入り】前川・前文科次官「行ったことは事実」「女性の貧困について実地の視察調査の意味合いがあった」★96 (171)ニュー速+
【出会い系バー出入り】前川・前文科次官「行ったことは事実」「女性の貧困について実地の視察調査の意味合いがあった」★95 (1001)ニュー速+
【話題】元東京都知事の猪瀬直樹氏、XVideosブックマークについて釈明 「週刊誌の記事で紹介されたサイトをメモ的に残していたもの」 (1001)ニュー速+
【科学】近親相姦はなぜダメなのか? 「障害児が生まれる」は作り話★4 (455)ニュー速+
【芸能】海老蔵、麻央の一時帰宅を報告 「今日実はまお 帰ってきました 家に おかえり」 (410)音楽・芸能ニュース
【社会】女子生徒に「裸になれ」 教諭懲戒免職 「大人になったらエッチしような」とも 堺市 (181)ニュー速+
【話題】元東京都知事の猪瀬直樹氏、Xvideosをブックマーク トレンドに ★2 (990)ニュー速+
データベース板の人気スレ
Oracle 質問総合スレ12 (767)
SQL初心者質問スレ (670)
PostgreSQL Part.11 (218)
Oracle 質問総合スレ9 (986)
MySQL 総合 Part24 (1010)
Oracle 質問総合スレ10 (1014)
SQL質疑応答スレ 15問目 (1013)
SQL質疑応答スレ 17問目 (331)
[test] 書き込みテスト 専用スレッド [テスト] (386)
MySQL 総合 Part25 (895)
Microsoft SQL Server 総合スレ 11 (402)
♪つっかもうぜ!DB! (68)
SQLite Part.10 (607)
はじまりです。 (584)
XML統合スレッド (397)
RDBMS比較総合スレ 【サーバ】 (115)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
広告


首都圏の方、ソフトバンク光オススメですよ


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード:差分取得 - 正常取得 - 3件 - 取得完了