SQL質疑応答スレ 17問目 [無断転載禁止]©2ch.net

レス数が1000を超えています。これ以上書き込みはできません。
1NAME IS NULL2016/07/10(日) 22:29:01.40ID:???
このスレは
「こういうことをやりたいんだけどSQLでどう書くの?」
「こういうSQLを書いたんだけどうまく動きません><」
などの質問を受け付けるスレです。

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

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

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

前スレ:
SQL質疑応答スレ 16問目
http://echo.2ch.net/test/read.cgi/db/1447160858/

2NAME IS NULL2016/07/10(日) 22:29:31.04ID:???

3NAME IS NULL2016/07/10(日) 22:30:30.90ID:???

4NAME IS NULL2016/07/10(日) 22:30:52.07ID:???
よくある質問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
;

5NAME IS NULL2016/07/10(日) 22:31:14.13ID:???
よくある質問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
;

6NAME IS NULL2016/07/10(日) 22:34:14.23ID:???
よくある質問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によって文法がかなり違うので注意

7NAME IS NULL2016/07/10(日) 22:34:59.82ID:???
よくある質問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/statements_10002.htm#CHDCEJJE
http://www.oracle.com/technetwork/articles/sql/11g-pivot-097235.html

8NAME IS NULL2016/07/10(日) 22:46:13.30ID:???
ううむ、ブロックされてしまいました。どうしたらいいだろう。

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.

9NAME IS NULL2016/07/10(日) 22:47:49.09ID:???
SQLソースの部分は外しておきます。

よくある質問5

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

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

   20100601
   20100602
    ・
    ・
    ・
   20100630

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

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

10NAME IS NULL2016/07/10(日) 22:49:00.82ID:???
以上、テンプレ終わり

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

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

12NAME IS NULL2016/07/14(木) 03:19:38.54ID:???
ここに内容書けば無料なんだけど

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

14NAME IS NULL2016/07/15(金) 09:39:41.81ID:???
プレーンテキストでここに貼って

15NAME IS NULL2016/07/15(金) 10:18:31.95ID:???
ワードファイル送りつけられても迷惑メールからのゴミ箱インよ

16NAME IS NULL2016/07/15(金) 11:41:49.64ID:???
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個くらいやれば終わりです。

17NAME IS NULL2016/07/15(金) 13:52:48.16ID:???
金もらって引き受けるほどの仕事じゃないようだし
そういう手間かけるくらいなら、ご自身で治した方が良いのでは?

18NAME IS NULL2016/07/15(金) 14:14:56.18ID:???
> SELECT *FROM 氏名表 AS A
> WHERE A.番号IN
> (SELECT 番号
> FROM 成績表
> WHERE 点数>=500)

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

19NAME IS NULL2016/07/15(金) 14:20:47.03ID:???
要件を教えて欲しいのだが。何を直せばいいいんだ?

20NAME IS NULL2016/07/15(金) 15:30:39.87ID:???
>>16
inをjoinに置き換えろって話のようにみえるけど
joinしたビュー作っとけばもっと楽かもしれんぞ

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

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

21NAME IS NULL2016/07/15(金) 15:46:23.35ID:zBhn779u
これについてはインラインビュー(FROM句の副問い合わせ)はやめた方がいいな。

WHERE句で絞った方がいい。

22NAME IS NULL2016/07/15(金) 16:18:18.22ID:???
同感

23NAME IS NULL2016/07/15(金) 16:41:58.02ID:???
実行計画見るまでもないレベルのデータ量な気がするが。
何やっても数百ms程度で戻る気が。

24NAME IS NULL2016/07/15(金) 16:57:08.32ID:???
>>21
その理由は?
単なる性能的な話なら、まず実行計画見るよって事だし

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

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

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

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

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

27NAME IS NULL2016/07/15(金) 19:15:33.39ID:???
僕のために争ってくれてありがとう。
依頼する人は見つけたから大丈夫だよー
これで単位も一安心

28NAME IS NULL2016/07/15(金) 19:51:07.64ID:zBhn779u
>>24
理由も何もまずはSQLの普通の書き方しろってことだよ。

29NAME IS NULL2016/07/15(金) 19:53:41.17ID:zBhn779u
>>24
INリストには数の制限があるからな。

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

30NAME IS NULL2016/07/15(金) 20:33:15.50ID:OwU9VU0D
>>29
お前はバカなんだから口を慎しめと何度

31NAME IS NULL2016/07/16(土) 17:02:32.57ID:IKSp3mrg
>>30
どこが間違っているのか教えてください。

32NAME IS NULL2016/07/16(土) 17:08:06.50ID:IKSp3mrg
↓これ何?

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

33NAME IS NULL2016/07/17(日) 21:52:20.05ID:N1m3wNQ4
すみません、以下、質問させてください。

親テーブル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です、よろしくお願いします。

34NAME IS NULL2016/07/17(日) 22:41:52.05ID:2o6ZRKeT
>>33
リレーションの説明がありませんので、答えようがありません。

35NAME IS NULL2016/07/17(日) 22:58:48.06ID:???
B×Cの中から自分が欲しいものを条件で絞り込むんだよ。その条件が無いから全部出てくる。

36NAME IS NULL2016/07/17(日) 23:00:32.84ID:N1m3wNQ4
>>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)

37NAME IS NULL2016/07/17(日) 23:02:11.09ID:fmLQHPFo
おもしろい展開w

38NAME IS NULL2016/07/17(日) 23:41:31.84ID:???
質問がいまいち理解できん
そもそもIOとか、SQL書いたとおりに実行されるわけじゃないんだが

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

39NAME IS NULL2016/07/18(月) 00:53:22.27ID:EKBnHgrJ
>>38
俺もI/Oについては突っ込みたかったが、そもそもRDBの理論、概念を否定する内容だからスルーしたw

40NAME IS NULL2016/07/18(月) 00:55:52.42ID:EKBnHgrJ
>>36
その"C(5)"って何?

データ型?

41NAME IS NULL2016/07/18(月) 01:03:46.13ID:EKBnHgrJ
>>36
その3つのテーブルをaという列だけで結合すればいい話なのかな?

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

42NAME IS NULL2016/07/18(月) 01:12:13.04ID:EKBnHgrJ
BテーブルとCテーブルにリレーション、関連性があるのかないのかはっきりしてくれ。

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

どっちなの?

43NAME IS NULL2016/07/18(月) 01:17:58.22ID:???
unionの話じゃないのかい

44NAME IS NULL2016/07/18(月) 03:30:28.74ID:Dk5LLrvU
>>39
RDBの理論が分かってないのはお前な

45NAME IS NULL2016/07/18(月) 06:25:57.47ID:EKBnHgrJ
>>44
それはRDBMSのことであって特定の製品を指しているわけでもない。

46NAME IS NULL2016/07/18(月) 08:25:50.10ID:Dk5LLrvU
>>45
ワケ分からん事言ってないで必死でググって顔真っ赤にして感謝しろよw
今頃もう真っ赤っ赤かなw

47NAME IS NULL2016/07/19(火) 00:50:27.43ID:yVILcX3x
RDBMSはSQLの処理の方法にRDBMSに任せるのがRDBなんだよ。

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

48NAME IS NULL2016/07/19(火) 03:30:05.15ID:???
とりあえず書き込む前に書こうまず読み直してとりあえず書こう

49NAME IS NULL2016/07/19(火) 04:19:10.59ID:???
慌てないで、落ち着いて

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

51NAME IS NULL2016/07/24(日) 10:41:37.30ID:???

52NAME IS NULL2016/07/27(水) 21:37:51.21ID:OesecO5v
ジョインで連結しまくったクエリに
ORDER BY で並び替えかけると
えらい遅くなるのですが
改善する方法はないのでしょうか?

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

54NAME IS NULL2016/07/27(水) 21:58:01.84ID:???
的確。

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

56NAME IS NULL2016/07/27(水) 22:52:26.24ID:???
GROUP BYもあるならmaterialized viewにしてインデックス張るしかないかな
メモリをひたすら積んでメモリソートでごり押しという手もあるが

57NAME IS NULL2016/07/27(水) 23:13:51.10ID:???
テーブルレイアウトと実行してるSQL全部書けば
ある程度汎用的なインデックスのアドバイスができるかもしれんが

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

58NAME IS NULL2016/07/27(水) 23:27:08.61ID:???
【質問テンプレ】
・DBMS名とバージョン

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

59NAME IS NULL2016/07/28(木) 00:48:24.45ID:Pc5r9mq6
テーブルレイアウトって言葉はやめてほしいわ。

60NAME IS NULL2016/07/28(木) 10:49:25.87ID:???
うちのダイニングのテーブルの配置はどう言ったらいいでしょうか

61NAME IS NULL2016/07/28(木) 14:59:33.90ID:???
 
粗大ゴミの回収に出す

62NAME IS NULL2016/07/29(金) 09:54:35.19ID:SbaxQ6kv
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がなければパフォーマンスはそれほど問題はありません。

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

63NAME IS NULL2016/07/29(金) 10:09:10.29ID:???
それだとGROUP BYよりEXISTSのほうがよくね?

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

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

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

65NAME IS NULL2016/07/30(土) 07:56:46.82ID:XyUbordV
ない項目のインデックスはどうやって作るのか

66NAME IS NULL2016/07/30(土) 08:19:54.62ID:???
ない項目ってどういう意味だ?
インデックスは項目(の組み合わせ)に対して作るものだぞ

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

68NAME IS NULL2016/07/31(日) 09:46:00.41ID:???
>>67
自分で決める事では

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

70NAME IS NULL2016/07/31(日) 14:20:50.26ID:???
ちなみに>>67はおかしいですか?
先生にしらせるときと生徒に知らせる時でER図を書きなさいって問題なんですが

71NAME IS NULL2016/07/31(日) 16:02:20.51ID:???
問題に書いてあることを誤読や読み落とししている気がする。

72NAME IS NULL2016/07/31(日) 17:31:55.47ID:???
宿題を堂々とここに書いて教えろと要求かぁ

73NAME IS NULL2016/07/31(日) 21:26:13.43ID:???
まずER図書いてみろって話だが

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

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

74NAME IS NULL2016/08/08(月) 22:56:12.48ID:???
・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

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

75NAME IS NULL2016/08/08(月) 23:54:36.83ID:???
名前テーブルも作ってそれと外部結合すりゃいいじゃん。

76NAME IS NULL2016/08/09(火) 00:00:01.71ID:???
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)

77NAME IS NULL2016/08/09(火) 01:13:18.45ID:???
表示をその順序にしたいと言うなら、
その順序指定になるカラムを追加したら?

78NAME IS NULL2016/08/09(火) 08:40:05.08ID:???
>>76
> これにdddを1の下に追加して

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

79NAME IS NULL2016/08/09(火) 09:32:25.91ID:???
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

80NAME IS NULL2016/08/09(火) 10:03:52.74ID:???
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;

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

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

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

82742016/08/09(火) 23:16:58.43ID:???
>>75,81
ありがとう。
75 で言われてハッとして distinct で作った名前の一覧と月の一覧とを掛け合わせて、
これと元のテーブルデータを外部結合して行けました。

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

84NAME IS NULL2016/08/10(水) 16:49:54.18ID:???
>>83
お名前.com sdサーバー データベース バックアップ
でググったらすぐに見つかったが?

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

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

86NAME IS NULL2016/09/24(土) 03:18:01.58ID:???
>>85
joinを知らないとか分からないとか、そういうレベル?
とりあえず>>1読んで出直して

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

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

88NAME IS NULL2016/09/24(土) 07:52:00.23ID:???
>join対象が複数あったら、

複数joinすれば?

89NAME IS NULL2016/09/24(土) 11:06:44.19ID:???
深く考える前にやってみればいいんじゃないかな、とか。

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

91NAME IS NULL2016/09/24(土) 21:03:47.14ID:???
>>85
その前提なら
> 会社テーブル・従業員テーブルそれぞれ1回ずつ2回SELECT発行する
でいいと思う

92NAME IS NULL2016/09/24(土) 21:21:17.59ID:???
いや、1回SELECT発行がいいと思う

93NAME IS NULL2016/09/24(土) 21:23:50.81ID:dG2/rE9U
この場合それぞれ2回ずつSELECTが正解じゃね?

94NAME IS NULL2016/09/25(日) 07:15:27.74ID:???
従業員に付与される会社情報の多さが気になるなら2回でいいんじゃね
というか自分も2回だね

95NAME IS NULL2016/09/25(日) 08:00:17.84ID:???
>>93
2回ずつ?
なんのために?

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

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

98NAME IS NULL2016/09/25(日) 10:29:39.14ID:???
富豪アプローチで毎回取得&キャッシュでええやん。

99NAME IS NULL2016/09/25(日) 10:40:03.14ID:???
時間も掛かるし負荷も高いんじゃない?

100NAME IS NULL2016/09/25(日) 16:03:47.98ID:???
月額2000円くらいの予算でvps借りるとしてmysqlで最大どれくらいのトランザクションを捌けるもんなの?

101NAME IS NULL2016/09/25(日) 16:07:28.77ID:???
要件定義してあげるスレが必要

102NAME IS NULL2016/09/30(金) 00:05:15.58ID:???
どこで質問したらわからないんですが総合スレってありませんかね?

103NAME IS NULL2016/09/30(金) 14:16:58.52ID:???

104NAME IS NULL2016/11/09(水) 18:56:03.76ID:AtwDWs/+
Mysql で 出力データーを
20.00 → 20
21.40 → 21.4
23.05 → 23.05
20.10 → 20.1
みたいに少数以下の語尾のゼロを取ることをMySQL内ですることはできないでしょうか?

105NAME IS NULL2016/11/09(水) 19:00:44.82ID:???
普通付かないだろ
元の値は文字列なのか?

106NAME IS NULL2016/11/09(水) 19:05:31.21ID:AtwDWs/+
>>105
decimal です。

107NAME IS NULL2016/11/09(水) 19:39:25.86ID:???
>>104
なぜゼロ取りたいの?

108NAME IS NULL2016/11/14(月) 22:17:52.79ID:bmYVZ934
truncとかfloorとか
文字ならsubstrみたいなやつで

109NAME IS NULL2016/11/18(金) 01:26:39.84ID:???
アドバイスをいただきたく
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
)
/

110NAME IS NULL2016/11/21(月) 06:49:29.05ID:sXX+G/pS
>>109
/があるあたりでOracleだと思うが、なんで並列処理化するとか考えないの?

111NAME IS NULL2016/11/21(月) 11:05:47.74ID:???
というか、ふつうにhoge=trim(hoge)で良い気がするんだが
なんで自己結合する必要があるんだ

112NAME IS NULL2016/11/21(月) 11:19:03.28ID:???
それか元のテーブルをRENAMEして
新しいテーブルにINSERT SELECTしたら?
表領域足りんのか

113NAME IS NULL2016/11/21(月) 18:31:53.36ID:CmVzeDRz
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';

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

114NAME IS NULL2016/11/21(月) 18:43:05.79ID:???
>>113
and date_format(record, '%H:%i') between '09:00' and '12:00'

115NAME IS NULL2016/11/21(月) 19:36:05.17ID:???
>>114
できました!ありがとうございます!
date_format関数について勉強しておきます

116NAME IS NULL2016/11/22(火) 17:17:14.56ID:???
>>114
こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか?

117NAME IS NULL2016/11/22(火) 18:14:09.68ID:???
>>116
> こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか?
本読まないでしょ。
初心者でも入門書を2,3冊こなせば書けると思うよ。

118NAME IS NULL2016/11/22(火) 18:28:47.65ID:???
短いやつをちょっとずつ書けば慣れるけど
MySQLの方言だからねえ、、、

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

120NAME IS NULL2016/11/22(火) 20:04:48.97ID:???
>>117
入門書を二冊も読んだら上級者でしょ?
それもかなり上のクラスの

121NAME IS NULL2016/11/24(木) 15:48:27.14ID:???
sql初心者で2、3行程度の簡単なsqlしか実行した事がないんですが、世の中では何百行、何千行のsqlを実行する事もありますか?

122NAME IS NULL2016/11/24(木) 16:33:30.05ID:???
>>120
上級者のハードル低いね

123NAME IS NULL2016/11/24(木) 16:40:02.92ID:???
100行程度なら描いたことがある
メンテナンス性を考えると
あまり長くしないようがいいように思う

124NAME IS NULL2016/11/24(木) 16:49:13.99ID:???
>>122
相対的には上級者になるのかもねw
絶対的にはもちろん違うけど

125NAME IS NULL2016/11/24(木) 17:00:52.88ID:???
>>124
自分がかなり上のクラスの上級者であると自己判定していて、自分のクラスになるには入門書2冊が必要だった、ということかも

126NAME IS NULL2016/11/24(木) 17:17:01.99ID:???
入門書を何冊読んでも入門書レベルの知識しかつかないという、ごくあたりまえの話

127NAME IS NULL2016/11/24(木) 20:22:40.50ID:???
>>121
そんな複雑なやつを書く前にストアドとかビューを組み合わせるとかを検討する
そんなの書いたら検証がえらいことになる

128NAME IS NULL2016/11/24(木) 21:42:31.35ID:???
聞いた話でそれを見たことはないけど、1000行くらいのが出来上がったとかなんとか。
見たくもない(ある証券系のシステムでのお話)

129NAME IS NULL2016/11/25(金) 19:24:44.86ID:???
問い合わせ文じゃなくて、ややこしいストアド書くなら数百は余裕であり得るだろうけど

130NAME IS NULL2016/11/25(金) 21:18:31.44ID:???
行が増えざるを得ない状況がストアド開発には多すぎるからなぁ
つまり複雑度はなぜ行が多いのか次第

131NAME IS NULL2016/11/25(金) 21:23:23.29ID:riZyA4Jk
>>121
カラム数が多くて、改行してたらあっという間。

132NAME IS NULL2016/11/25(金) 22:45:32.51ID:???
>>131
> カラム数が多くて
それはそれでどうかと思うが...

133NAME IS NULL2016/11/28(月) 10:24:40.80ID:???
データ抽出用のビュー作るとカラム数数百とかなる

134NAME IS NULL2016/11/28(月) 11:06:13.68ID:???
二つのテーブルを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行とかいく。

135NAME IS NULL2016/11/28(月) 19:58:42.77ID:3f+IloFY
カラム数はシステムが古かったり、考え方が古いひとが作ったものをだったりするとコントロールできない。

136NAME IS NULL2016/11/28(月) 20:54:44.09ID:???
何か列と行がグチャグチャ

137NAME IS NULL2016/11/28(月) 21:16:32.90ID:???
わざわざ1カラム1行でクエリ書いて行数多くてメンテナンス性落ちるなら本末転倒

138NAME IS NULL2016/11/28(月) 22:25:17.16ID:PzYguHzt
>>137
はあ?

139NAME IS NULL2016/11/29(火) 10:41:34.96ID:???
>>137
>>134みたいなケースで言うと、行数が多くてメンテナンス性が落ちるということはない。
逆に、1行に複数カラムを羅列される方がメンテナンス性が落ちる。

140NAME IS NULL2016/11/29(火) 12:22:04.31ID:???
お前らの言うメンテナンス性ってテキストの編集しやすさの事だったんかw

141NAME IS NULL2016/11/29(火) 12:34:20.19ID:W7hPtk8B
>>140
保守、仕様変更でSQLの構文が書き直されるようなのは馬鹿のやることだろ。

リスク高すぎ。

142NAME IS NULL2016/11/29(火) 12:41:50.92ID:???
可読性が低くてメンテナンス性は高いという状況が思いつかない

143NAME IS NULL2016/11/29(火) 13:04:43.09ID:???
>>141
>保守、仕様変更で

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

144NAME IS NULL2016/11/29(火) 13:17:16.12ID:W7hPtk8B
>>143
ストアドだって同じだろw

145NAME IS NULL2016/11/29(火) 13:44:04.12ID:???
>>143
> なるべくSQL(ストアド)の変更だけで留めようと努力するけど違うのか
QiitaをkickされたSQLおじさん信者か何かか?

146NAME IS NULL2016/11/29(火) 21:15:59.57ID:???
>>145
SQLおじさんってどなた?
ORMおじさんは知ってたけど

147NAME IS NULL2016/11/30(水) 10:30:54.88ID:???
>>146
SQLおじさん、Qiitaに炎上記事投稿 周囲の反応と垢BANまでの流れ
http://togetter.com/li/1047474

148NAME IS NULL2016/11/30(水) 11:36:29.69ID:???
>>147
ありがとう、同一人物だった

149NAME IS NULL2016/12/14(水) 16:14:32.69ID:???
TBS

150NAME IS NULL2016/12/17(土) 00:34:45.23ID:L7Q4LZyG
教えてください
アクセスを使ってます

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

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

151NAME IS NULL2016/12/17(土) 01:19:14.54ID:L7Q4LZyG
150です

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

152NAME IS NULL2016/12/23(金) 14:37:04.89ID:???
それクロス集計じゃなくてただの直積じゃないのか…?

153NAME IS NULL2016/12/24(土) 04:08:40.81ID:???
クロス結合とクロス集計って違うよ

154NAME IS NULL2016/12/26(月) 23:30:53.01ID:???
すみません、教えていただけますでしょうか。
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する形になると思うのですが、
よい方法があれば教えていただけないでしょうか。

155NAME IS NULL2016/12/27(火) 02:49:52.16ID:???
>>154
もしかして"10.90.10"で一つの項目に入っていて
そのうちの"10.90"と突き合わせたいとかいう話?

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

156NAME IS NULL2016/12/27(火) 07:38:43.84ID:???
>>155 早速のレス、ありがとうございます。

>>もしかして

157NAME IS NULL2016/12/27(火) 07:39:20.83ID:???
すみません、なぜか切れてしまいました。

>>もしかして"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円
のような感じです。

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

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

159NAME IS NULL2016/12/27(火) 11:54:27.23ID:???
>>158
それselect * してるやつがいたらこける可能性ある

160NAME IS NULL2016/12/27(火) 12:00:38.56ID:???
>社内用のシステムでお客様で使っているものではないのが救い

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

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

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

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

162NAME IS NULL2016/12/27(火) 14:28:17.14ID:???
わざわざ abczz じゃなく abdzz にしてる意図が気になるな

163NAME IS NULL2016/12/27(火) 15:14:12.20ID:???
>>162
likeしたときに
abc-とabcde-だと被るからじゃない?

164NAME IS NULL2016/12/27(火) 16:49:49.23ID:???
苦しすぎるw

165NAME IS NULL2016/12/27(火) 17:12:37.88ID:???
>>157
> データベース設計を見直したいのですが、もうシステムが動いてしまっていて、
> 変更がちょっと難しい状態なのです、、、

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

166NAME IS NULL2016/12/27(火) 19:31:30.63ID:???
>>165
view賛成
ま、弊社の場合はviewだらけで訳が分からなくなってるけどね(笑

167NAME IS NULL2016/12/27(火) 21:09:16.63ID:???
>>165
ソレダ

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

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

169NAME IS NULL2016/12/28(水) 06:24:05.12ID:???
>>165
accessで困ってる初心者に追加可能な選択クエリとか書けるかっていう疑問はあるけど出来たらそれで良いかもね

170NAME IS NULL2016/12/29(木) 07:14:51.28ID:???
viewじゃ更新できないカラムのsqlあったらどうすんの

171NAME IS NULL2017/01/04(水) 10:49:09.60ID:???
トリガー作るしか無いかなあ

172NAME IS NULL2017/01/29(日) 14:56:15.44ID:???
oracleのmergeについて質問です。
oracleは11gを使っています。


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

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

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

173NAME IS NULL2017/03/14(火) 22:41:55.92ID:???
【質問テンプレ】
・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の値を結合したいです。
よろしくお願いします。

174NAME IS NULL2017/03/15(水) 00:45:52.14ID:???
主キーも何も無いのこれw

175NAME IS NULL2017/03/15(水) 14:25:20.71ID:???
Nameの結合の順番は決まってんの?

176NAME IS NULL2017/03/15(水) 18:49:35.26ID:???
group_concat()があれば簡単なのに

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

177NAME IS NULL2017/03/15(水) 20:10:02.29ID:???
AccessならVBAでID受け取ってNameをカンマ連結した文字列返す関数作ればできんじゃね

1781732017/03/17(金) 23:41:34.54ID:???
>>174-177
返信おそくなってすみません
質問に不足してた部分があったので
また質問しなおしたいと思います

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

179NAME IS NULL2017/04/26(水) 20:40:34.52ID:???
・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月までの会計年度の行を取りたいのですが、そのようなことは可能でしょうか お願いします

180NAME IS NULL2017/04/26(水) 21:37:32.38ID:???
select * from table where year*100+month between 201704 and 201803;

じゃだめか?

181NAME IS NULL2017/04/26(水) 21:56:03.44ID:yyy4jyWJ
俺じゃダメか?

182NAME IS NULL2017/04/26(水) 22:08:23.58ID:???
(year=2017 and month>=4) or (year=2018 and month<=3)でいいだろ

183NAME IS NULL2017/04/26(水) 22:54:12.56ID:???
IIf(Month<4,Year-1,Year) AS 会計年度
見たいなカラム持ったクエリ定義しとけよ

1841832017/04/26(水) 22:57:19.84ID:???
あ、なぜかACCESSだと思ってたw
標準的なSQLならCASEでビューか

まあ、わかるだろ

185NAME IS NULL2017/04/27(木) 04:56:49.99ID:???
>>179
性能は知らん
where make_date(year, month, 1) between '2017-04-01' and '2018-03-31'

186NAME IS NULL2017/04/27(木) 07:07:55.94ID:???
>>182
自分もこれだな

187NAME IS NULL2017/04/27(木) 09:29:25.83ID:???
日付を分割してintに入れる糞実装、未だに存在するのかよ

188NAME IS NULL2017/04/27(木) 10:38:00.97ID:???
日付じゃなくて必要なのが月までだからだろ

189NAME IS NULL2017/04/27(木) 10:55:10.08ID:???
それでも /01 にしてdate型に突っ込むわ

190NAME IS NULL2017/04/27(木) 12:24:41.45ID:???
どうでもいいけど言うならせめて糞設計だよね
実装てw

191sage2017/04/27(木) 15:25:55.19ID:JuRKhktP
設計:年・月を保存する
実装:年・月を別カラムにする

192NAME IS NULL2017/04/27(木) 15:38:14.45ID:???
質問者への回答と、設計の改善提案は別だろうに

193NAME IS NULL2017/04/27(木) 16:00:01.62ID:???
number(8)に日付いれるのが好きなフレンズもいるな

194NAME IS NULL2017/04/27(木) 16:08:50.03ID:???
>>193
難点は経過日数計算が大変な

195NAME IS NULL2017/04/27(木) 17:08:47.17ID:???
俺は >>180 支持だなぁ
速度的にも見た目的にも

196NAME IS NULL2017/04/27(木) 18:52:05.48ID:???
>>180
会計年度中も指定できるので非常に参考になりました

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

197NAME IS NULL2017/04/27(木) 18:59:16.96ID:???
年月を保持する要件で、データに意味を持たない日の情報が含まれるって、良いのでしょうか

バグを産む可能性を秘めてるような

198NAME IS NULL2017/04/27(木) 19:31:38.84ID:???
>>197
あり得ない月とかを突っ込める方が恐いわ

199NAME IS NULL2017/04/27(木) 19:39:19.72ID:QZ3/RiVo
>>198
そんなもんなんぼでもあるわwお前ビビりすぎw

200NAME IS NULL2017/04/27(木) 19:54:14.57ID:???
バカが現れた

201NAME IS NULL2017/04/27(木) 20:18:45.26ID:???
>>199のレスの意味がわからなすぎる

202NAME IS NULL2017/04/27(木) 20:19:31.22ID:???
バグというより、データベースに事実にない情報を含めるとか違和感が

203NAME IS NULL2017/04/27(木) 20:44:47.72ID:???
numberでもバグを産む可能性を秘めてるし
どっちのリスクをとるかだけじゃね

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

205NAME IS NULL2017/04/28(金) 07:06:33.42ID:???
そして2017/4/1と2017/4/2など
同一年月で複数レコードできてしまうのでした

206NAME IS NULL2017/04/28(金) 07:18:39.77ID:???
年月情報をユニーク制約を保持する仕様で日付計算のためにdate使ってたら、皆さんはどう思いますか

207NAME IS NULL2017/04/28(金) 10:47:01.79ID:???
もうUNIQUE制約のある年月列と日付計算用の列を分けろよ

208NAME IS NULL2017/04/28(金) 11:33:54.87ID:???
レコードの入力時に日付が何入っていようと、1にしてしまえば良いだけだろう

209NAME IS NULL2017/04/28(金) 12:16:53.71ID:???
そんなもん制約がなければ全く信用できん
本当に頭が悪いなお前ら

210NAME IS NULL2017/04/28(金) 13:33:21.87ID:???
>>205
2017/00 とか 2017/13 とか入ってるのとどっちがいい?

211NAME IS NULL2017/04/28(金) 15:57:28.27ID:???
DB側の制約がいかに利用されていないか分かるな

212NAME IS NULL2017/04/28(金) 18:48:18.70ID:???
1日の0時になっているか確認するcheck制約つければいい

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

214NAME IS NULL2017/04/30(日) 03:36:41.43ID:???
>>182
後の人間を苦しめるコードをまき散らすのは止めよう

215NAME IS NULL2017/04/30(日) 19:54:54.91ID:PSrTmapn
>>214
馬鹿の苦しみなんか気にしてられんわw

216NAME IS NULL2017/04/30(日) 20:56:47.54ID:???
3年分取ってきてと言われて初めて問題に気付くパターンや

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

218NAME IS NULL2017/04/30(日) 23:33:29.04ID:???
あと fiscal_year(date) みたいにオーバーロードしとけば
インターフェースが統一されて使いやすい

219NAME IS NULL2017/05/01(月) 09:41:38.57ID:???
SQLにオーバーロードあるんですか?どんなRDB?

220NAME IS NULL2017/05/01(月) 10:54:41.81ID:???
え、、、普通にあるでしょ
むしろできないDBってどれよ

221NAME IS NULL2017/05/01(月) 13:48:49.26ID:???
>>220
できないやつ多数でしょ

222NAME IS NULL2017/05/01(月) 14:14:22.87ID:???
そうなんか、OracleとPostgreSQLで出来てるから普通なのかと・・・

223NAME IS NULL2017/05/01(月) 14:29:03.64ID:???
まーた、俺様の「普通」が炸裂しとる

224NAME IS NULL2017/05/01(月) 14:33:46.48ID:???
Oracleは特例
いいね?

225NAME IS NULL2017/05/01(月) 15:03:51.32ID:???
てか、そもそもOracleでも単純なオーバーロードってあったっけ?

226NAME IS NULL2017/05/01(月) 15:05:03.60ID:???
packageを使ったオーバーロードはあるが・・・
http://www.shift-the-oracle.com/plsql/overloading-subprogram-name.html

227NAME IS NULL2017/05/01(月) 15:07:37.27ID:???
このケースはComputed Columnが使えればそれがいいと思うけど
Postgresでは使えないから関数オーバーロードしとくって話
Computed Columnなら使えるDB多いだろ

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

228NAME IS NULL2017/05/01(月) 15:15:27.63ID:???
普通に>>182でいいだろ

229NAME IS NULL2017/05/01(月) 15:36:01.14ID:???
PostgreSQL有害論

230NAME IS NULL2017/05/01(月) 16:10:53.74ID:???
>>228
会計年度を必要とするたびに繰り返し同じことをするのでよければね
年度別に集計したい場合とかしんどいし俺はごめんだわ

231NAME IS NULL2017/05/01(月) 16:49:59.51ID:???
普通に関数でいいと思うんだが、あえて(関数?)オーバーロードって言ってるのはなんで?

232NAME IS NULL2017/05/01(月) 16:57:59.25ID:???
>>230
そういうこと言ってるからいつまでたってもスキルが向上しないんだよ
select case when month < 4 then year - 1 else year end as fiscal_year, sum(hoge)
from foo
group by case when month < 4 then year - 1 else year end

233NAME IS NULL2017/05/01(月) 17:06:24.57ID:???
つか、いたるところで会計年度を意識するようなシステムなら、会計年度カラムを作っとけばいいよな

234NAME IS NULL2017/05/01(月) 18:03:32.59ID:???
>>232
where句も入れて何回繰り返すのさ
面倒くさいとは思わないの?
単発の作業ならわからんでもないが会計年度みたいなのは1回じゃすまないだろ

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

235NAME IS NULL2017/05/01(月) 18:18:52.43ID:???
>>234
> 面倒くさいとは思わないの?
いや、まったく
>>232レベルのクエリなら10秒もかからずタイプできるだろ

236NAME IS NULL2017/05/01(月) 18:28:00.19ID:???
>>234
> where句も入れて何回繰り返すのさ
ストアドでも似たようなもんだろ。
select fiscal_year(year, month), sum(hoge) from fuga group by fiscal_year(year, month)
しかもストアド使うと、year, monthにインデックスあっても使われないし。

237NAME IS NULL2017/05/01(月) 18:37:19.33ID:???
ストアド最強!!!|バカの壁| SQL92以降

238NAME IS NULL2017/05/01(月) 18:46:32.86ID:???
kantomi@qiita_banned < ストアド!ストアド!

239NAME IS NULL2017/05/01(月) 18:53:59.52ID:???
>>235
面倒くさいと思わないならいいんじゃね

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

インデックスは必要ならはればいい

240NAME IS NULL2017/05/01(月) 19:03:28.63ID:???
>>233
算出できる情報を別途カラム作って持たせるのは最終手段

241NAME IS NULL2017/05/01(月) 19:04:19.13ID:???
>>180 重み付けの定石
>>182 単年度でしか動かないクソ
>>185 意図が分かりやすい
>>217 ビジネスロジックをDBMSに持たせる派とアプリに持たせる派で戦争勃発

242NAME IS NULL2017/05/01(月) 19:33:28.15ID:???
>>241
一番馬鹿ww

243NAME IS NULL2017/05/01(月) 21:25:30.10ID:???
>>234
fiscal_year(year, month)って関数自体はまだなにもオーバーロードしてないだろうが。

244NAME IS NULL2017/05/01(月) 21:52:46.85ID:45FTV8QE
>>241のどこが馬鹿なのか論理的に説明できないやついるの?

245NAME IS NULL2017/05/01(月) 23:12:56.24ID:???
>>240
分解せずに日付型で持っていればよかったって事だな
以降>>188へ戻る

246NAME IS NULL2017/05/02(火) 03:16:15.56ID:???
管理上のオーバーヘッドってのがユーザ側の話なのかシステム側の話なのかしらんが
関数オーバーロードができたとして、それがビューより管理が重いとか信じられん

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

247NAME IS NULL2017/05/02(火) 08:24:38.84ID:???
一方ロシアは会計年度カラムを追加した

248NAME IS NULL2017/05/02(火) 10:00:08.57ID:???
インデックス張るなら、ロシア方式が一番いいよな
トリガーで仕掛けておけば気にしなくて済むし

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

250NAME IS NULL2017/05/02(火) 10:22:47.67ID:???
>>239
> asで名前つけとけばgroup byでは繰り返す必要ないよ
その手段が使えるDBでは、>>232も同じことが言える

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

251NAME IS NULL2017/05/02(火) 10:26:43.28ID:???
ん? >>232 だとインデックス使われないだろ
>>217-218 >>185 のような関数だともっと使われない
>>182 のように or あると、うまく使ってくれるか怪しい

252NAME IS NULL2017/05/02(火) 10:38:44.85ID:???
>>251
> ん? >>232 だとインデックス使われないだろ
where書いてないからね
>>232は、集計がしんどいという奴へのレス

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

253NAME IS NULL2017/05/02(火) 10:44:41.29ID:???
それより決算月が変わる可能性について考えたほうがいいと思う

254NAME IS NULL2017/05/02(火) 10:45:38.57ID:???
>>251
> >>217-218 >>185 のような関数だともっと使われない
こういうバカ避けのためにわざわざ「性能は知らん」って書いてあるのにバカはそれすら理解できないんだな w
インデックス使いたいならdate型にしとけよ

255NAME IS NULL2017/05/02(火) 10:49:15.47ID:???
>>253
会計年度カラム追加で解決。

256NAME IS NULL2017/05/02(火) 10:51:13.38ID:???
>>254
year, monthにインデックス張ればいいだろ
アホか

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

258NAME IS NULL2017/05/02(火) 11:03:21.36ID:???
>>256
> year, monthにインデックス張ればいいだろ

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

259NAME IS NULL2017/05/02(火) 15:49:34.57ID:???
>>256
バカってこれだから...
複数の列に張るより単一の方が有利だろう
そんなことも理解できないのかよ w

260NAME IS NULL2017/05/02(火) 16:00:26.84ID:???
そんな理由だったらオレもアンタをバカ呼ばわりしていいかな

261NAME IS NULL2017/05/02(火) 16:16:34.86ID:???
>>260
理由が書けるならね

262NAME IS NULL2017/05/02(火) 17:11:25.84ID:???
不利っつっても、比較が1回か2回かって違いくらいしかないだろ。

263NAME IS NULL2017/05/02(火) 17:17:06.13ID:???
ここを2つに分けるかどうかの是非はともかく
キーが2つになるから絡むつにしようとかおかしいだろw

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

264NAME IS NULL2017/05/02(火) 18:48:29.70ID:???
>複数の列に張る

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

265NAME IS NULL2017/05/02(火) 18:57:10.84ID:???
yearのインデックスとmonthのインデックスを別々に張りそう

266NAME IS NULL2017/05/02(火) 19:11:26.98ID:???
>>250
>その手段が使えるDBでは、>>232も同じことが言える
そんなんわざわざ言わんでもわかっとるがな〜ww

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

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

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

268NAME IS NULL2017/05/02(火) 22:51:26.07ID:???
>>264
お前こそわかってないだろ w
>>180, >>182 みたいに複合インデックスの各々の列を別々に大小比較で使うとインデックス使えないぞ

269NAME IS NULL2017/05/02(火) 23:17:09.54ID:???
使われないインデックスと、使えないお前らの脳ミソ達。

270NAME IS NULL2017/05/03(水) 00:11:51.74ID:???
>>182は(orは別として)yearとmonthの複合インデックスの教科書的な例だと思うが。
つか、>>180>>182を同列に並べている時点でお里が知れる。

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

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

272NAME IS NULL2017/05/03(水) 07:59:56.11ID:???
馬鹿はなぜ無駄に未来の心配ばかりするのか

273NAME IS NULL2017/05/03(水) 09:25:30.95ID:???
>>270
実行計画見てみ
複合インデックスの仕組み知ってたらそんなアホな発想はできないよ

274NAME IS NULL2017/05/03(水) 10:39:56.79ID:???
おまえこそ見てみろと言いたいが。

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

275NAME IS NULL2017/05/03(水) 11:04:58.97ID:???
>>274
> orのせいで
バカを晒すのはほどほどにしろよ

276NAME IS NULL2017/05/03(水) 12:06:11.56ID:???
>>274
複合インデックスから任意の1つの列を選んで使う事はできないので、 データベースはインデックスを使いません。
インデックスの構造をより深く見ていくと、この理由がはっきりします。
http://use-the-index-luke.com/ja/sql/where-clause/the-equals-operator/concatenated-keys

277NAME IS NULL2017/05/03(水) 12:40:47.23ID:???
今どきは>>182でも(year,month)のインデックスがあれば
(そしてそれを使ったほうが速いとDBMSが判断すれば)
使うDBMSのほうが多いと思う

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

278NAME IS NULL2017/05/03(水) 13:06:33.96ID:???
>>276
それはyearを使わずにmonthだけだった場合だな。こんな初歩的な勘違いしてたのか。

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

280NAME IS NULL2017/05/03(水) 14:38:41.03ID:???
アホなレス量産してるやつは約1名だけっぽいな

281NAME IS NULL2017/05/03(水) 17:44:08.92ID:???
year, monthにインデックスの件だけど、PostgreSQLなら使われるけどなぁ
ほかのDBだと使われなかったりするのか?

282NAME IS NULL2017/05/03(水) 17:47:31.47ID:???
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

283NAME IS NULL2017/05/03(水) 18:26:59.82ID:???
使われないDBがあると思ってるのは約1名だけだぞ

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

285NAME IS NULL2017/05/03(水) 18:42:36.82ID:???
インデックス使われないマン =
オーバーロードマン =
Computed Columnマン

286NAME IS NULL2017/05/03(水) 18:49:07.86ID:???
=管理レベルマン

287NAME IS NULL2017/05/03(水) 19:48:53.29ID:???
>>281-282
ああPostgreSQLはデータが少ない時はBit Map展開するのか
http://use-the-index-luke.com/ja/sql/explain-plan/postgresql/operations
それを一般的な話にされても困るな

288NAME IS NULL2017/05/03(水) 19:56:46.81ID:???
まさか今どき、インデックスがあれば必ず使うとか思ってるんだろうか
ルールベースとコストベースの違いも分かってない?

289NAME IS NULL2017/05/03(水) 20:03:06.22ID:???
「使われない場合もある」に方向転換w

290NAME IS NULL2017/05/03(水) 20:30:25.65ID:???
>>285
おいこら
インデックス使われないマンと一緒するなよw

291NAME IS NULL2017/05/03(水) 20:42:23.99ID:???
>>288
>>270 辺りに言ってやれよ

292NAME IS NULL2017/05/03(水) 20:49:46.41ID:???
>>291
インデックス使われないマンちぃーす

293NAME IS NULL2017/05/03(水) 21:10:30.66ID:/Lg9geb/
お前らが馬鹿なのは使う必要のないインデックスについて延々と話してることだけどな

294NAME IS NULL2017/05/03(水) 22:00:09.77ID:???
>>288
「使う場合もある」に方向転換w

295NAME IS NULL2017/05/03(水) 22:14:57.26ID:???
>>282
それ >>287 が書いてる通り Bit Map Index Scanだよ
URL読めばわかると思うけど

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

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

296NAME IS NULL2017/05/03(水) 22:20:18.00ID:???
結論

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

297NAME IS NULL2017/05/03(水) 22:20:54.65ID:???
まあ、日付型とか言ってる奴は決算月の考慮どうするんだろうと思うわ

298NAME IS NULL2017/05/03(水) 22:51:38.44ID:???
またドヤ顔で恥の上塗り

299NAME IS NULL2017/05/03(水) 22:56:01.77ID:???
具体的に説明できない奴がわらわら沸いてるw

300NAME IS NULL2017/05/03(水) 23:01:34.87ID:???
>>297
決算月と日付型との間に問題があるなら後学のために披露しては?
それか質問なら>>1読んでからどうぞ

301NAME IS NULL2017/05/04(木) 09:47:10.24ID:???
結論だけ言ってて根拠が無ければそれはただの推論

302NAME IS NULL2017/05/04(木) 10:19:56.24ID:???
妄想の可能性も...

303NAME IS NULL2017/05/04(木) 11:07:26.95ID:???
>>287
データ量が多いというのは1億レコードとかそんな単位?
>>282は100万件だったけど、1000万件でも同じだよ。

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

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

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

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

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

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

305NAME IS NULL2017/05/04(木) 11:33:25.73ID:???
>>304
> マジで仕組みを理解してないんだな w
わかるような単語使いましょう。ちゃんと用意されてるんだから。

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

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

306NAME IS NULL2017/05/04(木) 13:11:20.76ID:???
>>305
> カーディナリね。
それを言うならカーディナリティな

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

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

307NAME IS NULL2017/05/04(木) 13:46:35.74ID:???
>>306
> それを言うならカーディナリティな
知ってるなら最初から使おうな。

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

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

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

308NAME IS NULL2017/05/04(木) 14:11:42.70ID:???
脇道の細かい議論しても仕方がないから、論点を絞ろう。

君が主張したいのはこれか?
>>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)」に対してインデックスを貼ることができる
・(蛇足)そこまでするなら、普通にクエリ書け

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

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

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

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

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

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

311NAME IS NULL2017/05/04(木) 17:13:18.38ID:???
なんでBit Map Index Scanになるのが当然のような言い方なんだか。

312NAME IS NULL2017/05/04(木) 17:21:33.21ID:???
>>311
他の方法があると言うなら示してみて

313NAME IS NULL2017/05/04(木) 17:22:38.91ID:???
そろそろ結論出して終わりにしてください
結論がまとまらないなら、両論併記で良いと思います

314NAME IS NULL2017/05/04(木) 17:28:28.15ID:???
お互い相手のことを馬鹿だと思っているなら
馬鹿相手にムキになっている自分を恥じたほうがいいと思うが

315NAME IS NULL2017/05/04(木) 17:48:27.91ID:???
いや既に結論出てるけど理解できない人が食い下がってるだけ

316NAME IS NULL2017/05/04(木) 18:23:25.80ID:???
>>180で答え出てるから後は設計スレでしてくれ
閑古鳥鳴いてるからウェルカムだぞ

317NAME IS NULL2017/05/05(金) 11:22:05.92ID:???
せめて年月から会計年度を返す関数化してくれ

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

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

319NAME IS NULL2017/05/09(火) 13:48:09.40ID:???
ケースバイケース

320NAME IS NULL2017/05/09(火) 13:48:27.88ID:???
>>309
> なぜ使われないんだ?
なぜもクソも使わないんだよ。

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

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

321NAME IS NULL2017/05/09(火) 14:10:30.17ID:???
親切なので、year, monthに個別にindexを張った場合の実行計画を取ってみた。
https://explain.depesz.com/s/UapJ

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

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

322NAME IS NULL2017/05/09(火) 14:24:55.28ID:???
さらにおまけ。

# \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になってますが。

323NAME IS NULL2017/05/09(火) 14:55:26.36ID:???
これにもレスしとこう。

前提として、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

324NAME IS NULL2017/05/09(火) 18:45:08.23ID:???

325NAME IS NULL2017/05/10(水) 10:29:23.99ID:???
>>324
まあ、微粒子レベルで俺が間違ってる可能性があるからな

326NAME IS NULL2017/05/10(水) 10:41:42.84ID:???
>>325
お前が>>323なら、おかしいのはお前の相手の方だから心配すんな
>>268からずっとおかしい
相手するだけ無駄

327NAME IS NULL2017/05/10(水) 10:55:53.42ID:???
今時、コストベースがどうこうとか言う奴だからな。
10年以上前にちょろっとDB触ったレベルの奴じゃね?

328NAME IS NULL2017/05/10(水) 14:06:04.96ID:???
・ストアドにしてオーバーロードしろ
・インデックス使いたいならdate型にしろ
・date型にしないなら個別インデックスにしろ
・Bit Map Indexガー
・ソートガー

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

329NAME IS NULL2017/05/10(水) 17:35:34.21ID:???
今更というかやっと式インデックスが出てくる脱力感

330NAME IS NULL2017/05/10(水) 18:21:15.72ID:???
>>329
式なんか使わずに普通にクエリ書けと何度言ったら

331NAME IS NULL2017/05/15(月) 18:17:10.53ID:/ZtiK+kF
Local and global coordinate system

332NAME IS NULL2017/05/29(月) 23:01:50.19ID:OpaRYJdt
・Postgresql 8.4

・テーブルデータ
|col_a|col_b|col_c
-----------------
name1 1  0
name1 0  3
name2 0 2
name2 0 2
name3 0 3
name3 0 4


・欲しい結果
|col_a|col_b|col_c
-----------------
name1 1  0
name1 0  3
name3 0 3
name3 0 4

・説明
列col_aの文字列が同じで、col_bとcol_cの数値が一致しないタプルを取り出したいのですが
どのようなSQLでいけるでしょうか?よろしくお願いします。

333NAME IS NULL2017/05/29(月) 23:52:29.72ID:???
>>332
SELECT S1.col_a, S1.col_b, S1.col_c
FROM 'テーブル名' S1 , 'テーブル名' S2
WHERE S1.col_a = S2.col_a
AND (S1.col_b <> S2.col_b OR S1.col_c <> S2.col_c)
ORDER BY S1.col_a ;

間違ってたらごめん

334NAME IS NULL2017/05/29(月) 23:57:58.93ID:ppw3vS3C
>>332
グループ化で複数レコードが存在存在するnameを排除すればいい。

335NAME IS NULL2017/05/30(火) 00:12:21.01ID:???
複数レコードが存在するレコードを削除すればよい、ではなくてか。
having count(*) = 1 みたいに。

336NAME IS NULL2017/05/30(火) 00:13:06.46ID:???
削除っていうと聞こえが悪いけど、そこはご勘弁

337NAME IS NULL2017/05/30(火) 14:28:59.06ID:dt3JZxtj
>>332
DISTINCT

338NAME IS NULL2017/05/30(火) 14:35:58.66ID:???
まとめると
SELECT col_a, col_b, col_c FROM テーブルデータ GROUP BY (col_a, col_b, col_c) HAVING COUNT(*) = 1
こうかね?
ORDER BYもいるとは思うけど

DISTINCTは name2 0 2 も1件でちゃうような

339NAME IS NULL2017/05/30(火) 15:13:05.29ID:???
select * from テーブルデータ where col_a in (select col_a from テーブルデータ group by col_a,col_b,col_c having count(*) = 1);

340NAME IS NULL2017/05/30(火) 16:13:29.76ID:???
a,b,c以外にも表示したいときはそうなるか
まあ (a,b,c) in (select a,b,c from 〜 ) とかになるだろうけども

341NAME IS NULL2017/07/11(火) 14:39:34.13ID:VmiHpvub
項目A,B,C,Dの値を入れ替えたいです。
・DBMS名とバージョン:postgreSQL 8.4.13
・テーブルデータ
A B C D
1 2 3 4
1 2 3 4
2 3 4 1
このテーブルのAの値をBに、Bの値をCに、Cの値をDに、Dの値をAに入れたいです。
A B C D
4 1 2 3
4 1 2 3
1 2 3 4
としたいです。

UPDATE TABLENAME SET A = D, B = A, C = B, D = C;
でよいのでしょうか。よい場合、変更する項目数が50位でも大丈夫でしょうか。
検索したところ、2項目の入れ替えはこれでよいようなのですが、
複数(多数)の場合でもよいものか教えていただきたいです。
よろしくお願いします。

342NAME IS NULL2017/07/11(火) 14:42:47.22ID:???
>>341
それでいい

343NAME IS NULL2017/07/12(水) 02:12:00.48ID:???
>>342
ありがとうございました。自信を持って(?)作業します。

344NAME IS NULL2017/07/12(水) 05:24:51.54ID:???
え、BにDの値入らない?大丈夫?

345NAME IS NULL2017/07/12(水) 10:20:42.90ID:???
>>344
大丈夫

updateが完全に完了するまでは古いレコードは残っていて(そうしないとrollbackできない)、
>>341のクエリは、更新前のレコードをold、更新後のレコードをnewとするなら、
UPDATE TABLENAME SET new,A = old.D, new,B = old.A, new,C = old.B, new,D = old.C
というような処理が行われる

3463412017/07/12(水) 12:30:52.13ID:???
レスありがとうございます。
>>344 >>345
検索して調べたときに知ったのですが、
postgreSQL,SQLserver,おそらくoracleは大丈夫。
MySQLは、左から順に評価するので、たぶんBはDの値になるようです。
みなさん一時項目を使ったり、足し算引き算をしたりして工夫されているようです。

347NAME IS NULL2017/07/12(水) 14:25:49.61ID:???
mysqlは(1,2,3,4) -> (4,4,4,4)になるよ
クソ

348NAME IS NULL2017/07/12(水) 14:36:41.10ID:???
え、SQLってこの程度のことも規約で決まってなかったのか

349NAME IS NULL2017/07/12(水) 19:37:23.75ID:???
>>345
>>346
質問者じゃないけど、参考になる例題でした。

350NAME IS NULL2017/07/12(水) 21:55:04.69ID:???
一時テーブルを作成して、更新後の並びになるようにコピーする
元テーブルのレコードを削除して、一時テーブルからコピーする

なんてやるのはどうなんだろう?

create temporary table tmp select d as a,a as b, b as c, c as d from TABLENAME;
delete from TABLENAME;
insert into TABLENAME select * from tmp;

351NAME IS NULL2017/07/13(木) 05:58:18.91ID:???
【テンプレ】
・DBMS名とバージョン : mysql Ver 14.14 Distrib 5.1.73,
・テーブルデータ : 添付画像をご覧ください
・欲しい結果 ; 添付画像をご覧ください

http://fast-uploader.com/file/7055447564296/

・説明

※添付画像では、col1被り数の1行目(セル番地で言うとおB5セル)を例に取っています)
※添付画像の、数式表示欄を見ていただますようお願いいたします。(Excelの式が入っております。)

DB上にテーブルがあり、code1、code2、code3と列があります。
code1、code2、code3の、全ての行の「どこか」でデータが被っています。被っていない所もあります。
被っているのは、同一列だったり、別の列の違う行だったり、はてまて、同じ行の別の列だったり様々です。

これを、col1被り数、col2被り数、col3被り数のように、「被ってる行」をカウントしたいんですが、
方法がさっぱり思いつきません。


何卒ご教示くださいますよう、お願いいたします。

3523412017/07/13(木) 13:19:26.70ID:???
>>350
SQLが通るかどうかは置いといて、結果の並び順は保証されていないので
キーを使うなどしないと「たまたま」動作したということになると思います。

353NAME IS NULL2017/07/13(木) 16:49:04.18ID:???
>>351
元テーブル名が分からなかったので、partsと仮定した

http://ideone.com/wZK0bA

354NAME IS NULL2017/07/13(木) 19:57:15.52ID:???
>>352
「列の」並び順の話だろ

355NAME IS NULL2017/07/13(木) 20:46:37.04ID:???
>>353
ありがとうございます!印刷して家宝にします!!!

3563412017/07/14(金) 01:19:55.97ID:???
>>354
列の並び順を替えるにしても、行の順が元テーブルと違っちゃうかも
しれませんよという話です。
キーの部分を書くのが面倒で省略したということかもしれません。

357NAME IS NULL2017/07/14(金) 01:28:39.43ID:???
行の順序が変わったとしても、それが何か影響を与えるとは思わないんだが

3583412017/07/14(金) 09:16:50.89ID:???
>>357
なるほど了解。

359NAME IS NULL2017/07/14(金) 10:11:57.35ID:???
mysqlならストアドだろうな

360NAME IS NULL2017/07/16(日) 03:19:50.47ID:???
初めてVPSで構築しています。
MySQL設定でハマってます。

Pleskだと/etc/my.cnfや/etc/php.d/mysql.iniは無視されるのでしょうか?
my.cnfに書いてみたんですが、どうも反映されてないようです。

MySQLTunerを実行してみると
failed to execute: SELECT VERSIONのようなのが鬼のように表示され、
General recommendationsに下記のように表示されてます。

query_cache_size (=0)
query_cache_type (=0)
query_cache_limit (> 1M, or use smaller result sets)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
thread_cache_size (start at 4)
table_open_cache (> 400)
performance_schema = OFF disable PFS
innodb_file_per_table=ON
innodb_log_file_size * innodb_log_files_in_group should be equal to 1/4 of buffer pool size (=64M) if possible.

(=0)は0にしなさい。
(> 1M)は1MB以上に指定しなさい。
それに合わせてmy.confに入れてみたんですが、
これが全く変わりません。

361NAME IS NULL2017/07/16(日) 10:22:53.35ID:???
straceしてみてどの設定ファイル読んでるか確認してみたら?

362NAME IS NULL2017/07/17(月) 08:19:42.44ID:???
久しぶりに来た半初心者なのですが、上の方の議論で出てた会計年度の話は、単に引き算を利用してはいけなかったんでしょうか

4ヶ月引いて1日足して、としてやれば安定して通常年度に戻せる気がするのですが

363NAME IS NULL2017/07/17(月) 10:26:23.55ID:ELQvIlPL
日付から年度を求めたい、という話?
そういうのでもいいけどそれ間違ってるからね

364NAME IS NULL2017/07/17(月) 10:28:40.66ID:???
どの話をしようとしているのか分からん

4ヶ月引いて1日足すというだけでも
30日に1日足したら31日になるのか1日になるのかどう判断するんだ?

365NAME IS NULL2017/07/17(月) 10:39:33.34ID:???
>>363
ほんとだ
なんで足す1出てきたし4なんですかね

なんにせよありがとう

366NAME IS NULL2017/07/23(日) 12:32:38.73ID:???
例えば、左から右に行って、
途中でジェイってなって、そのまま終わったらいいかと思うんですが。
新しいSQLの概念というか。

367NAME IS NULL2017/07/23(日) 15:48:13.53ID:???
>>386が何を言ってるのかさっぱり判らぬ

368NAME IS NULL2017/07/23(日) 15:48:48.68ID:???
間違えた。 >>386じゃなく>>366だった^^;

369NAME IS NULL2017/07/23(日) 16:38:22.44ID:???
大丈夫、俺も分からん

370NAME IS NULL2017/07/23(日) 16:58:56.49ID:???
RDBMS使ってRPG作ろうとしているのかな?

371NAME IS NULL2017/07/23(日) 19:13:31.67ID:ic0ZKVtq
月末日なんて翌月の1日前なのになw

372NAME IS NULL2017/07/23(日) 19:42:03.08ID:???
>>371
その翌月の日が1日だったらな

373NAME IS NULL2017/07/23(日) 19:49:11.25ID:???
>>372
は?

374NAME IS NULL2017/07/23(日) 21:05:31.62ID:???
>>372
月末の次の日が1日じゃないケースってなに?

375NAME IS NULL2017/07/23(日) 21:59:12.88ID:???
>>371の言う「翌月の1日前」が「翌月の1日の1日前」という意味なら、ってことだろ。

376NAME IS NULL2017/07/23(日) 22:36:23.90ID:???
7月23日の翌月の1日前は8月22だろjk

377NAME IS NULL2017/07/23(日) 22:46:18.66ID:???
おまえ、そんな頭のレベルでよくSQL云々出来るなぁ

378NAME IS NULL2017/07/23(日) 23:25:31.06ID:???
IPAの試験が、読解力を試されるような問題だらけになるわけだ。

379NAME IS NULL2017/07/23(日) 23:40:56.92ID:???
営業日の話ししてんじゃないのか

380NAME IS NULL2017/07/24(月) 00:34:13.18ID:???
複数の同一形式のcsvからデータを読み取る時、普通は↓こんな風に定義するけど、

[001.csv]
[002.csv]
[003.csv]
Col1=F1 Char Width 255
Col1=F2 Char Width 255

ユニオンで縦連結する時は、↓こうじゃないと定義内容が反映されない。

[001.csv]
Col1=F1 Char Width 255
Col1=F2 Char Width 255

[002.csv]
Col1=F1 Char Width 255
Col1=F2 Char Width 255

[003.csv]
Col1=F1 Char Width 255
Col1=F2 Char Width 255

何で?

381NAME IS NULL2017/07/26(水) 22:15:23.65ID:???
・tableA
日付、名前、国語、算数、英語
5/1 赤木 100、100
5/1 三井 50、70
5/1、桜木、40、20

6/1 赤木 100、100
6/1 三井 50、50
6/1、桜木、20、40

7/1 赤木 100、100
7/1 三井 70、70
7/1、桜木、50、50

・tableB
採点開始日、名前 
7/1、桜木
5/1、赤木
6/1、三井

・採点平均
名前、国語平均、英語平均
赤木 100、100
三井 60、60
桜木 50、50


↑のテーブルAのデータを
テーブルBの採点開始日からの採点平均をだしたい
↓で大丈夫だろうか? あらかじめJoinしておいたほうがレスポンス的にはよいのかな?

SELECT tableA.名前,AVG(tableA.国語)AS 国語平均,AVGtableA.英語)AS 英語平均
FROM tableA,tableB
WHERE tableA.日付 >= tableB.採点開始日
AND tableA.名前,tableB.名前

382NAME IS NULL2017/07/26(水) 22:18:02.28ID:???
>>381
tableA は
日付、名前、国語、英語
です。

383NAME IS NULL2017/07/26(水) 22:38:14.43ID:???
>>381

SELECT tableA.名前,AVG(tableA.国語)AS 国語平均,AVG(tableA.英語)AS 英語平均
FROM tableB
inner join tableA
on tableA.日付 >= tableB.採点開始日
AND tableA.名前=tableB.名前
group by tableA.名前
でいいんじゃないかな

384NAME IS NULL2017/07/26(水) 22:55:56.85ID:???
>>383
ありがとうございます
join したほうがいいのかな
これを参考にしてやってみます。

385NAME IS NULL2017/07/27(木) 11:16:31.96ID:???
>>384
データ量はたぶんたかだか数万レコード程度だろうから、どんなやり方でもパフォーマンス的には気にする必要ないと思うよ

386NAME IS NULL2017/07/27(木) 21:34:59.28ID:???
>>383
横からだが、fromとwhereで結合しても、joinで結合しても
書き方が違うだけで同じだぞ

パフォーマンス気にするなら、使ってるDBMSの実行計画読めるようにならないと
事前に結合した実データ(のテーブルやビュー)用意するんじゃなければ
SQLの書き方では差がでないのが原則

387NAME IS NULL2017/07/27(木) 22:17:49.93ID:Wb6w4MLZ
じじいが嘘を広めていることもあるから混乱するんだよな。

388NAME IS NULL2017/07/27(木) 22:31:45.92ID:???
tableAのデータがあった場合、tableBの結果と、tableCのビューが欲しいです。
tableAの補習が入った場合は学校にいくまでの間はすべて補習の時間になります。
まったく書き方が見当がつかないのでアドバイスお願いします

tableA
時間、学校、部活、補習

2017/6/1 06:00:00、NULL、OK、NULL
2017/6/1 07:00:00、NULL、OKL、NULL
2017/6/1 08:00:00、OK、NULL、NULL
2017/6/1 09:00:00、OK、NULL、NULL
2017/6/1 10:00:00、OK、NULL、NULL
2017/6/1 11:00:00、OK、NULL、NULL
2017/6/1 12:00:00、OK、NULL、NULL
2017/6/1 13:00:00、NULL、OK、OK
2017/6/1 14:00:00、NULL、OK、NULL
2017/6/1 15:00:00、NULL、OK、NULL
2017/6/1 16:00:00、OK、OK、NULL
2017/6/1 17:00:00、OK、NULL、NULL
2017/6/1 18:00:00、NULL、OK、NULL
2017/6/1 19:00:00、NULL、OK、NULL
2017/6/1 20:00:00、NULL、OK、NULL
2017/6/1 21:00:00、NULL、OK、NULL

tableB
時間、活動

2時間、部活
5時間、学校
3時間、補習
2時間、学校
4時間、部活

tableC
時間、活動

7時間、学校
6時間、部活
3時間、補習

389NAME IS NULL2017/07/27(木) 22:40:11.70ID:???
他人にわかる説明ができるようになったら解決するんじゃないかな。

390NAME IS NULL2017/07/27(木) 22:56:18.00ID:???
>>388
tableBとtableCはビューB,、ビューCをだしたいに訂正します。
ビューCはビューBの部活、学校、補習の合計時間をだします。

tableA は1時間間隔で 活動した予定にOKが付きます

6時と7時は部活をやっているので2時間になります。
そのあと学校が5時間

その次は部活と補習がOKになっていますが
補習がOKなったら、学校がOKになるまで補習の時間なので
補習が2時間になります。

この流れで↓の結果が欲しいです。

ビューB
時間、活動

2時間、部活
5時間、学校
3時間、補習
2時間、学校
4時間、部活

ビューC

7時間、学校
6時間、部活
3時間、補習


SQLだけで書くのは見当がつかないのでアドバイスお願いします。

391NAME IS NULL2017/07/27(木) 23:04:51.56ID:???
SQLだけで書けないと思ったのにSQLスレなのか
DBだけでやれない想定として、どういう風に実装予定なの?
ざっくりでいいからさ(Java使って、とかWindows上でとか)

392NAME IS NULL2017/07/27(木) 23:33:31.06ID:???
SQLだけでできるかわからないので質問しました。
今回のような内容はSQLでやるべきではない?SQLでできてもものすごくめんどくさい?
の状態です。似たような内容を何件か取得したいと思っているのでしりたいです。

SQLだけでビューB、ビューCをだせるなら、Windows上のアプリ でそれを取得してCSVデータにするのが簡単だと思っています。

SQLだけで無理ならtableAのデータからCSVデータを作成のつもりです。

393NAME IS NULL2017/07/27(木) 23:42:29.20ID:???
ビューとして取る必要があるの?
画面に表示したいとか?
取得したデータをそうしたいの?

394NAME IS NULL2017/07/27(木) 23:50:08.71ID:???
ビューとして取れるようにしておけばそのままCSVにだすだけで簡単なのと、
画面に表示したいと思っています。
取得したデータの操作は考えていません。

395NAME IS NULL2017/07/27(木) 23:50:42.81ID:???
データが絶対に1時間間隔で抜けはないってならSQLだけでできるんじゃね

俺ならBはtableA を時間でソートして、ホストアプリでブレークチェックしながらカウントして表示するけどな

396NAME IS NULL2017/07/28(金) 00:01:52.52ID:???
>>388
は1時間間隔でなっていますが
秒単位で間隔は一定ではないです。
すみません。

Windows上のアプリはあまり動作増やしたくないなと思っていたんですが
SQLだけでやろうとすると
大変?って感じなのかな

397NAME IS NULL2017/07/28(金) 08:06:19.46ID:???
普通データベースの動作を増やさないように工夫すべきなんだけどな

398NAME IS NULL2017/07/28(金) 08:09:22.13ID:???
> は1時間間隔でなっていますが
> 秒単位で間隔は一定ではないです。
意味不明だし後出しフラグ立ってるしすまんが抜けさせてもらうわ

399NAME IS NULL2017/07/28(金) 09:06:32.50ID:???
最初からずーっと意味不明だったな

400NAME IS NULL2017/07/28(金) 11:05:37.51ID:IsxTOLxk
>>396
初心者か?SQLは呪文ではない。

401NAME IS NULL2017/07/28(金) 11:06:54.25ID:IsxTOLxk
ロジックを隠蔽すると軽くなる理屈が不明

402sage2017/07/28(金) 13:06:18.42ID:UiVRAQM3
mdbファイルをDSNで一般に公開する方法を教えてください。
perl公開ならiisを使えばよいことは分かります。
pdf公開ならftpサーバを使えばよいことは分かります。
mdbファイルはiisを使って公開できるのでしょうか?
iisには接続文字列の設定がありますが意味が分かりませんでした。
odbcad32.exeはネットワーク越しは無理みたいでしたし。
ACCESSというお高いソフトにはmdbファイルを公開できる
サーバ機能が含まれているのでしょうか?

403NAME IS NULL2017/07/28(金) 13:09:57.81ID:???
>>402
データベース(ファイル)を一般公開してはいけません

404NAME IS NULL2017/07/28(金) 17:22:29.53ID:IsxTOLxk
公開って何?

405NAME IS NULL2017/07/28(金) 17:34:26.21ID:???
mdbはファイル共有型だから
そのmdbファイルをファイル共有できるようにすればOK

とレスしてみたけど
そのレベルで一般に公開するのはやめとけ

406NAME IS NULL2017/07/28(金) 18:01:40.86ID:IsxTOLxk
答えてる方も何をいってんのかw

407NAME IS NULL2017/07/28(金) 19:15:12.26ID:???
共有はいいけど公開はダメってだけでしょ

408NAME IS NULL2017/07/28(金) 21:58:07.64ID:???
さすがにイントラでってことなんだろうけど、それでも公開はまずいっしょ

409NAME IS NULL2017/07/28(金) 22:35:23.73ID:UiVRAQM3
漏れをそのレベルとしか見れない人よりはレベル高いと思ってる。
ここまで6件のレスがついたが誰人答えを知らないほどレベルの高い質問をしてしまった。
漏れよりレベルの高い人を待つ。
合計7人が回答をお待ちしています。

410NAME IS NULL2017/07/29(土) 00:45:43.29ID:???
>>409
とりあえず2chで質問とかアホなことしてる時点で低レベルやぞ?

411NAME IS NULL2017/07/29(土) 01:12:28.22ID:HlUqV4Yy
分かっておる。しかしそんな漏れよりももっとレベルの低い人が見つかった気がして
ちょっとうれしくなった。
あんたも答える知識の無い低レベルだな。
FileMaker入れて漏れは今解決したよ。
7人の戦士のうち結果的に漏れが一番レベルが上になったようだ。
ばいばい。

412NAME IS NULL2017/07/29(土) 01:45:14.92ID:???
低いレベルというか専門性が違うだけでしょ
SQLスレで聞くのも違う気がするし

413NAME IS NULL2017/07/29(土) 01:51:03.66ID:???
聞けるスレがないと言うのも気の毒だったけど
しかし、もっと違うアプローチをすべきだとは思った

414NAME IS NULL2017/07/29(土) 02:02:41.39ID:???
MDBファイルはADOを使ってPHPからアクセス出来るので
IIS上で上手くやればWebサイトとして構築出来るんじゃないかな?

415NAME IS NULL2017/07/29(土) 05:31:07.27ID:wCmqTHAL
彼はデータのを表示させるためなら、どんな方法でもよいとしか言ってないぞ?

416NAME IS NULL2017/07/29(土) 05:37:16.37ID:wCmqTHAL
FTPでファイル転送してるらしいから、mdbファイルを渡せばいいんじゃないのか?

417NAME IS NULL2017/07/29(土) 12:18:07.93ID:???
初心者てレベル争い好きだなw

418NAME IS NULL2017/07/30(日) 00:15:18.39ID:???
>>414
Webサイト構築したいとか言う話じゃないし、それが出来るレベルの人間の質問でもないけど

>>415
彼って誰だよ
表示出来ればどんな方法でもいいとか誰がいってるの?

mdbをDSNで直接指定できるようにするにはファイル共有でアクセスできるようにすればいい
それを一般に公開するかどうはやる奴が決めればいい

419NAME IS NULL2017/07/30(日) 00:24:21.99ID:???
>>418
でも、iisやftpの話を出してきてるし
一般に公開する方法ってことだから
内容を表示出来れば要件は満たしそう

420NAME IS NULL2017/07/30(日) 16:59:29.66ID:J2rDve9a
>>402 は何を公開するとも言ってない。

Perlのスクリプトを公開するのもコードを公開するとも受け取れる。

PDFファイルはなぜかFTPでダウンロードさせてるあたりから、助言する段階の情報がまだない。

421NAME IS NULL2017/07/30(日) 17:45:16.01ID:???
PostgreSQLでいうと、port 5432をインターネットに公開したいってことでしょ

422NAME IS NULL2017/07/30(日) 22:13:58.56ID:???
>>420
>mdbファイルをDSNで一般に公開する方法を教えてください
って言ってるけど?

423NAME IS NULL2017/07/30(日) 23:15:07.79ID:???
文盲かな?

424NAME IS NULL2017/07/31(月) 00:05:16.94ID:???
ここのスレは>>411にとって
>漏れよりももっとレベルの低い人
の集まりで
>答える知識の無い低レベル
らしいから、そんなのこちらが考えるだけ無駄

425NAME IS NULL2017/07/31(月) 04:43:26.66ID:lcWS9MWM
WebブラウザでAccessの画面を開きたいレベルの話だと思うけどな。

PDFファイルをローカルで開いていることもわからないくらいだから。

426NAME IS NULL2017/08/03(木) 21:28:57.05ID:UD0thFWN
すいません質問です
記事テーブルとカテゴリテーブルがあるのですがそれぞれのID部分を post_id category_id とするのか、単に id とするのかどちらがいいでしょうか?

427NAME IS NULL2017/08/03(木) 23:04:48.93ID:???
ネーミングの問題?自分で作ってるものなんだろうけど、3ヶ月後の自分は他人なんだから、そんなしょーもないところで
手を抜かずにちゃんとした名前、この場合ならpost_ , category_ 等々にしたら?

428NAME IS NULL2017/08/03(木) 23:11:37.36ID:WNAOpieS
>>426
そのIDが同じものでないなら、ただのIDという名前はやってはいけないレベルの命名。

429NAME IS NULL2017/08/03(木) 23:15:52.36ID:???
作った当初は覚えているだろうけど
何年か経ってSQLソースを見た時に

「このidってなんだったっけ?」

てことになる

430NAME IS NULL2017/08/03(木) 23:41:59.58ID:WNAOpieS

431NAME IS NULL2017/08/03(木) 23:42:49.91ID:???
>>428
そうでもない

432NAME IS NULL2017/08/04(金) 00:16:01.81ID:???
普通にidでええやろ
category.category_idとかアホみたいやん

433NAME IS NULL2017/08/04(金) 00:26:25.00ID:???
>>432
これ

434NAME IS NULL2017/08/04(金) 00:27:50.41ID:???
デフォルトは主キーがIDのフレームワークもある時代に何言ってんだか

435NAME IS NULL2017/08/04(金) 00:40:24.77ID:lQ2EAqCJ
>>434
データベースに詳しくないのが無茶苦茶なことをやるんだよな。

436NAME IS NULL2017/08/04(金) 00:41:55.38ID:lQ2EAqCJ
ナチュラルジョインも知らないのが設計するとそうなる。

4374262017/08/04(金) 01:06:51.92ID:ps9NmLsK
皆様ありがとうございますm(_ _)m
idは他のテーブルでも使用されるので post_id などに統一しようと思います

438NAME IS NULL2017/08/04(金) 14:36:14.96ID:???
どんなテーブルだろうが id は id やろ?
テーブル見ればなんの id か分かるだろ?
アホはアホなとこに神経使うんだな(笑)

439NAME IS NULL2017/08/04(金) 16:26:24.86ID:???
maker.code (PK)
product.code (PK)
設計はともかくこういう命名規則も許せないのか、気になるところね

440NAME IS NULL2017/08/04(金) 16:39:09.84ID:???
id列にも名前に修飾詞をつけておくとusing句が使いやすいというメリットがあるんやで
なんでも原理原則に従うのがいつも最良の方法とは限らんのや

441NAME IS NULL2017/08/04(金) 16:53:10.36ID:???
テーブル以外のidも意識しろって話でしょ
全部idだとどこの何のidか意識する必要あるし、外部キーとしてidが多々あるとNGだね

442NAME IS NULL2017/08/04(金) 17:25:24.36ID:???
テーブル名指定したらいいだけやん

443NAME IS NULL2017/08/04(金) 17:32:23.63ID:???
>>442
だよね

444NAME IS NULL2017/08/04(金) 18:30:50.02ID:sgWQZKSP
ナチュラルジョインも知らないのが設計するとそうなる。

445NAME IS NULL2017/08/04(金) 18:43:29.71ID:???
>>444
最近覚えた言葉を使いたがるやつっているよね

446NAME IS NULL2017/08/04(金) 18:48:16.83ID:sgWQZKSP
同じカラム名で意味の異なる属性は、RDBではないな。そのテーブルの主キーではあるが、業務上、意味がない値を格納するだけだとしてもよろしくない。MS-Accessの古い慣習の影響か。

447NAME IS NULL2017/08/04(金) 19:00:50.99ID:???
あのさぁ、1プロジェクトで数百以上のテーブルとか普通にあるんだけど、それぞれユニークなカラム名付けるのか?

448NAME IS NULL2017/08/04(金) 19:02:00.80ID:???
>>446
おまえ独特なRDBの定義だな(笑)

449NAME IS NULL2017/08/04(金) 19:07:45.32ID:sgWQZKSP
カラム名が同じなら、その項目同士にリレーションシップがあると考えるのが標準SQL。

450NAME IS NULL2017/08/04(金) 19:42:37.61ID:???
>>449
はっ?
そんな仕様にはなっていない

451NAME IS NULL2017/08/04(金) 19:47:30.11ID:lQ2EAqCJ
>>450
リレーションシップは外部キー制約があるかどうかではない。

452NAME IS NULL2017/08/04(金) 19:59:03.73ID:???
>>449
ソース

453NAME IS NULL2017/08/04(金) 19:59:47.03ID:???
>>446
どこの世界の話だよ

454NAME IS NULL2017/08/04(金) 20:20:01.75ID:lQ2EAqCJ
関係リレーショナルデータベース

455NAME IS NULL2017/08/04(金) 20:20:50.75ID:lQ2EAqCJ
関係データベース

456NAME IS NULL2017/08/04(金) 21:08:11.33ID:???
>>442
て言うか単一テーブルだけでないなら普通そうするよね

457NAME IS NULL2017/08/04(金) 21:42:18.25ID:???
テーブル名指定するなら、テーブル名をコラム名の一部に使うのと同じ事になる

458NAME IS NULL2017/08/04(金) 23:18:24.74ID:???
考え方の違いだな。
テーブルはエンティティを表すとするならカラムはその固有の属性だが、もともとのリレーショナルモデルでは
先に属性があってその関係をリレーション(テーブル)として表すわけなんで、同じ属性が異なる複数の
リレーションに含まれ得る。

459NAME IS NULL2017/08/04(金) 23:40:12.87ID:???
>>457
ならねーよ

460NAME IS NULL2017/08/05(土) 01:35:30.52ID:???
すみません、SQLの実行の順番ってどうなってるのですか?

select
hoge
from
tableA
inner join (...) subQuery1
on(...)
inner join (...) subQuery2
on(...)
みたいなsqlがあるとき、どのどこから実行されるのですか?

461NAME IS NULL2017/08/05(土) 06:36:08.94ID:MeRXBAvD
>>460
質問がおかしい

462NAME IS NULL2017/08/05(土) 07:34:03.19ID:???
from→where→group by→having→select→union等→order by
の順に実行したかのような結果になる(from内のjoinは左から)
内部動作として実際にこの順で実行しているかはまた別の話

463NAME IS NULL2017/08/05(土) 07:42:50.82ID:MeRXBAvD
>>462
そういう説明はやめた方がいい。

464NAME IS NULL2017/08/05(土) 08:14:28.45ID:???
いや、必要な知識だと思うが。

465NAME IS NULL2017/08/05(土) 08:51:33.75ID:MeRXBAvD
>>464
彼の質問はインランビューだと思う。

466NAME IS NULL2017/08/05(土) 09:21:04.88ID:???
サブクエリもfrom句の内なんだからそのように解釈すればいいだろう。そもそも何を問題にしているのかわからん。

>>460の質問はおかしい
>>460の質問はインラインビューについて聞いている
>>460の質問はインラインビューについて聞いているが質問がおかしい

どれ?

467NAME IS NULL2017/08/05(土) 09:30:25.17ID:MeRXBAvD
>>466
初心者なんだから、そんなのあたりまえだということがわからない。

話をすっとばしてはいけない。

468NAME IS NULL2017/08/05(土) 09:55:24.27ID:???
その「あたりまえ」は>>462の知識を前提にしているんだから順序はそれでいいんだよ。何をすっとばしたって?
それにそもそも、>>460がそのあたりまえのことを理解できない初心者だと決めつけるのもおかしいだろう。

一連のレスを見返してみると、お前は中身のないケチをつけるしか能がないのか?しかも支離滅裂。

469NAME IS NULL2017/08/05(土) 10:40:13.77ID:???
>>465
淫乱ビュー!?

4704652017/08/05(土) 11:06:11.75ID:???
すみません。SQL初心者なのにここで質問してしまいました。
知りたかったことは下記のようなことです。

subQuery1,2はTableAを別名化したものです。subQuery内にはそれぞれwhere条件があります。

subQuery1内のwhere句のregist_dateが2017/08/04between2017/08/05

subQuery2内のwhere句のregist_dateが2000/01/01between2017/08/05


このとき、subQuery2内のwhere句には、2017/08/04~2017/08/05のフィルタがかかった状態で検索されるのですか?
それともフィルタがかからない状態で検索され、2000/01/01~2017/08/05までの全レコードが検索され、
その上で内部結合の結合条件のレコードが抽出されるのですか?

471NAME IS NULL2017/08/05(土) 11:48:15.87ID:???
概念的には各サブクエリは独立して実行されると考えてよいが、
それをjoinした結果からは区別がつかん場合もある。
もちろん実際の実行順序は別の話。

472NAME IS NULL2017/08/05(土) 14:00:31.63ID:MeRXBAvD
>>470
同じSELECT文の中で同じテーブルを検索したら、それはそれで結果のビューができるという考え方でよい。

RDBMSによって内部の実装は異なるし、データの統計情報によっても処理方法は異なる。

473NAME IS NULL2017/08/05(土) 14:05:36.05ID:MeRXBAvD
>>470
内部結合だから結合条件によっては、同じ結果になるか、初心者にありがちな検索結果からSQLが正しいかどうかを確認してるのか?

474NAME IS NULL2017/08/06(日) 11:03:43.07ID:???
日本語下手な奴は迷惑

475NAME IS NULL2017/08/06(日) 11:09:38.00ID:???
外国人に日本語を下手なのを納得です

476NAME IS NULL2017/08/10(木) 17:31:03.03ID:???
SQL初心者のスレが無いorz
mysqlですがちょっと教えて下さい
table nulltest
id int primary key,
price1 int not null,
a__price1 int default null
というテーブルで

a_price1がnullでないならそれを採用、
a_price1がnullならprice1を採用
id price1 a_price1
1 , 10 , 8
3 , 122 , 100
10 , 10 , null
とあるなら
1 , 8
3 ,100
10, 10
と出したい。SQLで出来ませんか?

477NAME IS NULL2017/08/10(木) 20:25:08.56ID:???
インジェクション扱いされて
SQL文、書き込めない。

478NAME IS NULL2017/08/10(木) 20:27:07.56ID:???
>a_price1がnullでないならそれを採用、
>a_price1がnullならprice1を採用

coalesce(a__price1,price1) as a_price1

全角を半角に直して

479NAME IS NULL2017/08/10(木) 20:45:02.52ID:???
>>478

その引数を最初から評価して最初にNULL値でない引数を返す

ということで最初にa__price1を持ってくるということですか。
ありがとうございます

480NAME IS NULL2017/08/11(金) 10:43:48.97ID:b98NF32s
>>479
彼は関数を使えと言ってるけど、CASE式でもいいけどな。

481NAME IS NULL2017/08/11(金) 23:37:00.76ID:???
476です。あ〜、case式ですか

case when a_price1 is null then price1 else
a_price1 end as a_price1
でも出来ました。ありがとうございます。

482NAME IS NULL2017/08/19(土) 02:13:10.41ID:???
IDEなんかに出てくるフォルダがスキーマってやつだよね?
でテーブルがあると
スキーマとテーブルの間のフォルダみたいな奴はなんなの?

483NAME IS NULL2017/08/22(火) 12:29:00.59ID:???
スキーマとテーブルの間のやつだろ論理的に考えて

484NAME IS NULL2017/08/22(火) 12:57:26.72ID:c5XGebwI
>>482
どのRDBMSかわからないが、GUIのツールによっては、他のユーザーのスキーマ、データベースオブジェクトがぶら下がっているかのように見えるものがある。

485NAME IS NULL2017/08/24(木) 21:53:48.44ID:???
ExcelでWith使いたいんですけど、何とかなりません?
もちろん、With〜End WithのWithじゃなくて、SQLのWithです。

486NAME IS NULL2017/08/24(木) 22:39:48.52ID:BMRgLesK
>>485
その説明では何を言ってるのかわかりません。

487NAME IS NULL2017/08/25(金) 00:27:12.49ID:???
>>485
vbaか?

488NAME IS NULL2017/08/25(金) 02:54:28.48ID:???
temp table的な使い方のWITH句について言ってるんだと思うけど
DBサーバー、DBドライバ、実際のクエリ、この辺りの情報そろえて
DB製品スレかExcelスレで聞いたほうがいい

489NAME IS NULL2017/08/25(金) 15:58:24.67ID:???
>>485
With B

490NAME IS NULL2017/08/25(金) 17:47:25.62ID:???
>>485
日本語の勉強やり直したら?

491NAME IS NULL2017/08/25(金) 20:09:29.64ID:t92cdcnK
ネット上でよく見かける困ったバカの特徴

自分が理解出来ないとすぐに相手の言語能力不足を指摘する(しかも割と本気)

492NAME IS NULL2017/08/25(金) 21:46:33.91ID:PpXsPpW0
>>491
仮定での回答ほどたいへんなものはない。

493NAME IS NULL2017/08/25(金) 22:44:29.27ID:???
>>486
>>487
いや、485にも書きましたけど、SQLのWithですって。
VBAのWith〜End WithのWithじゃないです。

>>488
そのWithです。
Excelスレって、そっちの人達じゃわからないですよ。
あと、DBサーバーとかDBドライバって、
使えるかどうかは、それに依存するんですか?

494NAME IS NULL2017/08/25(金) 22:47:33.44ID:???
WITHなら分かるけどWithは分からないにゃあ

495NAME IS NULL2017/08/25(金) 22:52:13.60ID:???
>>494
!?
SQLって小文字使えるでしょ!?
少なくともExcelなら、SelectとかFromとか、小文字使えますよ。

496NAME IS NULL2017/08/25(金) 23:42:02.08ID:???
>>493
お前、>>1も読めないバカか?

497NAME IS NULL2017/08/25(金) 23:44:55.40ID:???
>>485
相手のDBMSによるので最低限何のDB使ってるのか書け
接続方法等によってSQLの発行方法が微妙に違うからそれも書け

498NAME IS NULL2017/08/25(金) 23:52:02.00ID:???
自分が分かっていない事を分かっていないんだろうから何を言っても無駄

499NAME IS NULL2017/08/25(金) 23:58:49.33ID:???
>>498>>497あてです

500NAME IS NULL2017/08/26(土) 00:09:13.03ID:???
ネズミをいたぶる猫を連想してしまった

501NAME IS NULL2017/08/26(土) 00:15:40.58ID:???
>>493
推測するに、ODBCかなにか使って、外部のDBを扱いたいのだろうと思う
その場合、外部のDBが何であるか、例えばOracleとかMySQLとか
そして、そのDBに対してどのような接続方法をするか、
質問する際にそういう情報として出さないと、誰も回答しようがないと思う
Withが使えるかどうかは、相手次第

502NAME IS NULL2017/08/26(土) 00:15:43.45ID:???
ネズミをいたぶる猫を見て笑ってる人がいるときいて

503NAME IS NULL2017/08/26(土) 00:34:58.63ID:???
>>493
ExcelスレってのはExcelのVBAスレな

>使えるかどうかは、それに依存するんですか?
依存する場合もあるし、君が何か間違えてる可能性もある
そもそもサーバー側がサポートしてないケースだってあるだろ
エラーが出てるならそのエラー内容も含めて関連スレで聞きな
SQLの文法でエラーになってるならここで聞けばいいけど

504NAME IS NULL2017/08/26(土) 00:39:32.94ID:???
お前らの優しさを見習いたい

505NAME IS NULL2017/08/26(土) 00:41:09.46ID:???

506NAME IS NULL2017/08/26(土) 01:06:14.63ID:SWywwfsW
ExcelのシートにADOで繋いでクエリかけたいとかなら無理だぞ
VBA使ってるなら文字列生成を工夫して省力化できるかもしれんが。
ちなみにWITH句もしくはCTE(Common Table Expressions)といったほうが通じる

507NAME IS NULL2017/08/26(土) 12:21:03.06ID:???
>>501
完全に間違った推測ワロタw
しゃべるなバカw

508NAME IS NULL2017/08/26(土) 12:23:51.10ID:xlgNQVZl
>>507
おまえ、質問者だろ?

前もそういう態度だったよな?

509NAME IS NULL2017/08/26(土) 12:26:29.08ID:???
>>508
違うわw
質問に群がる教えたがりのバカを笑ってるだけだw
お前みたいなバカなw

510NAME IS NULL2017/08/26(土) 13:11:07.10ID:???
煽りは無視して

511NAME IS NULL2017/08/26(土) 14:00:41.66ID:???
>>845が情報を出さない以上無意味

512NAME IS NULL2017/08/26(土) 14:47:34.48ID:???
まあ確かにこの質問者は態度悪いな

513NAME IS NULL2017/08/26(土) 18:30:27.89ID:???
「態度」じゃなくて「頭」な

514NAME IS NULL2017/08/26(土) 19:51:42.90ID:???
>>497
>>501
相手方は、AccessかExcelかCsvです。
接続方法は、MsQueryかADOしか分かりません。

>>503
そのExcelのVBAスレなんですけど、
そっちは、普通の使い方をする人がメインで、
SQLとかWindowsAPIとか、マイナーなのはあんまり話が通じない・・。

ここも、WithがSQLのWithだとわからないで攻撃してくる人がいましたけど、
あっちはもっと酷いです。

>>506
無理なんですか・・。
ありがとうございました。

515NAME IS NULL2017/08/26(土) 20:02:14.73ID:UyefH8h9
>>512,513
お前らの頭なw
なんでバカのくせに教えたがるの?w

516NAME IS NULL2017/08/26(土) 20:08:01.94ID:fS1lbmBN
「話が通じない」んじゃなくてお前の書き方がヴァカなんだよ

517NAME IS NULL2017/08/26(土) 20:12:57.75ID:UyefH8h9
>>516←自分のバカをバカにされてバカにしてる奴が質問者だと思いこみたい救いようのないバカw

518NAME IS NULL2017/08/26(土) 20:19:19.21ID:xlgNQVZl
>>514
そもそもあなたの言葉は非常にわかりにくく、大半の日本人は理解できませんよ?

519NAME IS NULL2017/08/26(土) 20:20:33.40ID:xlgNQVZl
言い方が悪いけど、頭の悪い女性が書く文章に似ている。

520NAME IS NULL2017/08/26(土) 20:33:35.52ID:UyefH8h9
>>519
だから悪いのはお前の頭だと何度w
とはいえすかさずバカ特有の論理性を欠いた女性蔑視発言をねじこんでくるあたりはさすがだなw
バカオブザバカの称号をお前に授けようwww

521NAME IS NULL2017/08/26(土) 22:13:59.42ID:5aHU4Upa
第三者がかたわらでわめいている構図w

522NAME IS NULL2017/08/26(土) 23:00:21.75ID:???
いつものクズがVBAスレから出張してきててワロタwww

523NAME IS NULL2017/08/27(日) 08:01:00.92ID:???
>>518
それはそうです。
分かる人(Withというキーワードだけでピンと来る人)に向けて書いてますから。

524NAME IS NULL2017/08/27(日) 08:24:00.98ID:???
with自体について突っ込まれているんじゃないってことすら読み取れないのか。
ざっと見まわしても>>494ぐらいしか見当たらんけどな、そういうのは。

525NAME IS NULL2017/08/27(日) 10:06:46.09ID:QBQ1on1X
>>523
だから、どこでSQLのwith句をどう使おうとしているのか、どう書こうとしているのか、頼むから書いてくれ。

526NAME IS NULL2017/08/27(日) 11:43:26.86ID:???
そうやって甘やかすから図に乗るんだよ

527NAME IS NULL2017/08/27(日) 13:17:12.26ID:???
暇な人(分かるとは言っていない)だけが答えてますから。

528NAME IS NULL2017/08/27(日) 18:58:25.87ID:???
>>525
>相手方は、AccessかExcelかCsvです
らしいから、Jet(ACE)だろ
少なくとも俺の知るバージョンではCTEは使えないから
回答として、できないで終了でいんじゃね

529NAME IS NULL2017/08/27(日) 20:18:39.07ID:???
質問者の態度が悪いから終了済み

530NAME IS NULL2017/08/28(月) 19:51:37.55ID:???
Excel VBAスレにいるいつもの奴だからスルーで
自分で質問して自分で回答してる奴ね

お前らどうせ分からないだろ、俺が一番詳しい(キリッ
って態度で質問してる

誰かが回答するとすぐ回答者を装って嫌違うってレスしてくるからすぐわかるぜ

531NAME IS NULL2017/08/28(月) 21:28:11.81ID:???
憐れだな

532NAME IS NULL2017/08/28(月) 22:52:26.60ID:XdLa3rwF
>>530
だからそのwithじゃなく雑誌のwith

533NAME IS NULL2017/08/31(木) 16:21:53.66ID:eqJ9vJSf
>>1
【緊急】
すき家の定食に衝撃異物!
ずさんな管理体制が明らかとなった
指摘したその時!わざとらしく店員が声をあげごまかした!

229 名前:やめられない名無しさん [sage] :2017/08/29(火) 07:31:54.64 ID:EfhOnUp0
俺の朝はいつもすき家
楽しみにしてたのに・・今日に限って朝定食にしたんだ

見てくれ、これが証拠
店員さんも驚いて声をあげてる・・
https://www.youtube.com/watch?v=wjD4hUeU-CA

ちなみに半分食べた
お客様センターが通じない・・病院行く・・
(´・ω・`)すき家が大好きだったのに・・

534NAME IS NULL2017/09/02(土) 17:24:26.40ID:fn9CT/Jy
LEFT JOINで結合した際に、対応するレコードがない場合
値がnullになりますが、元のテーブルのデフォルト値にするにはどうしたら良いでしょうか?
SELECT句で各clumnにIFNULLは使いたくないです
MySQLを使っています
よろしくお願いします

535NAME IS NULL2017/09/02(土) 18:09:41.53ID:???
LEFT OUTER JOINの話かな?
どっちにしろ、そんな方法はない
IFNULLで地道に埋めるしかない

536NAME IS NULL2017/09/02(土) 18:24:43.00ID:???
>>534
CASE式、COALESCE、IFNULL, サブクエリ、デフォルト値有りの一時テーブルへINSERTとかかな
IFNULLを使いたくない理由が手間のみなら諦めたほうがいい
真っ当な理由があるならCASE式での代替を考えるといいのでは

537NAME IS NULL2017/09/02(土) 18:26:33.96ID:fn9CT/Jy
>>535
>>536
そうですか・・・
clumnの数がかなりあるので糞面倒ですが地道にやります
ありがとうございました

538NAME IS NULL2017/09/02(土) 18:45:22.86ID:???
ソース全部手で打ち込んでいるのか?
環境が分からないけど、
大概のエディタって置換機能あるだろう

539NAME IS NULL2017/09/02(土) 19:42:16.80ID:???
単純な繰り返しならエクセルの計算式でsql文作ってコピペすれば楽チン

540NAME IS NULL2017/09/02(土) 19:57:29.59ID:???
すごくたくさんあるならSQLを生成するスクリプトを書くとか

541NAME IS NULL2017/09/02(土) 21:09:40.84ID:???
SELECT *, "default" AS [name] FROM foo

こんな感じでfooテーブルのレコードに任意の値をくっつけたものを出力可能
NOT EXISTSとかのサブクエリと組み合わせて、EXISTS側とUNIONで合体する
自分ならまずやらない方法ではあるが

単発のSQLじゃなくアプリケーションで使うSQLだとすると
DB設計かアプリケーション設計かどっちか考えなおしたほうがいいかもね

542NAME IS NULL2017/09/02(土) 23:03:08.61ID:???
「かなりある」とか言ってても実際は大したことない

543NAME IS NULL2017/09/02(土) 23:18:50.28ID:???
CentOS6 + mysql 5.57
社のシステムなので、アップデートやインストール、ログ設定の変更ができない前提です。

まず前置きですが

既存のデータをDB化する一環で、大量(毎日80000行)くらいのinsert文を実行しなければなりません。
insert文自体は、既存のテキストデータから必要事項を抜き出して私が組み立てています。
元のデータはwindowsだったりワープロ専用機だったりですが、最終的に全てUTF-8に変換しています。
まぁこの処理自体はマクロ等駆使してやっているので問題がないのですが、元々のテキストに本来SQLで避けなければならないような半角記号とかが含まれている可能性がありますが、そこまでのチェックは物理的にできません(やっていません)。
一応、改行を\n、半角の引用符号は全角に、程度の処置はしています。
で、この大量のテキストをsource文で読み込んで処理するのですが、所々warning**みたいな表示がでているのがわかります。
登録済み行数のチェックくらいはできますが、フィールドの中身が正しく登録されたかどうかまでのチェックはとても手が回りません。

そこで質問なんですが、SQLを実行する前にエラーになりそうな箇所を知る方法、あるいは、実際にエラーやwarningが出た行を知る方法(ツール、設定)がないでしょうか。

544NAME IS NULL2017/09/02(土) 23:37:05.01ID:???
改行コードを入れてはいけないとか
引用符を入れてはいけないとか
そんな「俺ルール」はDBにとっては知ったこっちゃないので
まずはその「俺ルール」を正確に定義しないと何も始まらない

545NAME IS NULL2017/09/02(土) 23:57:36.86ID:???
>>543
エラーが出た行が分からない理由がよく分からない

自分ならINSERTじゃなくインポート(LOAD)使う
8万行くらいならよっぽどレコード長が長くない限りすぐ終わる
でDBからデータをエクスポートして元データと差分比較して検証する
検証が完了したらインポート先のテーブルから本番テーブルへデータ移行する

まあ100件くらいの少量でやり方を確立してから本当に必要な量でやったほうがいいよね

546NAME IS NULL2017/09/02(土) 23:58:49.02ID:???
あとSQLの質問じゃないしMySQLスレで聞いたほうがいいんじゃないの?

547NAME IS NULL2017/09/03(日) 00:25:28.93ID:???
エラーハンドリングのやり方がわからないという意味なのかな?
それなら製品ごとにやり方違うからMySQLスレで聞いたほうがいいと思う

548NAME IS NULL2017/09/03(日) 08:08:16.34ID:???
>>543
> そこまでのチェックは物理的にできません(やっていません)。
やれよ...
チェックすべきなのは
https://dev.mysql.com/doc/refman/5.6/ja/string-literals.html
表 9.1 特殊文字エスケープシーケンス を参照

> 実際にエラーやwarningが出た行を知る方法(ツール、設定)がないでしょうか。
tee と warning コマンドで全部出力すればいいだけだろ

まあ何度もやるなら>>545の言うようにLOAD(もしくはそれをラップしたmysqlimportコマンド)を使うべきとは思う
https://dev.mysql.com/doc/refman/5.6/ja/mysqlimport.html

549NAME IS NULL2017/09/03(日) 09:18:14.94ID:???
>>543
>チェックはとても手が回りません。
なんで?時間が無い、技術が無い?

550NAME IS NULL2017/09/03(日) 10:57:23.38ID:O1ZU9t9T
もうSQLというより、IT技術者の初心者の質問だよなw

551NAME IS NULL2017/09/03(日) 11:54:28.53ID:???
計算機科学者と宇宙飛行士ってどっちの方が頭いい?

552NAME IS NULL2017/09/03(日) 21:49:26.78ID:O1ZU9t9T
>>551
宇宙飛行士は頭がいいというよりは、超絶バランス感覚がある人でないとできない。

頭が良すぎる人には向いてない。

553NAME IS NULL2017/09/04(月) 03:07:24.06ID:???
自分は生まれつきもの凄く頭が悪いのですが、東京大学理学部数学科に入って数学を学びたいという目標があります。
生まれつきもの凄く頭が悪い人でも、人並み外れた努力を積み重ねれば、その目標を実現することはできると思いますか?
どうでしょうか?

554NAME IS NULL2017/09/05(火) 23:16:20.77ID:fWoFV/f/
>>553
東京大学に入ることは努力で可能なことです。そんなに難しいことではありません。

高校生までに東大に合格するような勉強方法や、強い意志がみなないだけです。

555NAME IS NULL2017/09/06(水) 00:06:04.88ID:???
ネカフェで三田紀房の ドラゴン桜 でも読んどけ

556NAME IS NULL2017/09/06(水) 19:19:21.78ID:ARdyJ0VM
それをSQLで

557NAME IS NULL2017/09/08(金) 00:26:54.83ID:???
insert into >>553(atama)
values
select エッセンス from ドラゴン桜;

558NAME IS NULL2017/09/12(火) 11:19:53.86ID:pQpjXKHz
MySQL5で1つのカラムに空白区切りの単語がはいっているとします。
テーブル構成は以下の通りです。

id|word
.1|バナナ
.2|バナナ みかん

COUNTで集計したいのですが、
空白文字で区切って「バナナ:2」「みかん:1」のようにすることって出来ますか?
(空白区切りじゃなくてカンマ区切りでもいいです)

別に単語分割したテーブルを用意するのではなく、
1つのテーブルでカラム内の値を分割して集計する方法があれば教えてください

559NAME IS NULL2017/09/12(火) 15:45:27.39ID:???

560NAME IS NULL2017/09/12(火) 15:46:12.26ID:???

561NAME IS NULL2017/09/12(火) 15:55:17.71ID:???
各DBでのやり方見たら分かると思うけど
そのケースをSQLで処理するためには
単語分割したテーブルを用意するのと同じような処理が必要

562NAME IS NULL2017/09/13(水) 02:52:44.62ID:xvQI2SSS
関数従属性の話って「意味論」でいいんだよね?
ある「カラムAから -> カラムB」の従属性があるかどうか
って現在のテーブルに格納されている値を見比べるだけじゃ
わからないよね?
もしカラムAとカラムBの値が全く同じ組み合わせで対応している
ように見えても、それが偶然これまではそうなだけなのかもしれないし、
「A -> B」が「値を見る限り従属している」のが分かったとしても、
それが「直接従属している」か「推移的な従属」なのかって、
値を見てもわからないよね?
カラムの意味を考えたり、値を格納している実装を見ないと
「どんな従属性なのか」ってわからないっすよね?

563NAME IS NULL2017/09/13(水) 07:05:44.47ID:???
そうっすね

564NAME IS NULL2017/09/13(水) 07:50:29.57ID:???
今あるデータがすべてならばデータを見れば判断できる。
それ以外のこれから入れるデータがあるのであれば当然、今あるだけのデータからは判断できない。

565NAME IS NULL2017/09/13(水) 12:19:17.25ID:???
意味論て言ってるのにデータを見ただけで分かるわけないだろ
頭が悪い奴だなw

566NAME IS NULL2017/09/13(水) 13:05:00.31ID:xvQI2SSS
>>565
「意味論だよね?」って確認してるの。
関数従属性について図で例示されてる解説があるだろ?
でもこういうのみてもさっぱり理解できないから、よく考えたら
例示では理解しにくい概念なんじゃないかって思ったんだよ。
やはりそうなのか。

567NAME IS NULL2017/09/13(水) 15:52:20.65ID:???
うん、関数従属性はデータからだけじゃわからないよ

既存のテーブル構造が関数従属性を100%表現できている場合は
データじゃなくその構造を見ることでどういう従属性があるか理解できるかもしれないが
現実には100%表現できてることなんてまずないからね

568NAME IS NULL2017/09/13(水) 20:22:58.03ID:???
集合論を知っていればわかるように、集合自体が構造を表す。
つまり、テーブル内のデータが全体集合なのであればそこに存在する従属性はそれでわかる。
現実的には全体集合を得られていることなんてレアケースだろうから、そのときは
「(いま得られている)データからだけじゃわからない」ってことになるが。

569NAME IS NULL2017/09/13(水) 20:53:13.11ID:???
>>568
言い訳が苦しすぎんだろw

{ A , 11 , 999 , タコス , 2017/08/13 }
{ B , 12 , 777 , ドンタコス , 2017/08/14 }
{ C , 13 , 555 , ポリンキー , 2017/08/15 }
{ D , 14 , 333 , ネオポリンキー , 2017/08/16 }
{ E , 15 , 111 , ポンキッキー , 2017/08/17 }
{ F , 16 , 333 , ドストエフスキー , 2017/08/18 }

これが全体集合だったとして、ここに存在する従属性がわかるなら教えてくれよ

570NAME IS NULL2017/09/13(水) 21:11:39.20ID:???
3番目のカラムを除く組み合わせほぼ全てだろ?
Aならばタコスだし2017/08/13だし、ドンタコスならばBだし12だ。

571NAME IS NULL2017/09/14(木) 19:05:36.25ID:???
bigqueryの質問はここでいいですか?

572NAME IS NULL2017/09/14(木) 19:10:31.97ID:arvuh5Nr
質問スレで念のために自分の聞きたい質問がスレの主旨に合っているかを問うのだが
その問い自体が既にスレの主旨から外れているという矛盾を抱えた石橋叩きの人生
生きるのが大変そうですね

573NAME IS NULL2017/09/14(木) 19:28:55.22ID:???
>>572
適切なスレに誘導してくれよw

574NAME IS NULL2017/09/14(木) 19:53:49.43ID:???
BigQuery ってなんだ?
ってググったら Google のサービスか
何を聞きたいのか知らんけど普通に Google に聞けよ

575NAME IS NULL2017/09/21(木) 06:08:31.91ID:???
MYSQLで
まったく同じ構造の表三つを、

表1    表2   表3
1     null   1
2     2     null
3     3     3
null    4     null
5     null    5
nul    6     6

のように結合したいのですが、どのようなSQLにすればよいのでしょうか
表は三つあるのですが、どこがデータ量が一番多いのかはわかりません

576NAME IS NULL2017/09/21(木) 06:28:30.84ID:???
>>575
FULL OUTER JOIN

577NAME IS NULL2017/09/22(金) 14:44:50.06ID:???
テーブルレイアウトも結合条件も解らんのだが

578NAME IS NULL2017/09/22(金) 15:23:28.44ID:ztnwHSNR
推測するに各テーブルがカラム1個で、
全データを列挙したいんじゃ?

579NAME IS NULL2017/09/22(金) 19:55:55.00ID:???
つまり、こういうことか?
select 表1.カラム1,表2.カラム1,表3.カラム1
from
(select カラム1 from 表1
union
select カラム1 from 表2
union
select カラム1 from 表3) t
left join 表1 on 表1.カラム1= t.カラム1
left join 表2 on 表2.カラム1= t.カラム1
left join 表3 on 表3.カラム1= t.カラム1

580NAME IS NULL2017/09/27(水) 21:42:06.33ID:???
SQL Server 2014 で教えてください。

1)
select * from tableA join tableB;

select * from tableA left join tableB;
と書いた場合、上は inner join、下は left outer join と同等でしょうか。
引き継いだコードが上のように書いてあるのですが、join で検索を掛けても inner join とかの記事しか出てこず。

2)
テーブルから特定の値のレコードを検索する場合、
a) 検索したい値を格納した(一時)テーブルと結合する
 select * from tableA t1 inner join tableB t2 on t1.id = t2.id; など /* tableB に欲しいレコードの id を格納しているとします */
b) where で in を使用して検索したい値を列挙する
 select * from tableA t1 where id in (/* 欲しいレコードの id を列挙 */)
などの方法があるように思います。

a と b の実行時間を計ると b の方が圧倒的に速いのですが、そういうものなのでしょうか。

581NAME IS NULL2017/09/27(水) 22:06:04.92ID:???
>>580
1) JOINだけならINNER JOIN、LEFT JOINはLEFT OUTER JOIN
下のページでjoin_typeを参照して
https://docs.microsoft.com/en-us/sql/t-sql/queries/from-transact-sql

2) 状況による
explainして実行計画を比較するのが一番
(参考)https://stackoverflow.com/a/1200337

5825802017/09/28(木) 21:07:29.31ID:???
>>581
ありがとう。

1) は動作結果からそう考えていたのですが、仕様的確認をとれて助かりました。
2) はそうですよね。SSMS の実行計画は見ていたのですが、そういう差があること以上のことは分かりませんでした。
教えていただいた方法でも調べてみます。

583NAME IS NULL2017/10/10(火) 07:06:25.79ID:???
サブクエリでのORDER BYが、メインクエリでも有効なのかどうか、
ご存知の方教えていただけないでしょうか。

例えば、学生別点数テーブルから点数上位10名を取得したい場合、

SELECT
*,
ROWNUM as num
FROM (
SELECT *
FROM 学生別点数テーブル
ORDER BY 点数 DESC
)
WHERE num <= 10;

というソースだと、
サブクエリでは学生別点数テーブルが点数の降順でソートされるはずですが、
メインクエリでROWNUMが各レコードに通番(num)を振る際にもその並びが保持されているのか。

「サブクエリの並び順って、メインクエリでは保持されないんじゃなかったか?」と質問を受け、
回答に困っている状態です。
oracle 11gのリファレンスには、ROWNUMを利用した上記SQLで、点数上位10名が取得可能と読み取れます。
「ORDER BY句を副問合せに埋め込んでROWNUM条件をトップレベル問合せに置いた場合、行の順序付けの後でROWNUM条件を強制的に適用させることができます。たとえば、次の問合せは、小さい順に10個の従業員番号を持つ従業員を戻します。」
https://docs.oracle.com/cd/E16338_01/server.112/b56299/pseudocolumns009.htm

別の箇所で質問させてもらった際は、
「サブクエリーでソートされた結果を出力するだけ(joinやwhere条件など索引に関係するものが無ければ)なら、並びを変更される要因がないので、同じ結果となる」
との回答をもらっていますが、
もしよろしければこちらの有識者の方のご意見も頂けると幸いです。

よろしくお願い致します。

584NAME IS NULL2017/10/10(火) 07:43:42.44ID:???
その回答した人は、ROWNUMがOracle固有の疑似列だということを知らなかったんじゃないかね。
ちゃんとそれがわかるように質問した?
あとOracleの場合でも、順序はROWNUMで得られるけれども出現順が保持されるとは言っていないと思う。

585NAME IS NULL2017/10/10(火) 08:19:14.50ID:???
>>583
保証されないって思っておいた方がいいと思う

> たとえば、次の問合せは、小さい順に10個の従業員番号を持つ従業員を戻します。
これは
「小さい順に10個の従業員番号を持つ従業員」を戻します
であって
小さい順に「10個の従業員番号を持つ従業員」を戻します
じゃない

> 「サブクエリーでソートされた結果を出力するだけ(joinやwhere条件など索引に関係するものが無ければ)なら、並びを変更される要因がないので、同じ結果となる」
これOracleサポートの正式回答ならとりあえずは信じていいと思うけど、バージョン変わった時も保証されるのかを聞いておいた方がいいと思う

そもそも普通に
order by num asc
を追加しとけばいいだけじゃないの?

586NAME IS NULL2017/10/10(火) 08:36:52.44ID:oX0yCwR9
でたらめアドバイスだらけだが、OracleのFROM句の副問い合わせは、インラインビューと呼ばれ、並び替えも含めてインラインビューの結果そのものを、再度、検索する。

rownomをSELECT句に書いて、別名を付けるのは一般的ではない。

5875832017/10/10(火) 09:25:30.70ID:???
>>584,585
ご回答ありがとうございます。
別場所で質問した際は、oracle11gで、と前置きしていましたが、回答者の方がoracle固有の疑似列と知ってらっしゃったかは分かりません…

お二人に指摘頂いてるリファレンスの解釈については、確かにそのとおりですね。
公式の見解を聞きたいですが、サポート契約が無いのが辛いorz

5885832017/10/10(火) 09:29:46.26ID:???
>>586の方もご指摘ありがとうございます。

確かに、リファレンスにもROWNUMにasで別名を付けるソースではないんですよね…
ただ、既に稼働しているシステムのソースがROWNUM別名形式でして、弄くる箇所は最小限にしたいなあ、と。

589NAME IS NULL2017/10/10(火) 09:48:36.37ID:oX0yCwR9
>>588
そもそもrownumをSELECT句に挙げる慣習はOracleにはない。

最近、SELECT句で選択していない項目は条件で使えないと思っていたベテランがいたがw

590NAME IS NULL2017/10/10(火) 12:27:45.02ID:???
何でrow_number関数使わないのか

591NAME IS NULL2017/10/10(火) 13:02:37.26ID:???
既に稼働しているシステムのソースをなるべく弄らない方針にすると
負債がどんどん貯まっていって見るのも嫌になるのでおすすめ

592NAME IS NULL2017/10/10(火) 15:19:43.61ID:mDt5cW24
>>583
外側のクエリでサブクエリの並び順を変更する要素がなければ、サブクエリの並び順のまま出力されるけど、それは現状の実装がそうなってるだけ

外側にもサブクエリと同じorder byを付けとけばオプティマイザが2回目のソートは不要って判断してくれるから心配なら付けといて損はない

593NAME IS NULL2017/10/10(火) 16:01:13.47ID:mDt5cW24

594NAME IS NULL2017/10/10(火) 16:50:27.19ID:oX0yCwR9
>>592
それはおかしい。
間違いは素直に認めろ。

595NAME IS NULL2017/10/10(火) 16:51:41.65ID:oX0yCwR9
インラインビューをサブクエリとわざわざ曖昧にしてるあたり分かっているとは思えない。

596NAME IS NULL2017/10/10(火) 16:55:22.20ID:oX0yCwR9
>>590
row_numberは記述が冗長になるのと、機能を拡張しすぎていてかえって分かりにくくなってしまう。

597NAME IS NULL2017/10/10(火) 17:00:42.30ID:oX0yCwR9
>>592
あなたはrownumはフェッチ時に番号が振られるのを理解してないのだと思う。

番号を付けるときにorder by rownumしても何の意味もない。

598NAME IS NULL2017/10/10(火) 17:11:36.33ID:mDt5cW24
>>597
アウターにorder byがなくてもオラクルが順序を保証してくれると主張してるの?
最低限、何を主張したいのか分かるように書いてくれる?

599NAME IS NULL2017/10/10(火) 17:13:18.53ID:???
>>596
Oracle方言よりANSI SQL使うに越したことはない

600NAME IS NULL2017/10/10(火) 17:27:02.97ID:oX0yCwR9
>>598
rownumという列があるわけではない。

並び順はorder byを指定しないかぎりは保証しないというSQLの規格とは関係ない。

Oracleは内部的なことをSQLに書いているだけで、SQL ServerのTOP関数も内部では二度SELECTしていることが多い。

601NAME IS NULL2017/10/10(火) 18:06:03.05ID:mDt5cW24
>>600
で?
保証してくれるの?してくれないの?

602NAME IS NULL2017/10/10(火) 18:54:06.50ID:oX0yCwR9
rownum絡みの仕様変更はずっとアナウンスされていない。

603NAME IS NULL2017/10/10(火) 19:16:30.46ID:???
Qに対してのAが帰ってこないとはこの事だ

604NAME IS NULL2017/10/10(火) 20:57:29.86ID:???
order byがなければ順序は保証しないとマニュアルに明記されているにも関わらず
rownum使ったtop-N最適化のケースは例外的に順序が保証されると言うならその根拠が必要だよね

605NAME IS NULL2017/10/10(火) 21:07:48.37ID:oX0yCwR9
どういう思い込みなのか、rownumの変な使い方にこだわって、やってもかまわないが、変な人を貫きたいというので答えたのにな。

さらにオラクル社のいうこと、伝統、実装も突っぱねて、さらにオラクルでは、リソース食いのrow_numberを使用しようともしている。

どのRDBMSも標準化SQLが先にあって作られているわけではないから、標準SQLの方が性能も動きも読めないうえに、バグにあたる可能性がある。

さらに標準化SQLの構文を拡張してるから、どんどんわかりにくくなる。

なんで調べないのかな。

rownumは列じゃないんだよ。
インラインビューのorder byは意味があり、入れ子のrownum同士は別物。

オラクルではインラインビューのorder byは意味があり、インラインビューをSELECTするSQLではrownumをorder byをするのはかまわないが滑稽。

使い方は自由だからそう書きたいならそう書けばよい。

606NAME IS NULL2017/10/10(火) 21:14:58.28ID:???
こいつは誰と戦ってるんだ?

607NAME IS NULL2017/10/10(火) 21:16:41.71ID:oX0yCwR9
>>604
どういう初心者なのか知らないが、ソートしたものの中から、初めの何件かを取得するというSELECT文は、Oracle Databaseではインラインビューでソートしてrownumで絞り込む構文になっているだけ。

他のRDBMSでもOracleと同じものもあれば、ひとつのSELECT文で表現するものもある。

SQLの見た目で判断しているようでは、データベースをやめた方がいいよ。

どうしてソートしてないのに先頭何件かが取れるのか考えろよw

608NAME IS NULL2017/10/10(火) 21:26:57.19ID:xk7c94Oj
諦めろお前らはとっくに ID:oX0yCwR9 にマウント取られてんだよw

609NAME IS NULL2017/10/10(火) 21:31:29.49ID:oX0yCwR9
なぜ定石を無視する質問をするのかがわからない。

610NAME IS NULL2017/10/10(火) 21:39:40.29ID:oX0yCwR9
>>604
Oracle Databaseは保証しないことは書いてあっても、保証するとは明言していないのが特徴。

こんな実績があって有名な話題で、さらにorder byを特殊なOracle構文にも摘要させたがるのは、世界初のリレーショナルデータベースのオラクルが憎くて、標準SQL側の攻撃のようだw

611NAME IS NULL2017/10/10(火) 21:41:16.16ID:mDt5cW24
内部実装についていくら書いても
オラクルが順序を保証する根拠にならないよ
ただの無意味な長文

612NAME IS NULL2017/10/10(火) 21:46:43.85ID:mDt5cW24
>>610
じゃ、保証してないんでしょ?
保証してんの?

613NAME IS NULL2017/10/11(水) 01:21:18.59ID:???
>>586
一般的な書き方かどうかはどうでもいいけど
>並び替えも含めてインラインビューの結果そのものを、再度、検索する。
のソース教えてくれ
とくに、並び替えも含めてってとこな

これが正確で保障された動作なら、ORACLEにおいては保障されてるって話になるな

614NAME IS NULL2017/10/11(水) 02:07:19.45ID:???
>>613
なんねーよw
再度検索した後の結果セットの並び順が
その理屈でなんで保証されるんだよ

615NAME IS NULL2017/10/11(水) 05:03:11.04ID:f/rcAUbh
Oracle初心者が調べもせずに教えろと騒ぐスレになったのか。

616NAME IS NULL2017/10/11(水) 05:13:51.06ID:f/rcAUbh
例の目的を達するにはこう書くと決まっているのに。rownumは値が固定のカラムではないと何度言ったらわかるのかw

617NAME IS NULL2017/10/11(水) 05:51:58.04ID:???
>>614
保障されないならrownumでトップnとか取れないって事になるぞ
あれは単に行のフェッチ順のはずだから
でも実際にはあちこちでORACLEのトップnのクエリの例としてあがってるからな

>>616
理屈も解らずにただこう書くと言われても納得できない方が普通じゃないかね

618NAME IS NULL2017/10/11(水) 08:32:45.45ID:???
ここまできたらソース出した方がいいぜ

619NAME IS NULL2017/10/11(水) 11:11:27.92ID:f/rcAUbh
だから保証されていることを保証しているのかとアホみたいに聞くからおかしなことになる。

オラクルはインラインビューにあとからorder byを導入して、レコードの並び順を固定している。

だからインラインビューをSELECTする場合にはorder byがいらない。

だいたいマニュアルでも書籍でもネット上でもさんざん説明されているのに、オラクルスレでもないここで聞いている行為がおかしい。

620NAME IS NULL2017/10/11(水) 11:15:12.63ID:???
Oracleスレでやれよ
ここSQL全般スレなんだから方言とか実装の話なんかいらん

621NAME IS NULL2017/10/11(水) 11:58:54.68ID:???
>>617
top-Nを取得することと、取得した結果セットの並び順がどうなるかは別の問題だってのが分からない?

622NAME IS NULL2017/10/11(水) 11:59:35.43ID:???
下のが質問者が引用してたリファレンス原文だけど結果セットの並び順については何も言及されてない
the 10 smallest employee numbersがreturnされると書いてるだけ

For example, the following query returns the employees with the 10 smallest employee numbers.
This is sometimes referred to as top-N reporting:
https://docs.oracle.com/cloud/latest/db112/SQLRF/pseudocolumns009.htm#SQLRF00255

623NAME IS NULL2017/10/11(水) 12:02:40.48ID:???
でもって>>593リンクの中に並び順が保証されてるわけじゃないと書いてある

so, while I cannot imagine
select rownum, x.* from (select ... order by ... ) x
not being sorted by rownum (by the order by), it is permitted to not be sorted.

... Why would it be permitted not to be sorted? ...
because there is no order by on the outer query. that is why.

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1137689100346245972

624NAME IS NULL2017/10/11(水) 12:04:27.88ID:???
>>619
保証されてるというソースがあればみんな納得するよ

625NAME IS NULL2017/10/11(水) 12:53:06.66ID:???
>>619
> だからインラインビューをSELECTする場合にはorder byがいらない。
> だいたいマニュアルでも書籍でもネット上でもさんざん説明されている
ネットや書籍はどうでもいいからどのマニュアルのどこに載ってるか示してくれ

626NAME IS NULL2017/10/11(水) 17:03:54.04ID:f/rcAUbh
>>625
マニュアルは外国に丸投げしたせいか、劣化が激しく、間違いや変な説明が多いので、マニュアルが正ともかぎらないし、あえて言及してないことも多い。

627NAME IS NULL2017/10/11(水) 17:07:38.41ID:f/rcAUbh
https://docs.oracle.com/cd/E16338_01/server.112/b56299/pseudocolumns009.htm

「SELECT * FROM (SELECT * FROM employees ORDER BY employee_id) WHERE ROWNUM < 11;

前述の例では、ROWNUM値はトップレベルのSELECT文の値です。これらの値は、副問合せ内のemployee_idによって行が順序付けられた後で生成されます。」

628NAME IS NULL2017/10/11(水) 17:12:40.33ID:???
そのトップレベルのSELECTの結果の出力順が
インラインのORDER BYの順序と同一であることが
保証されてるかどうかって話じゃなかったの?知らんけど。

629NAME IS NULL2017/10/11(水) 17:13:49.47ID:f/rcAUbh
「ORDER&#160;BY句を副問合せに埋め込んでROWNUM条件をトップレベル問合せに置いた場合、行の順序付けの後でROWNUM条件を強制的に適用させることができます。
たとえば、次の問合せは、小さい順に10個の従業員番号を持つ従業員を戻します。
これは、上位N番のレポートと呼ばれることがあります。


SELECT * FROM
(SELECT * FROM employees ORDER BY employee_id)
WHERE ROWNUM < 11;

前述の例では、ROWNUM値はトップレベルのSELECT文の値です。
これらの値は、副問合せ内のemployee_idによって行が順序付けられた後で生成されます。」

630NAME IS NULL2017/10/11(水) 17:18:12.94ID:f/rcAUbh
>>628
rownumは主問い合わせの列で、その値は副問い合わせの結果と書いてある。

これを根底からくつがえすなら、あらゆるシステムで問題になっている。

これは内部的にソートされるから結果的に並び順が同じたぐいの話ではない。

631NAME IS NULL2017/10/11(水) 17:19:14.10ID:???
うんだからROWNUMの値がインラインのORDER BYに紐付いてるのはわかったよ
そのROWNUM < 11なトップレベルの問合せはROWNUM順になるのが保証されてるのか
ってのが上の人らの指摘なんじゃないの?
個人的には保証されてるかどうかはどうでもいいんだけどズレた内容でドヤ顔されるのはうざいし

632NAME IS NULL2017/10/11(水) 17:26:17.94ID:f/rcAUbh
インラインビューのorder byは無視されているのではなくて、order byの結果セットを返す仕様で、rownumは結果セットのフェッチ順。

構文が気持ち悪くみえる初心者がいるのは理解できるが、SQL ServerのTOPの方がよほど気持ち悪い。

レコードに位置の概念があったり、位置の概念がないと思いながらもソートがいきなりできると思い込むITオンチと話すときりがない。

633NAME IS NULL2017/10/11(水) 17:28:00.59ID:???
誰でも知ってることをドヤ顔で永遠と書いた挙句に最後は八つ当たりww

634NAME IS NULL2017/10/11(水) 17:29:56.92ID:f/rcAUbh
>>631
それは構文がそう見えるだけだろうが。

rownumの値は副問い合わせの結果で、かつrownumは主問い合わせの取得順。

Oracleの構文になんでそんなに文句があるのか。

外国人はデタラメが多いから気をつけろよ。

635NAME IS NULL2017/10/11(水) 17:31:15.35ID:f/rcAUbh
>>633
どうもスルー力がないようですね。

636NAME IS NULL2017/10/11(水) 17:33:11.25ID:???
構文にじゃなくてお前に文句があるだけでは

637NAME IS NULL2017/10/11(水) 17:36:44.50ID:f/rcAUbh
実際にこの話題は仕事でも若い人ほど、標準SQLが先にあって、OracleがそのSQLの仕様に沿って作られていると勘違いしているのか、引っかかって面倒なんだよな。

最近もSQLはこう書くとこうなるみたいな話をデータベースに詳しくない人間が言い始めると、面倒だからそれに従うしかない。

638NAME IS NULL2017/10/11(水) 17:38:22.42ID:f/rcAUbh
批判されていると思い込む恐怖心はわかるが、ネットとはこういうところです。

639NAME IS NULL2017/10/11(水) 17:47:01.74ID:???
批判されてるのもお前では

640NAME IS NULL2017/10/11(水) 18:02:51.58ID:???
>rownumは主問い合わせの取得順
これは間違いないんだが、その肝心の主問い合わせの取得順が
副問い合わせのORDER BY順にならなければトップn取れないわけだが
(最終的な出力順はその通りとは限らんでも良いけど)

これがORACLEでは保障されてるってなら
マニュアルのどこに書いてあるか言えばいいだけなんだがな

ORACLEには仕様ではないが過去の実装からそうだと決めつけられてることが結構あって
ORACLE自身も影響範囲がでかすぎて、おいそれと変更ができなくなってる
これもその一つだと思うけどね

641NAME IS NULL2017/10/11(水) 18:12:59.37ID:???
やりとり見てないまま横から失礼だが
普通は row_number() over 〜 使うんじゃないの

642NAME IS NULL2017/10/11(水) 18:18:20.51ID:???
>>640
top-N集合の取得は保証されてるよ
それはリファレンスのrownumのところ読めばわかるじゃん

643NAME IS NULL2017/10/11(水) 18:48:25.70ID:???
>>641
そうね
今はfetch first/next使う

644NAME IS NULL2017/10/11(水) 19:56:15.09ID:???
どうでも良いからOracleのスレでやれって アフォどもが

645NAME IS NULL2017/10/11(水) 21:34:43.34ID:f/rcAUbh
ソート条件のあるカーソルでフェッチ順がソート条件通りにならないという主張はただの知識不足としか思えない。

646NAME IS NULL2017/10/11(水) 21:40:14.45ID:f/rcAUbh
>>640
なんでオラクル社の説明をねじ曲げて解釈するのか?

例のrownumの件は、ドキュメントでも主問い合わせのrownumは、副問い合わせの結果が値で、主問い合わせの疑似列であると説明している。

647NAME IS NULL2017/10/11(水) 21:40:16.53ID:9hHhkBSp
>>645
もうやめたら?言えば言うだけバカがよけいにムキになるだけだぞw

648NAME IS NULL2017/10/11(水) 21:42:53.00ID:f/rcAUbh
>>647
SQLは仕事上、間違いを主張しまくる人間が多いから、ここでもとにかく誤りを正さないと生活がめちゃめちゃになる。

649NAME IS NULL2017/10/11(水) 21:51:37.74ID:???
>>646

>>623でオラクルのエンジニアが並び順は保証されてないとハッキリ言ってるじゃん
彼が間違ってて君が正しいと言える客観的根拠が全く提示されないから説得力ゼロ
今のところ”ソースは俺の頭の中(キリッ”な状態

650NAME IS NULL2017/10/11(水) 21:53:42.91ID:???
>>645
君以外誰一人としてカーソルのフェッチについての話なんてしてないよ

651NAME IS NULL2017/10/11(水) 22:03:53.96ID:9hHhkBSp
ああなるほど、いかにもバカらしい勘違いだなw

652NAME IS NULL2017/10/11(水) 22:21:29.26ID:???
典型的な老害

653NAME IS NULL2017/10/11(水) 22:25:26.59ID:f/rcAUbh
>>650
SQLが何なのかわかってない。いい加減にしろ。

654NAME IS NULL2017/10/11(水) 22:27:41.07ID:f/rcAUbh
>>649
その人が間違ってるのに、なぜオラクルエンジニアの私が間違ってると決めつけられなきゃいけないのか?

655NAME IS NULL2017/10/11(水) 22:31:39.23ID:???
>>646
主問い合わせのrownumは主問い合わせのフェッチ順のはずで
>副問い合わせの結果が値
なのは、「主問い合わせのフェッチ順が副問い合わせのorder by順」な結果に過ぎないんじゃね
で、今問題なのは
「主問い合わせのフェッチ順が副問い合わせのorder by順」
なのは実装なのか仕様なのかって話なんだが
(主問い合わせの出力順が主問い合わせのフェッチ順通りかどうかは別の問題)

ま、どっちにしても個別DBMSの話だから続きはオラクルスレでやってくれればいいけど

656NAME IS NULL2017/10/11(水) 22:37:12.18ID:f/rcAUbh
不思議なのは、Oracleがインラインビューにorder byの仕様をあとから追加して並び順を付けたのに、なぜ並び順が不定と言い張っているのか?

最近のマニュアルはどんどん表現が変わって、Oracle Databaseの歴史まで間違いを埋め込んでいる。

いまでも使われているバージョンなのに誤情報が書かれているから、仕方がない側面もある。

オラクル社がわけのわからない外国に仕事を投げてたり、データベースに詳しくない人間に仕事をさせるからおかしくなる。

657NAME IS NULL2017/10/11(水) 22:47:13.81ID:f/rcAUbh
>>655
それはOracleの構文が実装に近いから、標準SQLや他のRDBMSのSQLと比べるとそう感じるだけだと思うよ。

ソートはSELECTがネストするのに、構文ではネストしてないように見せているから初心者はそう思ってしまう。

結合もそうだけど、結合するとループのネストが発生することも知らないプロも多い。

あまりにしつこいから、時間があったら、実行計画を書くよ。

658NAME IS NULL2017/10/11(水) 22:52:23.83ID:???
サブクエリでorderby使えるようにしているオラクルがバカなんだよ
オラクルなんて使うなよ

659NAME IS NULL2017/10/11(水) 23:01:27.64ID:???
>>654
別に決め付けてはないだろ
オラクル社のサポートチームの主張が間違ってて
自称オラクルエンジニアの主張が正しいことも可能性としてはゼロではないと思ってるよ
だからきちんとした根拠を提示しろって言ってんの

でも散々的はずれなことを書いてきて
やっと提示されたソースが>>627みたいなレベルだから
今のところ誰も信用しない

660NAME IS NULL2017/10/11(水) 23:07:57.30ID:???
サポートチームという言葉は間違ってたか
どちらにしろThomas Kyteが間違ってて君が正しいという根拠があるんなら出してみれば

661NAME IS NULL2017/10/11(水) 23:08:39.27ID:9hHhkBSp
>>655←わかったけど意地はってる人
>>659←まだわかってないバカw

662NAME IS NULL2017/10/11(水) 23:33:27.61ID:???
Oracleスレに行かないのはOracleスレにもっと詳しい人がいるからやろなぁ

663NAME IS NULL2017/10/11(水) 23:35:44.56ID:???
>>661
はあww
馬鹿が追加されたか…

パッケージソフトにおける外部仕様と内部実装の違いの意味を理解してないから
内部実装について延々と無駄レスしてんだろ

664NAME IS NULL2017/10/11(水) 23:42:53.58ID:???
>>657
まさかと思うけど、一般的なRDBMSの実行計画で結合はネステッドループしかないと思ってるわけじゃないよな
で、オラクルがサブクエリのデータを扱う方法が、サブクエリの順序を保障した方法しか選択しない仕様なのかどうかの問題だと思うんだが

>>658
多くのRDBMSでサブクエリのOrder Byは意味を持つようになってると思うけどな
ただしそのサブクエリ内でトップなりオフセットなり取るっていう前提で
rownumみたいにそのサブクエリ内ではOrder Byに影響されない変な疑似列使うのが悪いだけで
昔ならともかく今どき書くべきクエリじゃないなと
ORACLEにはそんな過去のバッドノウハウがいっぱいあるけどな

>>661
別に意地張ってるわけでもなんでもなくて、初めから仕様か実装かって話をしてたはずなんだがね
その区別すらついてないから実装をグダグダと説明してたのかね

665NAME IS NULL2017/10/12(木) 00:57:57.42ID:???
マニュアルは信用ならん!
AskTOMの回答は間違ってる!!
俺が正しい!!!

またすごいのが来たね
ジャイアンも真っ青

666NAME IS NULL2017/10/12(木) 07:17:49.81ID:aeNA2Xqu
残念、やっぱり>>664も本質的にはバカだったかw

667NAME IS NULL2017/10/12(木) 09:09:43.10ID:???
あえて最初の質問>>583に改めて答えてみる。

まず、>>583は構文が間違っているので以下のように直す。
(SELECT句でつける別名はWHERE句では使えない。)

SELECT t.*, ROWNUM as num FROM ( SELECT * FROM 学生別点数テーブル ORDER BY 点数 DESC ) t WHERE ROWNUM <= 10;

このとき、WHERE句のROWNUMは副問合せ内のORDER BYの順序で振られる。
これはマニュアルに明確に書かれている。

しかし、このSELECT文全体の結果が副問合せ内のORDER BYの順序で
返されることは保証されていない。

もっと言えばSELECT句のROWNUMがWHERE句のROWNUMと同じになるとも限らない。
WHERE句を評価した後、SELECT句を評価するまでの間に
順序を変えてはいけないと決まっているわけではなく、
順序が変わればROWNUMも変わる可能性がある。
(副問合せを評価した後、主問合せのWHERE句を評価するまでの間にも
 同じことが言えるが、これはOracleが自分でマニュアルで規定している。)

668NAME IS NULL2017/10/12(木) 10:33:15.96ID:???
オラクルなんてオワコンじゃん

669NAME IS NULL2017/10/12(木) 10:52:48.57ID:???
もうしつこいなぁ
オラクル社に問い合わせろよ

670NAME IS NULL2017/10/12(木) 12:11:07.06ID:+PtNHGsI
>>667
あなたの考えだと、インラインビューの並び順指定をわざわざ付けたのは、ROWNUMのためという主張になるが自分でもおかしいと思わないのか?

どうもSQLがどう処理されているのかをあまり知らないからそんなヘンテコな発想になる。

副問い合わせの結果セットの並び順が不定なら、結合もグループ化もできないことになる。

671NAME IS NULL2017/10/12(木) 13:25:32.95ID:???
>>670
SQLがどう処理されてるかと、仕様として保証する動作かどうかは関係ない
それすら分からわないから一人でヘンテコりんな珍回答を繰り返す

672NAME IS NULL2017/10/12(木) 13:32:29.69ID:???
まあしかし、メーカーに「保障された実装」とメーカーが発表した「仕様」でどれほどの違いがあるのかという
保障された実装というものを考えると実装の区別もどうでもよくね

つうことでこの話終わりにしようぜ

673NAME IS NULL2017/10/12(木) 13:51:13.06ID:???
>>670
>副問い合わせの結果セットの並び順が不定なら、結合もグループ化もできないことになる。
ここでいう不定って、もとのORDER BY以外の順序の可能性があるってことで
たとえばハッシュジョインならハッシュキー順に、ソートマージならその結合キー順にならんでる可能性があるんじゃないかね

674NAME IS NULL2017/10/12(木) 15:17:56.52ID:???
>>672
保証な
guarantee

675NAME IS NULL2017/10/12(木) 16:01:26.35ID:???
>>672
仕様として約束された動作でなければ断りなく変わりうるから
明確にアナウンスされる仕様変更とはベンダー側もユーザー側も対応が違ってくる
その違いが重要じゃないと言い切れる場合を除いて区別は必須

676NAME IS NULL2017/10/12(木) 19:29:31.58ID:+PtNHGsI
>>673
もともとの質問者はリレーショナルデータベースでは、ORDER BYしないかぎりはレコードの並び順は保証しないという仕様から疑問に思っただけだと思われる。

内部的にソートが発生するSQLだったり、並び順があるインデックスが使用されたり、たまたま実際のデータ格納順が同じで、ORDER BYがあってもなくても結果が同じなのと、RDBMSの仕様はまったく異なる話。

そもそもORDER BYは、結果に対する並び替え指示だから、イメージとしてはSELECTを二度行っているようなもの。

6775832017/10/12(木) 22:02:19.61ID:???
>>583の元の質問をさせてもらった者ですが、話が大きくなり申し訳ありません。
議論を止める権利などは無いと思いますが、
私個人の問題としては(一旦は)解決しているので報告させて頂きます。

678NAME IS NULL2017/10/12(木) 22:24:52.35ID:???
律儀やね

ORDER BY ROWNUM じゃなく
ORDER BY 点数 DESC って書いておくといいよ
サブクエリ内と同じ表現ね

6795832017/10/13(金) 20:31:05.81ID:???
>>678
ありがとうございます。今後、修正する際は気をつけます。

また、幾つかのレスで「Row_number()を使えば」とアドバイス頂いています。
仰るとおりで、Row_number()であれば心配しなくて済みそうですが、
何年も前に客先に納品しているシステムでして勝手に修正は難しい状況です。
作るときに気が付いて欲しかったなあ・・・

680NAME IS NULL2017/10/13(金) 21:01:00.17ID:e4fuwytS
いい加減オラクルスレでやれっつてんだ、このクソボケ

681NAME IS NULL2017/10/13(金) 21:10:10.49ID:???
こんな過疎板でキレることじゃねーだろww
約1名を除いてwww

682NAME IS NULL2017/10/13(金) 21:47:24.19ID:98IUocac
>>679 の発言を見てるとまだ勘違いしてるようだな。

683NAME IS NULL2017/10/13(金) 22:19:00.51ID:npPDgh/r
バカを誘うんじゃない

684NAME IS NULL2017/10/16(月) 07:42:36.81ID:???
よ〜し今年中にSQL理解できるようになるぞ〜(^〜^)
よろしく!

685NAME IS NULL2017/10/16(月) 12:48:05.00ID:???
よろチクビ!

686NAME IS NULL2017/10/16(月) 18:58:20.24ID:???
ジャン=ポール・サルトルさんとデニス・リッチーさんはどっちの方が天才ですか?

687NAME IS NULL2017/10/16(月) 19:15:13.08ID:???
アングロサクソンは最強の人種ですか?

688NAME IS NULL2017/10/16(月) 22:11:05.74ID:???
いいえ、サモア人が人類最強です。

689NAME IS NULL2017/10/20(金) 19:21:50.59ID:???
SQL超初心者です。
特定の列を主キーにする場合、主キーの名前をその列名と同じにすると何か問題出ますか?
主キーはどんな名前がお勧めですか?

690NAME IS NULL2017/10/20(金) 19:35:23.02ID:MhmtGzT7
>>689
そんな疑問持ったことなかったなw何も考えずにPK_hageとかしてたけどw
おまえセンスいいかもw

691NAME IS NULL2017/10/20(金) 19:43:24.93ID:???
主キーは常に'id'だわ

692NAME IS NULL2017/10/20(金) 20:11:16.04ID:???
>>691
なぜですか?

693NAME IS NULL2017/10/20(金) 20:13:02.86ID:???
>>690
PK_派とid派が有るんですか?

694NAME IS NULL2017/10/20(金) 20:42:11.14ID:???
>>689
制約には名前をつけることができるが
主キー制約の場合はテーブル毎に一個しか持てないので
名前をつけようがつけまいが利便性は特に変わらない
(ので、主キー制約自体に名前をつけることは通常ない)

695NAME IS NULL2017/10/20(金) 20:56:42.26ID:RTm/vvXY
>>694
名前の無い主キーを作成出来るのですか?

696NAME IS NULL2017/10/20(金) 20:59:41.26ID:???
主キーの名前って言えば普通は列名のこと
PK制約の名前とは別だよ

CREATE TABLE Persons (
ID int NOT NULL PRIMARY KEY,



↑こう書けばDBMSで規定されてる命名ルール使ってPK制約名が付けられる

697NAME IS NULL2017/10/20(金) 21:06:42.39ID:RTm/vvXY
>>696
「主キー制約」と「PRIMARY KEY 制約」は別物と言う意味に解釈できるのですが、
それで良いのでしょうか?

698NAME IS NULL2017/10/20(金) 21:06:52.62ID:aE0VLgo8
>>694
名前のない主キー制約はない。

699NAME IS NULL2017/10/20(金) 21:07:57.48ID:aE0VLgo8
>>697
それは日本語で言うか英語で言うかの違いで同じ

700NAME IS NULL2017/10/20(金) 21:11:53.19ID:???
制約に名前をつけなかった場合、OracleならSYS_○○、
DB2ならSQL○○など、システムが勝手につける名前がつく

701NAME IS NULL2017/10/20(金) 21:12:38.46ID:aE0VLgo8
>>697
主キー列(カラム)は、そのテーブルで主キー制約がある列(カラム)のこと。

単に主キーというひとが多いからよくない。

主キー列はただの列名。主キー制約名は主キー制約名。

主キー制約に名前をつけなくてRDBMSが自動的に名前をつけるが、プロなら管理の都合上、ちゃんと名前をつける。

702NAME IS NULL2017/10/20(金) 21:13:24.76ID:???
CREATE TABLE Persons (

PRIMARY KEY (ID)


こう書いても同じでDBが自動で名前を付けてくれる

703NAME IS NULL2017/10/20(金) 21:14:37.36ID:???
また自称プロかよww

704NAME IS NULL2017/10/20(金) 21:14:42.93ID:???
>>697
主キー制約 = PRIMARY KEY 制約 だよ。(主キー=PRIMARY KEY)
ひとつの列が主キーであるなら、その列の名前=主キーの名前、という理解でよい

主キーの名前の付け方にはいろいろな流儀があるが、
SQLを利用するフレームワーク (例えば Ruby on Rails)との関係で
id という名前にすることが最近は多い
>>690 が書いているように、pk_hage みたいな人も多い
(「サロゲートキー」で検索するといろいろ出てくるはず)

705NAME IS NULL2017/10/20(金) 21:16:35.15ID:???
>>704
PK_hageはプライマリキー制約の名前で列名じゃないよ

7067042017/10/20(金) 21:17:18.37ID:???
>>702 が書いているように、
RDBMSに主キーの値を自動的に割り振らせたいようなときにも
列名を id とする

707NAME IS NULL2017/10/20(金) 21:17:18.87ID:aE0VLgo8
たぶん主キー制約名で一番多い命名は、PK_(テーブル名)。

7087042017/10/20(金) 21:18:46.46ID:???
>>705
制約名にすることが多いけど、列名にする人もいる
(質問者はそのあたりがごっちゃになっているっぽいけど)

709NAME IS NULL2017/10/20(金) 21:18:51.27ID:???
制約名と列名を混同している人がいるな
複合キーの場合どうすると思ってるんだ?

710NAME IS NULL2017/10/20(金) 21:20:15.43ID:aE0VLgo8
ただ"ID"という名前の列を作って主キー項目にするのは、たいしたデータベースを必要としていない人の習慣。

711NAME IS NULL2017/10/20(金) 21:21:47.38ID:???
>>710
それは言い過ぎじゃないかな

712NAME IS NULL2017/10/20(金) 21:22:24.90ID:aE0VLgo8
主キー列名、主キー制約名、インデックス名がちゃんと説明できるレベルの人は、この板にはほとんどいない。

713NAME IS NULL2017/10/20(金) 21:23:54.08ID:???
create table hoge (id integer primary key)
とした場合、制約名はシステムが勝手につけた名前になる

create table hoge (id integer constraint hage primary key)
とすると制約名はhageとなる

714NAME IS NULL2017/10/20(金) 21:25:43.33ID:aE0VLgo8
>>711
SQLは同じ名前の列は、同じ属性と見なすから標準SQLでもナチュラルジョインがあるわけで、良いはずがない。

715NAME IS NULL2017/10/20(金) 21:27:31.82ID:aE0VLgo8
>>713
あんたどのRDBMSの方言で説明してんの?

716NAME IS NULL2017/10/20(金) 21:28:23.02ID:???
>>708
お、そう
それはアンチパターンだね

>>710
トレードオフだからね
君はそれを知らないだけ

717NAME IS NULL2017/10/20(金) 21:30:12.14ID:???
もう自称プロに火つけんなよ

718NAME IS NULL2017/10/20(金) 21:31:14.77ID:???
ああ、order byの人か

719NAME IS NULL2017/10/20(金) 21:36:03.97ID:aE0VLgo8
>>716
何がトレードオフだよ。自分自身の関心事かそうでないかだろ。

有名なフレームワークやパッケージでもDBにうといのか、ひどい設計はよくある。

720NAME IS NULL2017/10/20(金) 22:02:38.96ID:???
>>708
ごっちゃにはなっていません。
最初の質問に書いたように列名と主キー名をあえて同じにすると何か困る事が有るかどうかを知りたかったのです。私はPK_派です。

721NAME IS NULL2017/10/20(金) 22:05:07.71ID:???
>>720
「主キー名」って何を指しているの? 主キー制約の名前?

722NAME IS NULL2017/10/20(金) 22:14:21.97ID:???
>>721
そうでした。

723NAME IS NULL2017/10/20(金) 22:20:44.01ID:???
制約名は重要なものじゃないから自動でつけられるだろ。制約だけ削除したい時にしか使われないと思う。
だから好きにすればいい。

724NAME IS NULL2017/10/20(金) 22:20:54.61ID:???
>>722
なるほど。その言葉の使い分けはとても重要なので今後気をつけてー

725NAME IS NULL2017/10/20(金) 22:28:05.26ID:???
>>713を知らなかった人が数名は居るってことか

726NAME IS NULL2017/10/20(金) 23:12:05.89ID:???
>>720
主キー制約のことを単に「主キー」とは呼ばないから
それだけは覚えといてよ

727NAME IS NULL2017/10/20(金) 23:15:46.29ID:???
試したことも試そうと思ったことも無いけど、制約名ってカラム名とかぶっても大丈夫なのか?
それと他のテーブルとかぶっても良いのか?
SQLServerの2008R2だと
>制約名は、テーブルが所属するスキーマ内で一意である必要があります。
って書いてあるんだが

728NAME IS NULL2017/10/20(金) 23:22:56.23ID:VNmP8QHa
だめだから自動のはSYS_連番とかになってるよね
自動付与のやつだとキー重複とかでエラーになったとき
エラーログとかでぱっとわからないからPK_表名にしてる。

インデックスの名前付けにいつも悩む。
表とか列とかつなげてくと長くなるし・・

729NAME IS NULL2017/10/20(金) 23:26:27.26ID:???
>>727
制約名同士でぶつかるなって話だよ
http://sqlfiddle.com/#!6/bacd6/1/0

730NAME IS NULL2017/10/21(土) 00:02:55.18ID:???
自称プロはOracleしか知らなそうだし、Oracle知らなそう

731NAME IS NULL2017/10/21(土) 00:50:01.04ID:Eth7MdL6
>>730
自分は意味のあることは書かず、他人批判、もっと言えば第三者から見ても嫌なやつと思われる言動をするのは、よほどひねくれているぞ。

732NAME IS NULL2017/10/21(土) 00:54:59.44ID:Eth7MdL6
>>723
制約が重要でない?

まあ汎用機世代の人間がテーブル名もカラム名も重要ではないと言うのと同じ感覚なのか?

733NAME IS NULL2017/10/21(土) 05:29:00.71ID:???
>>728
そもそもの>>689の話は、制約名を列名と同じにするって話じゃなかったのか
できるDBある?そんなことはできないで終わりの話じゃないのか

734NAME IS NULL2017/10/21(土) 08:11:31.61ID:???
DMLで多用するテーブル名、カラム名と基本的にDDLでしか使用しない制約名、インデックス名とじゃ
命名の重要度が違うのは当然だろう。

735NAME IS NULL2017/10/21(土) 09:00:42.05ID:???
>>731
批判に見えましたか!
自覚があるんやなぁ

736NAME IS NULL2017/10/21(土) 09:46:12.90ID:y12hXRx2
案の定質問の意味すらわからない奴が答えたがって場を荒すいつものパターンw

737NAME IS NULL2017/10/21(土) 09:51:46.91ID:???
それID見えてるやつのせいで起きるんだよなぁ

738NAME IS NULL2017/10/21(土) 09:58:25.58ID:y12hXRx2
>>737
他人のせいすんなクズw

739NAME IS NULL2017/10/21(土) 18:51:28.16ID:???
>>733
だいたいどのDBMSでもできるよ

740NAME IS NULL2017/10/21(土) 22:04:08.59ID:???
確かにID無しだけ見ると平和な良スレだな

>>733
できるのか
できるということはシステム的には問題ないって事だな
分かりにくくなったり手間が増えるかもしれんが

じゃあ、PK列名を全テーブルに対してユニークにする派の人なら
PK制約名をPKのカラム名と同じにするでもいいんじゃね
複合主キーどうするとかあるけどな

主キーは全部”ID”派の人はしらん
まあそう言う人は主キー制約の名前なんてそれこそ自動付加でいいんだろう

>>741
PKはテーブルに一つなのと制約名で重複しちゃダメなDBMSがほとんどなので
自動付与じゃなければPK_tablenameみたいにテーブル名を入れといたほうがいい
インデックスと違ってPK制約名からどの列がPKなのかを知りたいって人いないよね?

それに他の制約名と違ってPK制約名は意識的に扱うことが基本ないから自動付与で十分なことが多い
SQL ServerやPostgresなんかは自動付与でも分かりやすい名前になる

743名無しさん@そうだ選挙に行こう! Go to vote!2017/10/22(日) 19:04:47.81ID:B6C5gZpT
今回初めて知って嬉しいのはわかるけどこんなにいつまでも引っ張るような話題ではない

744NAME IS NULL2017/10/22(日) 20:01:12.98ID:???
はいはい
自称プロなら管理の都合上、ちゃんと名前つける( ー`дー´)キリッ
だもんねww

745NAME IS NULL2017/10/22(日) 20:58:53.03ID:???
話題としては意味はあるけど、SQL質疑応答スレでやる内容ではないな

746NAME IS NULL2017/10/22(日) 22:38:37.90ID:B6C5gZpT
あまのじやくやのうw

747NAME IS NULL2017/10/22(日) 23:05:36.02ID:hqoDUL2z
すっごい不評なegov法令検索を設計したのは名古屋大学の外山教授ですか?
不評過ぎます

748NAME IS NULL2017/10/22(日) 23:07:02.13ID:hqoDUL2z
すっごい不評な法令検索つくったくせに賞をもらっている意味不明な教授ですか?

749NAME IS NULL2017/10/22(日) 23:53:08.71ID:???
データベース板でID見えてるやつは地雷であり荒らしよ
無視推奨

750NAME IS NULL2017/10/23(月) 00:27:40.32ID:mf1jBI9V
豊田真由子様に罵倒されたい

751NAME IS NULL2017/10/23(月) 13:55:18.88ID:???
JavaでSQL書いてRDB使いまくりたいんですがそうなるためにこれ読んどけ見たいなのありませんか?
DBにデータを記憶するのはもちろんDBから数値や文字列を取り出してjava側で変数に代入したりして使いこなせるようになりたいです。

752NAME IS NULL2017/10/23(月) 15:29:30.92ID:CzSV0ugc
>>751
そのRDBが何なのか?

753NAME IS NULL2017/10/23(月) 15:53:41.99ID:???
>>751
JDBCの使いかたはわかってる?

754NAME IS NULL2017/10/23(月) 17:30:16.82ID:???
>>752
どれ使って良いかよく解らないんですが今はスッキリ解るシリーズのSQLの本読んでます。
MySQLかpostgreSQLがよさそうだなと思いますがSQLserverの無料版もよさそうだなと思って迷ってます。
>>753
使い方はよく解りませんがJDBCって言うの使えばどのDBMSでも多少ルールが違えど似たような扱いができるんですよね?
スッキリ解るシリーズの実戦編に少し書いてあった気がしますがほんの少しだけだった気がします。
なんかJavaとDBの連携した使い方がみっちりつまった本ってありませんか?初学者でもわかるようなので・・・

755NAME IS NULL2017/10/23(月) 17:33:48.73ID:ZhgI//rN
その選択肢はWindowsで動かす予定かな
DBはDBで単体でまず扱えるようにならないとあとあときついよ

756NAME IS NULL2017/10/23(月) 17:46:09.06ID:???
>>754
Javaデータアクセス実践講座

中で使ってるのはMySQL

javaとSQLがそれぞれわかっていることが前提条件になっているとは思う
一応これでJavaからMySQLに接続してどうのこうのってのは出来るようになった。

757NAME IS NULL2017/10/23(月) 20:14:17.85ID:mf1jBI9V
Javaというより、RDBの勉強の方がいいと思うけどな。JavaとRDBのやり取りは、知らないフレームワークを介さないのであれば難しいわけではない。

758NAME IS NULL2017/10/23(月) 20:48:54.31ID:???
>>757
>知らないフレームワークを介さないのであれば

学ばないでいつ知るんだよw
JDBCならともかくHibernateにしろSpring Data JPAにしろ
中身を把握するにはそれ相応の学習コストが必要

759NAME IS NULL2017/10/23(月) 21:09:51.32ID:mf1jBI9V
>>758
JDBC以外は全部、Java EEじゃないんですけど?

JDBCと言ってるのにいきなり謎のフレームワークを使えとはトレーナーとしてもありえない。

760NAME IS NULL2017/10/24(火) 01:31:44.05ID:???
謎のフレームワーク?

761NAME IS NULL2017/10/24(火) 02:12:17.03ID:Ftk4ZC9L
>>754 は超初心者だぜ?

762NAME IS NULL2017/10/24(火) 07:23:26.08ID:???
>>756
ありがとうございます。その本買ってみます。

763NAME IS NULL2017/10/24(火) 16:01:08.70ID:???
>>759
トレーナーとして?
プロの次はトレーナー

764NAME IS NULL2017/10/26(木) 00:31:39.63ID:Z3UH5ceX
なんでそんなにプロにつっかかるん?
ふいんき悪くなるからやめたら?

765NAME IS NULL2017/10/27(金) 10:04:02.60ID:???
SQL初心者です。
カラムをNULL許容型にするのは良くないと言った説明をいろんなサイトで見ます。
実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか?
DBを使いまくっている専門家の人の意見をお聞かせください。

766NAME IS NULL2017/10/27(金) 10:41:51.90ID:???
>>765
専門家じゃないけど

> カラムをNULL許容型にするのは良くないと言った説明をいろんなサイトで見ます。
必要ないなら非許容にするべき
理由は一番下のリンク先とかを読んでみて

> 実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか?
そのケースなら俺は普通に使う
ただNULLの扱いは初心者にはちょっと直感に反するところがあるから注意が必要
https://codezine.jp/article/detail/532

7672017/10/27(金) 10:46:26.58ID:KUE3Fyml
これは・・・・・面白い!!!
https://blogs.yahoo.co.jp/antseq01/15073181.html

768NAME IS NULL2017/10/27(金) 11:19:35.89ID:7pjSfMZX
>>765
リレーショナルデータベースではデータがない、値がないことを単にNULLと定義しているので、勘違いしないように。

769NAME IS NULL2017/10/27(金) 11:41:03.34ID:???
自分はNULL活用してるけどな

0や空文字 と 未定義(未入力) とは意味合いが違う
フラグを別に設けるのも嫌だし

最近は言語側でも int? n; みたいなことが出来るようになって嬉しい

770NAME IS NULL2017/10/27(金) 11:48:09.91ID:???
インデックスがねぇ

771NAME IS NULL2017/10/27(金) 11:55:53.32ID:7pjSfMZX
>>770
NULLを検索するという設計がおかしい。

772NAME IS NULL2017/10/27(金) 12:42:08.79ID:???
あれ、WHERE 項目 IS NULL ってインデックス効かないの?

773NAME IS NULL2017/10/27(金) 14:49:04.82ID:???
NULLを検索する設計がおかしいとは思わんが
インデックスが効くかどうかはDBMSによる

774NAME IS NULL2017/10/27(金) 14:52:48.92ID:???
「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの?

775NAME IS NULL2017/10/27(金) 14:54:13.98ID:7pjSfMZX
NULLを検索が多発している時点で考え方がおかしい。

776NAME IS NULL2017/10/27(金) 14:58:18.06ID:7pjSfMZX
>>774
言わんとすることはわかるが、なんで未入力とわかっている状態を検索して再度、確認する設計なのか?

777NAME IS NULL2017/10/27(金) 14:59:19.82ID:???
だから、「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの?
机上じゃなくて現実の運用場面を経験したことないのか?

778NAME IS NULL2017/10/27(金) 15:01:04.60ID:???
>>776
完全に入力が完了しないとコミットできない仕様(打ちかけを許容しない仕様)は
ちょっとユーザーフレンドリーじゃないと思うよ?

779NAME IS NULL2017/10/27(金) 15:24:58.30ID:7pjSfMZX
>>777
そもそもNOT NULLにしなくてはいけないと思い込んでいる初心者の話だろうが?

780NAME IS NULL2017/10/27(金) 16:22:16.25ID:???
>>765
バグを生みやすいからNOT NULLにできるんならそうしたほうがいい
といっても全部排除するにはそれなりの手間がかかるので落とし所を決める必要がある

単にデータが無い状態を表現する場合じゃなく
データが「まだ」無い状態を表現する場合にNULLがよく使われる
簡単にデフォルト値が決められるようなものはNULL許容にしない

781NAME IS NULL2017/10/27(金) 16:40:52.06ID:???
>>778
入力完了済みのデータと入力途中のデータを一つのテーブルで管理するなら
完了済みかどうかの状態を管理するカラムを用意してそれを検索するんじゃないの?
特定のカラムがNULLだからXXという状態だと判断するって方法は極力避けたほうがいいと思うよ

782NAME IS NULL2017/10/27(金) 16:53:00.08ID:7pjSfMZX
>>780
変なこと言うな

783NAME IS NULL2017/10/27(金) 16:55:39.17ID:7pjSfMZX
NULL許容はC#用語か。RDB用語で言ってくれ。不親切。

784NAME IS NULL2017/10/27(金) 18:42:11.20ID:???
>>764
この流れを見れば
ふいんき悪くしてるのが誰かアホでも分かるよね?

785NAME IS NULL2017/10/27(金) 18:51:51.10ID:7pjSfMZX
>>784
相当な小心者だな

786NAME IS NULL2017/10/27(金) 18:53:20.75ID:???
この質問、例の人の自演だろ
あんま相手しないほうが良さそう

787NAME IS NULL2017/10/27(金) 18:53:29.86ID:???
はーい!ID :7pjSfMZX君でーす!!

788NAME IS NULL2017/10/27(金) 19:21:39.36ID:???
nullはminとかmaxとかの集計関数で無視したい場合とか
更新が必要な項目で未更新状態の意味合いで使うな

789NAME IS NULL2017/10/27(金) 20:01:02.67ID:???
そういえばオラクルはキー項目でもnull許可できる糞仕様だったな
またオラクル使いか

790NAME IS NULL2017/10/27(金) 20:47:43.07ID:???
Oracleでもさすがに主キーにNULLは入らない
外部キーには入るがそれは別に普通のこと

それよりOracleは長さゼロの文字列とNULLが同じ意味になるという
糞仕様をいつまでも捨てられずにいることが問題

791NAME IS NULL2017/10/27(金) 20:50:02.76ID:n2vV1nnl
>>790
地雷だな、それって

792NAME IS NULL2017/10/27(金) 21:07:35.53ID:???
ま〜たこうやって、ボラクルの話になっていくのであった。

793NAME IS NULL2017/10/27(金) 21:31:19.54ID:???
>>788
>nullはminとかmaxとかの集計関数で無視したい場合
条件で絞ればいいだけじゃないの?

794NAME IS NULL2017/10/27(金) 22:49:58.72ID:???
正規化してテーブルを増やしてデータの一貫性を保ちやすくするのは解ったんですが
テーブル増やしたらデータを追加するとき複雑になりませんか?
あっちのテーブルに日付情報入れて利用者IDいれてこっちのテーブルに金額入れてとか混乱しそうな気がしますが

795NAME IS NULL2017/10/28(土) 00:43:45.46ID:SXU3olx1
>>784
え?ふいんき悪いのか?アホ的には?

796NAME IS NULL2017/10/28(土) 04:44:21.82ID:???
NULL使わない人はデータが無い状態をどうやって表現するのですか?

797NAME IS NULL2017/10/28(土) 06:49:50.86ID:???
リレーションを分ける

798NAME IS NULL2017/10/28(土) 08:02:48.10ID:???
NULLは必要だよ。
例えば日付型の生年月日があるとして、
NOT NULL なら default値はどうすんの?

799NAME IS NULL2017/10/28(土) 08:28:03.58ID:???
>>797
kwsk

800NAME IS NULL2017/10/28(土) 08:50:09.46ID:???
create table T (
pkey int primary key,
a int not null,
b int null
)

こんなリレーションなら下のように分ける

create table TA (
pkey int primary key,
a int not null
)

create table TB (
pkey int primary key,
b int not null
)

元のaがnot nullでbがnullという条件はTBからTAへの外部参照制約で表現できる

801NAME IS NULL2017/10/28(土) 11:10:00.12ID:qpJvhhHo
>>800
それは方言のじゃないのか?

802NAME IS NULL2017/10/28(土) 11:28:57.57ID:???
どこのこと?

803NAME IS NULL2017/10/28(土) 11:37:56.32ID:???
>>800
いちいちそんな面倒なことやってんの?

804NAME IS NULL2017/10/28(土) 12:35:01.35ID:???
NOT NULL縛りの是非はともかく、手間としては正規化とたいして違わない気がするが。
正規化を「いちいちそんな面倒なこと」と言う奴は少ないだろう。

805NAME IS NULL2017/10/28(土) 12:58:56.42ID:???
違うだろ〜
ハゲ〜

806NAME IS NULL2017/10/28(土) 13:31:18.62ID:???
null 可能列が10個あったら表が10個増えるのか w
まあ頑張れやとかしか言えない

807NAME IS NULL2017/10/28(土) 14:56:15.88ID:???
単純に10個増えるとは限らないよ

派生関係でうまく処理できる場合もあるけど
任意項目があるたびに派生関係を作っていくのはあまり現実的ではないよね

808NAME IS NULL2017/10/28(土) 15:58:18.89ID:???
思いつきでアホなこと言ったばかりに言い訳が苦しいなw

8098072017/10/28(土) 16:39:43.64ID:???
>>808
俺は派生関係提示したやつと別人だぞ

810NAME IS NULL2017/10/28(土) 19:05:25.10ID:???
>>800
で、外部結合して結局項目bがNULLになるのな

811NAME IS NULL2017/10/28(土) 19:34:58.65ID:Nv4Gn8Ik
ID 強制表示に出来ないのかな

812NAME IS NULL2017/10/28(土) 19:51:25.60ID:???
>>810
ならなかったらそもそも>>796への答にはならんだろ

813NAME IS NULL2017/10/28(土) 19:58:00.37ID:SXU3olx1
そもそも「データが無い状態」という情報をどうしても記録しておかなければいけない状況ってのはそうそうない
そのシステムの性質にもよるけど

814NAME IS NULL2017/10/28(土) 20:06:21.77ID:???
閉世界が前提だから、「データがある」状態だけ記録しておけばそれが存在しなければ「無い」だと思うが。
明示的に「無い」ことを記録しているわけじゃないだろう。

815NAME IS NULL2017/10/28(土) 20:55:50.54ID:SXU3olx1
>>814
いやそういう禅問答的な屁理屈を言われても「その通りですね」としか言えんけどw
何か反論したい事でもあるの?

816NAME IS NULL2017/10/28(土) 21:10:26.14ID:???
>>812
外部結合の結果とはいえ、デーが無い場合はNULLになるってことだ
直接テーブルに入れてないとは言えNULL使ってるわけだから>>796の回答足り得てないと思うけど?

817NAME IS NULL2017/10/28(土) 21:19:58.09ID:???
>>815
データが無いことを記録する必要があるかどうかという問い自体がナンセンスということ。

818NAME IS NULL2017/10/28(土) 21:22:55.68ID:???
>>812
それってb列に直接null入れるとのたいして違わなくね?

819NAME IS NULL2017/10/28(土) 21:29:12.67ID:???
>>816
NOT NULLにしたとしても外部結合したらNULL発生しうるじゃん
そうすると>>796への回答足り得ないの?

820NAME IS NULL2017/10/28(土) 21:30:47.78ID:???
派生関係はNULLを使わないために導入するものじゃないから話が噛み合わないのかもね

821NAME IS NULL2017/10/28(土) 21:38:29.64ID:SXU3olx1
>>817
ん?つまりnot null制約自体の存在を否定したいのか?

822NAME IS NULL2017/10/28(土) 21:59:40.59ID:???
「データが無いことを記録する」手段が唯一NULL許可フィールドのみなのであれば
NOT NULL制約と関係なくはないのかもしれんが、まぁ、関係ないよな。

823NAME IS NULL2017/10/28(土) 22:05:56.46ID:SXU3olx1
>>822
いや論じる事がナンセンスなんだろ?
その事と関係あるとかないとか唯一とか関係ないよね?
お前は何を言いたいの?

824NAME IS NULL2017/10/28(土) 22:16:58.96ID:???
質問者の>>796、とりあえずどうにか話の方向をどうにかしてくれよ。
nullの話は簡単に結論が出るようなもんじゃないんで、いつまでも続けられても鬱陶しいだけなんだ

825NAME IS NULL2017/10/28(土) 22:30:08.58ID:???
人と違ったことを言わないと気がすまない人っているね
俺は俺はってw

826NAME IS NULL2017/10/28(土) 22:41:07.11ID:???
こんな過疎スレで話が続いても誰も困らんだろ
それより質問者を含めスレ読んでるやつが
多くの選択肢を知ることができるほうが意義があると思うぞ

827NAME IS NULL2017/10/28(土) 22:50:23.13ID:???
禅問答は傍で見ているとうざいが、かといってテーブル10個作るのは面倒だなんてレベルの話ばっかりでもなぁ。

828NAME IS NULL2017/10/28(土) 23:15:38.46ID:???
>>823
「必要性があるとないとにかかわらず、意図的に「記録」するまでもなく、
「データが無い状態」というのはデータベース上のデータ自体で表現される
ものだから、>>813で書いている言明はそもそも意味がない」

本来なら「その通りですね」で終わってた話。

829NAME IS NULL2017/10/28(土) 23:23:38.74ID:SXU3olx1
>>828
いやだから何を言いたいのお前?w

830NAME IS NULL2017/10/28(土) 23:25:21.73ID:???
>>827
おまえの頭が低レベルすぎるだけ

831NAME IS NULL2017/10/29(日) 00:03:43.84ID:???
>>827
無意味なテーブル作るのなんか、たとえ1個でも願い下げだわ
作るのが面倒とか以前の問題

832NAME IS NULL2017/10/29(日) 03:06:41.55ID:???
>>819
>>796は、NULL使わない場合を想定した質問だぞ
データがない場合はNULLですだと、そもそもの質問の前提が成り立ってない
>>820
>NULL使わない人はデータが無い状態をどうやって表現するのですか?
に対する答えとして派生関係を出してきたはずだが
>>828
意図的にデータがない状態を記録するのに、NULLを使う手法はありかなしかって話をしてたんだと思うけど
そんな要件は現実的にあり得ないってならまあその意見もわからんではないが
実際のシステム設計じゃままある要件なんだがな

いい加減スレ違いなのは確かだし、これ以上は設計スレあたりで

833NAME IS NULL2017/10/29(日) 05:22:45.25ID:???
ちょっとした疑問なんだが、

ユーザーと所属するグループ、チームを表すテーブルを作る場合、カラムの命名についてはどっちが主流なんだい?

パターン1

テーブル:group_table
カラム:id,name

テーブル:team_table
カラム:id,name

テーブル:user_table
カラム:id,name,group_id,team_id

結合:

select
group.name as group_name,
team.name as team_name,
user.name as user_name
from
user_table as user
inner join group_table as group
on group.id=user.group_id
inner join team_table as team
on team.id=user.team_id

パターン2

テーブル:group_table
カラム:group_id,group_name

テーブル:team_table
カラム:team_id,team_name

テーブル:user_table
カラム:user_id,user_name,group_id,team_id

結合:

select
group.group_name as group_name,
team.team_name as team_name,
user.name as user_name
from
user_table as user
inner join group_table as group
on group.group_id=user.group_id
inner join team_table as team
on team.team_id=user.team_id

テーブル構成がおかしいとか、on句の書き方が気にくわないとか色々あるだろうけど、一先ず置いといて、
命名として、どっちなんだろうなと思って

834NAME IS NULL2017/10/29(日) 08:05:20.25ID:???
>>836
JOINの結果NULLが現れるから回答になってないってのはさすが屁理屈が過ぎるだろう。
>>796の前まではフィールドのNOT NULL制約について話していたわけだし、>>796
それを踏まえた質問ととらえるのが自然。

835NAME IS NULL2017/10/29(日) 10:01:25.63ID:???
>>833
どっちが主流かは知らんけど俺はパターン1

836NAME IS NULL2017/10/29(日) 22:04:41.05ID:???
>>833
プライマリキーとそれ以外のカラムでは扱いが違う
プライマリキー以外のカラムにテーブル名を単純なプリフィクスとして使う人は少ない

プライマリキーについてはDBよりの人はuser_id派が多めな印象
アプリよりの人はid派が多い印象(言語やフレームワークにもよるが)

個人的にはuser_id派

837NAME IS NULL2017/10/29(日) 22:26:54.40ID:???
>>835
>>836
サンクス

後だしで悪いが、
idはpk、
pk以外のカラムについては、name以外の話はなしでおなしゃす。
(nameはこうするとかのみで)

話が膨らんでしまうと発散して意味を成さなくなるので。

ちなみに自分はパターン2派。
関連がが分かりやすいので。

けれども、パターン1でも、テーブル名から予測可能だし、そもそも関連については外部キーで定義しろよと思うので、思想の話かなと。

職場でも、両派いるので、時流はどちらなのか知りたい次第です

838NAME IS NULL2017/10/29(日) 22:27:51.25ID:???
id派は基本的に全テーブルのプライマリキーをidという名前にする前提なので
単に命名の問題じゃなく設計に関わってくる問題

この辺読んで両方の意見を参考にするといいと思う
https://softwareengineering.stackexchange.com/questions/114728/

idじゃなくbug_idにしようぜってのがSQLアンチパターンにも出てくる

839NAME IS NULL2017/10/29(日) 22:38:13.88ID:???
>>838
サンクス

参考も読ませてもらうよ。

そんなあなたは、設計も命名も自由にできるとして、どっちにするの?

840NAME IS NULL2017/10/29(日) 23:49:53.10ID:???
>>839

>>838>>836 と同一人物だよ

841NAME IS NULL2017/10/30(月) 00:29:10.74ID:???
>>840
そうなんか。すまん。

842NAME IS NULL2017/10/30(月) 17:06:44.22ID:???
>>833
状況によるんでどっちが主流とか無いんじゃね

ORマッパーとか前提で、IDやSQLをあまり意識しないでいいなら1

生SQL扱うなら、本来の考え方からいけば2だろうな

843NAME IS NULL2017/10/30(月) 21:20:22.79ID:bh4tIMwn
SQL Serverの管理ビューは1で
Oracleのデータディクショナリは2だな
他のDBMSはどうだろう

844NAME IS NULL2017/10/30(月) 22:29:55.78ID:???
>>842
なにそのオレオレ本来の考え方って?

845NAME IS NULL2017/10/30(月) 22:34:48.02ID:???
論理レベルで複合キーやナチュラルキーのテーブルを
物理レベルでどう扱いたいかが重要な分岐点

846NAME IS NULL2017/10/31(火) 02:45:10.98ID:???
>>844
同じものには同じ名前をつける
違うものには違う名前をつける
これが原則

たとえば標準単価と販売単価を、同じ単価と言う項目名で定義するのはよろしくないだろ

ここ設計スレじゃないしこれ以上はどっか別のスレでよろしく

847NAME IS NULL2017/10/31(火) 06:28:26.89ID:???
>>846
何で列名だけで判断してるんだ?
標準価格.単価 と 販売価格.単価 が同じものに見えるなら病院に行った方がいい

848NAME IS NULL2017/10/31(火) 07:03:48.58ID:1FOujQPV
先入観に汚染されてるなw

849NAME IS NULL2017/10/31(火) 07:07:19.92ID:???
>>847
なんだこのバカw

850NAME IS NULL2017/10/31(火) 11:39:03.51ID:IzoEenp0
>>847
それはRDBの考え方ではない。

851NAME IS NULL2017/10/31(火) 13:26:32.03ID:???
そんな紛らわしいこと実務でやる奴いたら、とっちめられるぞ

852NAME IS NULL2017/10/31(火) 13:46:14.10ID:???
>>846
何をもって同じとするのか
何をもって違うとするのかの基準が違うから
id派とuser_id派に分かれるんだよね

例えば各テーブルに内部的な管理用としてレコードの更新日時を記録する場合
最終更新日時とかの名前でどのテーブルも同じカラム名でも別におかしくない
レコードの更新日時という意味で同じだから
id派の考えはその延長

853NAME IS NULL2017/10/31(火) 14:13:44.10ID:???
create table T (
nk1 int PK, -- nk = Natural Key
nk2 int PK,
nk3 int PK,
nk4 int PK,
a int not null,
b int null,
c int null
)

create table TA (
nk1 int PK,
nk2 int PK,
nk3 int PK,
nk4 int PK,
a int not null
)

create table TB (
nk1 int PK,
nk2 int PK,
nk3 int PK,
nk4 int PK,
b int not null
)

create table TC (
nk1 int PK,
nk2 int PK,
nk3 int PK,
nk4 int PK,
c int not null
)

854NAME IS NULL2017/10/31(火) 14:48:11.62ID:IzoEenp0
>>852
無理矢理すぎる理屈だな。

登録・更新者、登録・更新日時の項目は、結合項目として使用するなどどいう話は、あなたの中でもないだろうに。

855NAME IS NULL2017/10/31(火) 15:56:39.69ID:HRkll2T3
そうかなあ
テーブル名もカラム名の属性を表してるわけで
テーブル名をテキトーにつけてなけりゃ
情報の一部だべ

856NAME IS NULL2017/10/31(火) 16:15:00.47ID:???
>標準価格.単価 と 販売価格.単価
テーブル名まで書くんだったら、最初から
>標準価格 と 販売価格
で良いんでは

857NAME IS NULL2017/10/31(火) 16:32:16.66ID:IzoEenp0
>>855
テーブルの論理名はエンティティ名といって、適当に名前をつけていたら、混乱するだけでよいことはない。

858NAME IS NULL2017/10/31(火) 16:33:04.70ID:IzoEenp0
>>856
彼はオブシェクト指向とごっちゃになっているのだろう。

859NAME IS NULL2017/10/31(火) 16:53:50.50ID:???
価格というテーブルがあって

商品:外部参照(商品マスタの主キーを参照)
適用開始:日付型
適用終了:日付型
区分:0:標準 1:販売
通貨記号:USD/JPY・・・
単価:通貨型

という感じに定義されていて
標準価格や販売価格が実はテーブルじゃなくて、
価格テーブルを元にしたビューだった

という風なら理解できるぞい

860NAME IS NULL2017/10/31(火) 19:43:13.45ID:mnuaDWX/
>>859
価格というテーブルには、
標準価格か販売価格のどちらかしか
入らなくなりませんか?

861NAME IS NULL2017/10/31(火) 21:27:26.45ID:???
user_id派は昔ながらのリレーショナルモデル、id派はERモデルの発想だろう。
そのへん区別できてない人も多いけどな。

862NAME IS NULL2017/10/31(火) 21:34:56.59ID:???
>>849-850
爺は早めにくたばれよ w

>>856
テーブル名書かないの?
単一テーブルしか扱わない時はいいけど複数テーブル使ってる時にテーブル名を書かないとかその方がどうかしてると思うけど

>>858
はあ?
ひょっとして
ドットで繋いでる⇒オブジェクト指向
とでも思ってるのかよ w
全然関係ないだろ

863NAME IS NULL2017/10/31(火) 21:55:51.92ID:???
>>859
そのケースで標準価格と販売価格を一つのテーブルで管理するメリットって何?

864NAME IS NULL2017/10/31(火) 23:26:42.95ID:???
>>861
リレーショナルモデルとERモデルの違いについて、簡単にで良いので説明してくれ

865NAME IS NULL2017/10/31(火) 23:35:15.40ID:???
>>862
>複数テーブル使ってる時にテーブル名を書かないとかその方がどうかしてる
複数テーブル使うときにテーブル名で「修飾」しないで済むようにしましょう、ってのが根本にあるわけで
そのためにjoinにusingとかあるんだが

まあなかなか現実的にはそうすると項目名がやたら冗長になったりするから適当なとこで妥協するんだけどね
個人的な感覚では
標準単価なんかは妥協する必要のない範疇
更新日時なんかは妥協して問題のない範疇
IDなんかが議論の分かれるとこなんでよく話題にされる

まあ、宗教論だよ

866NAME IS NULL2017/11/01(水) 00:15:01.89ID:???
>>865
>標準単価なんかは妥協する必要のない範疇
>更新日時なんかは妥協して問題のない範疇

この線引を明文化して規約にしないと
同じデータベース内でブレた命名基準が使われて
一番使いにくい物ができあがる

867NAME IS NULL2017/11/01(水) 00:34:36.48ID:???
更新日時は文字通り誰が解釈しても一意になりそう
標準単価は、何を指すのかな?
商品なら、定価だったり、希望小売価格だったり
賃金なら、時間給か日給か月給?
その現場毎に決めるんだろうな

868NAME IS NULL2017/11/01(水) 00:50:55.07ID:???
>>852に書いてるようなデータベース上のレコード最終更新日時と
ドメインで意味がある更新日時(サイト更新日時とかスレ更新日時とか)だと解釈違ってくるよね

システム的な事情で「スレ」テーブルのデータを更新した場合でも
ユーザーが目にするスレ更新日時は更新されない事も有り得る

869NAME IS NULL2017/11/01(水) 08:01:28.84ID:???
>>864
先に属性があって、それらの間に何らかの関係が存在するときにそれをリレーション(テーブル)として
表現するのがリレーショナルモデル。属性はテーブル固有ではないのでそれ自身識別できる名前に
することが多い。
問題領域からエンティティを抽出してそれに含まれる属性を記述するのがERモデル。基本的に
属性はそのエンティティ固有のものだから他のエンティティと属性の名前が重複しても気にしない。
ただしERモデルをRDBに落とし込む際は他エンティティとの関係を表す参照フィールドが必要になる
場合があるが、これはそのエンティティに属するものとは言えないため必ずしも一貫性はない。

870NAME IS NULL2017/11/01(水) 11:14:37.77ID:???
c1,c2,...,c10と言う10個のカラムがあって、その中のどこかにkeywordが有るか判定するなら
c1 like %keyword% or c2 like ...
みたいに10個並べればいいですよね。
ではkeyword1とkeyword2が有るかどうか判定するなら同じくずらずらと条件を並べるしか無いですか?
もっとスマートに簡潔に書く方法は有りますか?

871NAME IS NULL2017/11/01(水) 11:35:10.09ID:/cVJI5F/
>>870
連結してしまう

872NAME IS NULL2017/11/01(水) 11:41:59.82ID:???
>>871
なるほど。
実際の開発の現場でもそういう手法を使うんですか?
ずらずら並べる方法と連結する方法とでは、どっちが検索が速いでしょうか?

873NAME IS NULL2017/11/01(水) 12:58:59.43ID:???
LIKE検索の時点で似たり寄ったりだし
どうしても早くしたいなら全文検索エンジンとか使え
http://www.clear-code.com/blog/2015/5/25.html

874NAME IS NULL2017/11/01(水) 17:01:39.42ID:???
>>870
クエリの見た目のキレイさだけならJOINの条件でLIKEを使う方法もある
パフォーマンスは一般的に良くない

外部結合使った例
SELECT *
FROM target t
LEFT JOIN keyword k1 ON t.c1 LIKE k1.col
LEFT JOIN keyword k2 ON t.c2 LIKE k2.col
LEFT JOIN keyword k3 ON t.c2 LIKE k3.col
WHERE k1.col IS NOT NULL
OR k2.col IS NOT NULL
OR k3.col IS NOT NULL ;

内部結合使う場合は結合条件をORでつないでカラムを並べるかUNIONするか

875NAME IS NULL2017/11/01(水) 20:23:03.03ID:33PRYza3
>>870
そんなSQLが必要なテーブルがおそろしいわ。

876NAME IS NULL2017/11/01(水) 20:41:04.71ID:???
c1...c10が等価で交換可能なのだとしたらそもそも第1正規形じゃないから実際の開発の現場で見かけるのは稀。
等価じゃないのに「その中のどこか」なんて問い合わせするのも稀。
「実際の開発の現場」じゃまず現れないレアケースなんで「スマートに」なんて期待するな。

877NAME IS NULL2017/11/01(水) 21:12:22.61ID:Rn9wp9k8
>>875,876
正しい設計のデータベースにも普通にありふれたテーブルですよ
経験不足なんですねあなた達

878NAME IS NULL2017/11/01(水) 21:19:00.00ID:???
君のスルー力が試される

879NAME IS NULL2017/11/01(水) 21:19:46.82ID:???
自分が面倒見ているサイトで
ユーザーにアイテム検索させる時に
このようなSQL書いてるな

880NAME IS NULL2017/11/01(水) 21:29:21.89ID:???
結局それは全文検索系ってことだよね

881NAME IS NULL2017/11/01(水) 21:51:43.96ID:33PRYza3
そんな面倒なのを非手続き型SQLでやろうとする発想がすごい。

882NAME IS NULL2017/11/01(水) 21:52:04.29ID:???
>>876
バカ設計はどこにでもある。稀じゃない。

883NAME IS NULL2017/11/02(木) 08:11:45.62ID:???
>>876
例えば社員情報を氏名、役職、所属、電話番号、社員番号の一部で検索するとか普通にあるけど?

884NAME IS NULL2017/11/02(木) 09:50:05.16ID:???
>>874
すみません、このコードを試してみたのですが外部結合など
初めてやるので実行するとエラーしました(SQL ServerとMySQL)。
このサンプルコードは、完全なSQL文ですか?
それとも概略を示したものですか?

885NAME IS NULL2017/11/02(木) 10:41:39.48ID:t1XvRAES
>>884
SQLがいいか悪いかを無視しても少なくともLIKEの前にANDがない。

886NAME IS NULL2017/11/02(木) 11:25:24.57ID:???
ん?

887NAME IS NULL2017/11/02(木) 12:38:26.10ID:SmP+Tevx
シンタックスすら覚束ないのに善し悪しを語りたがるバカw

888NAME IS NULL2017/11/02(木) 15:24:23.12ID:t1XvRAES
ああ、間違ってるな。

ただあのSQLのkeywordとはなんだろうな。

889NAME IS NULL2017/11/02(木) 16:17:17.63ID:???
>>884
何をもって完全とするかは君にしかわからないけど
SQL ServerでもMySQLでも問題なく動くよ

外部結合もやったことなくて何のエラーが出たかも分からないようなら
自分の今のレベルを素直に受け入れてLIKEでベタ書きするのがスマートだと思うよ

890NAME IS NULL2017/11/02(木) 17:18:04.94ID:???
>>874
ウンコード・マニアがSQLに対応していたらかなりいい点が貰えそう

891NAME IS NULL2017/11/02(木) 21:03:08.49ID:4yCYhJnd
なんだかよくわからないけどとりあえず煽ってみるウンコバカw

892NAME IS NULL2017/11/02(木) 21:47:39.63ID:441xfH76
このスレは想像、想定で回答する人間が多くて驚く。エスパーなのか?

893NAME IS NULL2017/11/02(木) 21:49:27.88ID:???
マミだよん

894NAME IS NULL2017/11/02(木) 22:43:38.19ID:441xfH76
案外おっさんがいるんだな。

エスパー魔美を連想するとは。

895NAME IS NULL2017/11/02(木) 23:24:16.53ID:???
mongoDBってSQLよりも簡単ですか?

896NAME IS NULL2017/11/03(金) 00:00:10.06ID:???
>>895
クエリ書くのはSQLのほうが簡単
MongoDBでクエリ書くのもそんな難しいわけじゃないけど
JavaScriptやmap/reduceの基本理解は必須

897NAME IS NULL2017/11/03(金) 00:58:43.23ID:7zJOPvVT
つまり簡単じゃんw

898NAME IS NULL2017/11/03(金) 02:53:53.20ID:???
簡単か難しいかは比較対象によるからね
SQLと比較すれば難しいし手間もかかる
SQLは全くの素人でも3日程度の研修受ければ
自分が欲しい結果を取得できるレベルにはすぐなれるが
JavaScriptだとそうはいかない

899NAME IS NULL2017/11/03(金) 03:03:46.70ID:???
SELECT cust_id, sum(amount)
FROM orders
WHERE status = 'A'
GROUP BY cust_id

上のSQLがmap/reduceだと↓ココにあるような関数になる
https://docs.mongodb.com/manual/aggregation/#map-reduce

他にもMongoでのクエリとSQLと比較してるドキュメントがたくさんあるから自分で見るといいと思う
https://docs.mongodb.com/manual/reference/sql-aggregation-comparison/#examples

900NAME IS NULL2017/11/03(金) 06:42:27.20ID:PR2/yxNu
スレ違い

901NAME IS NULL2017/11/03(金) 22:30:44.12ID:7zJOPvVT
つまり簡単じゃんw

902NAME IS NULL2017/11/03(金) 23:23:00.70ID:???
>>898
3日でSQLマスターするってスゲえな
どうやるんですか?

903NAME IS NULL2017/11/04(土) 00:50:07.98ID:???
>>902
マスターは言い過ぎ
文法を理解して自分が欲しい結果を取得するためのクエリが書けるようになるレベルな
ちゃんとした会社の研修コースを受ければいい

本で言えばスッキリのレベルなら2日コース
ゼロからはじめるのレベルなら3日コースが標準

904NAME IS NULL2017/11/04(土) 13:20:37.18ID:isarshv7
なぜsqlもmongodbも初心者レベルなのに答えようとするのか

905NAME IS NULL2017/11/05(日) 16:51:50.70ID:???
select ...
where カラム名 like '%'
みたいなwhere条件を追加した場合、このwhere条件が無い場合に比べて
検索時間が遅くなったりしますか?

906NAME IS NULL2017/11/05(日) 17:16:14.88ID:???
そりゃDBMSのオプティマイザの賢さ次第だな。試してみればいい。

907NAME IS NULL2017/11/05(日) 17:19:00.83ID:???
>>905
やってみなはれ。
やらなわからしまへんで。

鳥井信治郎

908NAME IS NULL2017/11/05(日) 18:19:41.67ID:???
で、遅くなったとして「じゃ条件つけるのやーめた」なんて出来るのか?

909NAME IS NULL2017/11/05(日) 19:19:45.88ID:???
クエリ組み立てる側で手間かければできないことないだろ。
もともと意味のない条件をつけるのがおかしいわけで。

910NAME IS NULL2017/11/05(日) 20:02:06.93ID:Fhmg/FV8
>>905
ただSQLだけで遅いの速いいうのはナンセンス。

911NAME IS NULL2017/11/05(日) 21:59:28.93ID:TKSEwyxb
どんなSQLだけだったら遅いの速いのいうのはナンセンスじゃないんだこれ?

912NAME IS NULL2017/11/06(月) 00:52:25.60ID:???
質問させてください

番号     住所
(number)  (address)
 1      東京
 2      大阪
 3      東京

住所でGROUP BYして番号順に並べたい
さらに住所の合計を取得したい

SELECT *,SUM(address) FROM table_addr GROUP BY address ORDER BY number DESC;
これだと番号順に並びません。どうしたらいいでしょうか?よろしくお願いします。

913NAME IS NULL2017/11/06(月) 01:23:28.40ID:???
番号順って、小さい順にしたいの?それとも大きい順?

9149122017/11/06(月) 01:33:13.19ID:???
>>913
レスありがとうございます
一応DESCですがASCでも構いません

915NAME IS NULL2017/11/06(月) 02:38:07.35ID:???
>>914
SELECT MAX(number) AS number, address, COUNT(address) AS kensu
FROM table_addr GROUP BY address ORDER BY MAX(number) DESC;

9169122017/11/06(月) 10:18:12.51ID:???
>>915
ありがとうございました

917NAME IS NULL2017/11/06(月) 12:54:15.84ID:OvWu3ceL
自作自演なのか?

なんでsumがカウントの間違いだとわかるのか?

918NAME IS NULL2017/11/06(月) 12:59:52.06ID:???
まあ住所の合計って意味わからんからな
よく気づいたと思うけど

919NAME IS NULL2017/11/06(月) 13:17:23.44ID:???
GROUP BY とORDER BYって同時にできるの?

920NAME IS NULL2017/11/06(月) 13:28:19.94ID:OvWu3ceL
>>919
グループ化したものを並び替えることはできる。

並び替えたものをグループ化しても意味がない。

921NAME IS NULL2017/11/06(月) 14:14:19.44ID:???
>>920
へえー
じゃあグループ化してないカラムを並び替えすることは出来る?

922NAME IS NULL2017/11/06(月) 14:16:34.60ID:OvWu3ceL
暇人だなw

923NAME IS NULL2017/11/06(月) 21:49:11.63ID:m9a7sHg6
笑ってごまかすんじゃない最後まで答えろ

924NAME IS NULL2017/11/06(月) 22:13:08.96ID:nRwHbJxK
変なのがずっと居座っていたのか。

925NAME IS NULL2017/11/06(月) 22:36:12.91ID:fjeBNiC4
>>923
俺のスキルじゃ無理

926NAME IS NULL2017/11/06(月) 23:11:44.01ID:m9a7sHg6
>>925
いやお前なら出来るはずだ

927NAME IS NULL2017/11/12(日) 08:40:38.51ID:???
SQLってcasesensitivitieじゃないんですよね?コマンドを小文字で書いても良いですか?
いちいちcapslock雄の面倒

928NAME IS NULL2017/11/12(日) 08:58:26.16ID:???
SQLって英単語の羅列で構造がぱっと見わかりにくいから、昔は予約語だけ大文字にするとかあったけど、
最近はエディタでハイライト(色分け)できるのが普通だから全部小文字でも全然問題ないな。

929NAME IS NULL2017/11/12(日) 09:13:40.39ID:???
小文字でも普通にオッケーなんですか

sqlite のクエリを書くのにpythonのIDE使ってるんでsintax highlightは効かないので見にくいかもしれない
一長一短すね

930NAME IS NULL2017/11/12(日) 11:08:21.18ID:???
使ったことあるのは oracle, SQL-Server, PostgreSQL, sqlite3, MySQL だけだけど、全部小文字でも問題なかったな

931NAME IS NULL2017/11/12(日) 13:00:50.96ID:bx2ZtZM+
>>929
初心者?

932NAME IS NULL2017/11/12(日) 13:04:49.71ID:???
一行に詰め込もうとかしなければ小文字でも読めるやろ

933NAME IS NULL2017/11/12(日) 14:09:18.93ID:???
英文(って言うかアルファベット)の大文字の綴りなんて、まず読みにくいだろ?

934NAME IS NULL2017/11/12(日) 14:14:09.39ID:???
大昔はコンソールから大文字しか打てなかった時代があった

935NAME IS NULL2017/11/12(日) 15:15:24.45ID:???
コボラーは今でも大文字なんだっけ

936NAME IS NULL2017/11/12(日) 15:30:51.57ID:???
COBOLも小文字
というかcase insensitiveやで

937NAME IS NULL2017/11/12(日) 15:32:09.97ID:???
COBOLは今は大文字小文字混じりだよ
FORTRANもね

SQLは特定の場所以外大文字小文字関係ない
内部では処理系によって大文字か小文字に変換して処理する

938NAME IS NULL2017/11/13(月) 20:56:12.44ID:YzugWzEj
板違いかもしれませんが、hirdb詳しい方いませんか?いたらhirdbのストアドが使い易いか教えて下さい。使ってるのみたことなくて…

939NAME IS NULL2017/11/13(月) 21:07:17.01ID:???
うっわかわいそうに

940NAME IS NULL2017/11/13(月) 21:08:07.96ID:Vp0kKm4r
>>938
ネットに公表されているマニュアルを見たのか?
ストアドは標準SQLだから標準SQLとかけ離れていることはない。

941NAME IS NULL2017/11/13(月) 21:23:35.97ID:vPFZRtjc
>>940
みました。標準的にみえるけど、あまり使われてないDBMSだから落とし穴がないかこわくて。そもそも自分がそんなにストアド使ったことないから判断しかねるのもあります。
それと、過去ログにはトリガー設定して自動で動くようにはできない??との記述もあって…

942NAME IS NULL2017/11/15(水) 03:09:42.05ID:0j2E8Ny1
sForm

943NAME IS NULL2017/12/12(火) 12:03:27.68ID:Gxq3LHR7
名前 年齢 住所の他にその人がどういう人なのか0個から複数の属性を持たせたいのですが
配列にするってのはデータベース的によくないんですよね?
そこは属性テーブルを別個作って
さらに属性と個人テーブルを関連付けさせるための関連付けテーブルを用意すればいいのでしょうか?

個人テーブル
 ID 1
 名前 山田太郎
 年齢 38
 住所 東京都

属性テーブル
 ID 1
 属性名 会社社長

関連テーブル
 ID 1
 個人ID 1
 属性ID 1

こんな感じですか?あと関連テーブルの個人IDと属性IDは外部キーでいいのでしょうか?

944NAME IS NULL2017/12/12(火) 14:35:32.23ID:???
変な感じ&#639;(。・&#604;・)&#638;

945NAME IS NULL2017/12/12(火) 16:13:02.05ID:???
1:nなら属性テーブルが直接個人IDもってても良いんじゃね

9469432017/12/12(火) 16:41:00.78ID:Gxq3LHR7
>>945
レスありがとうございます
なるほど
この情報が社内情報のようなものならそれでよさそうですね
実際はn:nの情報になります
外部キーはよくわからないのですが参照のようなもので
deleteされて整合性がとれなくなりそうなときにうまく解決してくれるようなものなのかなと
(子テーブルで親の参照がなくなることを警告出したり、整合性とるために削除したり?)
もうちょっと勉強してきます

947NAME IS NULL2017/12/12(火) 17:31:43.57ID:???
Googleのアドレス帳なんかは任意の項目が入力できるから
>>943みたいになってるんじゃないかな

948NAME IS NULL2017/12/12(火) 20:18:55.95ID:2NJ8QzBR
ほとんどの場合任意の属性を記録するのはシリアライズしたテキストで十分なんやで
オーバーエンジニアリングにならんように気いつけや

949NAME IS NULL2017/12/13(水) 10:32:20.73ID:???
NOSQLとかならわかるけどシリアライズしたテキストをRDBで使ったら負けかなと思ってる

950NAME IS NULL2017/12/13(水) 19:59:22.88ID:Gzldjtnr
逆だわwスキーマレスなNOSQLならなんぼでもオレオレ属性持てるやんw

951NAME IS NULL2017/12/14(木) 10:22:47.63ID:???
おまけみたいな項目だけテキストで持つとかでもええやん
ゼロイチ思考は損よ

952NAME IS NULL2017/12/14(木) 10:43:19.73ID:???
>>950
シリアライズしたテキストなんて曖昧なデータぶっこむのもOKだけど
RDB使ってんなら関係性重視したいよねっていう

953NAME IS NULL2017/12/14(木) 18:55:46.58ID:W31f7YBM
>>952
お前がやりたいなら止めはしないけどお前が重視したいらしい関係性て
おそらく関係モデルの関係とはなんも関係ない関係性やでw

954NAME IS NULL2017/12/15(金) 01:27:41.00ID:???
RDBじゃないDBMSの選択肢が極端に少ないって実情があるからな

955NAME IS NULL2017/12/15(金) 02:37:31.20ID:???
>おそらく関係モデルの関係とはなんも関係ない関係性やでw
それはない
正規化から勉強しなおしだな

956NAME IS NULL2017/12/15(金) 07:47:26.78ID:6QrkU8mN
>>955
いやあるからわざわざ言っとんのやでw
意固地のベイビーちゃんやなw

957NAME IS NULL2017/12/15(金) 12:49:28.67ID:???
>>955
要件もはっきりしてないのに
> それはない
って言い切る奴はバカ認定してもいいかな?

958NAME IS NULL2017/12/15(金) 15:11:25.84ID:???
しょせん他人事でどうでもいいことに熱くなるなよ

959NAME IS NULL2017/12/15(金) 16:58:53.39ID:???
奇をてらわずに>>943でいいじゃんな
スループット確保したいとか入力値が無法地帯でモデリングしようがないとか
そういう時に初めて検討すりゃいい

960NAME IS NULL2017/12/15(金) 17:09:24.86ID:???
>>957
それブーメラン

961NAME IS NULL2017/12/15(金) 17:18:42.86ID:???
KVS
 ID 1
 VALUE {
  "name": "山田太郎",
  "age": "35",
  "addr": "東京都",
  "attr": [
   
  ]
 }

これじゃRDBの意味がない

962NAME IS NULL2017/12/15(金) 17:21:46.72ID:???
KVS
 ID: 1
 VALUE: "山田太郎"
 ID: 2
 VALUE: "35"
 ID: 3
 VALUE: "東京都"

にすると扱うのが却って難しい

963NAME IS NULL2017/12/15(金) 21:41:32.93ID:???
>>960
えっ?
どこがブーメランなんだい?
ちょっと説明してみ

964NAME IS NULL2017/12/25(月) 08:23:47.10ID:Xetk2Fg1
MariaDB(MySQL)で質問です
Userテーブルがあり、各ユーザーはpointというint型のフィールドがあります
このpointの合計がx以上になる分だけのユーザーをソートして取得したいと考えています

色々と調べたり試行錯誤してみましたが限界を感じましたので
どうか皆様の知恵をおかしください。よろしくお願いします

965NAME IS NULL2017/12/25(月) 11:11:43.13ID:???
pointの合計ってなに?なんか計算をしたいの?

・Userテーブルがある
・各ユーザーはpointというフィールドを持つ

ちゃんとテーブルの構成を書かないとこれだけじゃよくわからない

966NAME IS NULL2017/12/25(月) 16:20:46.40ID:???
ユーザーIDでgroup by し sumでpointを集計
order by ユーザーID
んでhavingで sum(point) > x
みたいな?

967NAME IS NULL2017/12/25(月) 17:50:53.80ID:Xetk2Fg1
>>966
試してみます!

968NAME IS NULL2017/12/29(金) 11:02:39.55ID:dtNZwIie
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

J7FO55UASR

969NAME IS NULL2017/12/29(金) 17:11:12.15ID:???
>>968
でも、君あちこちにコピペしてて苦労してそうじゃん
もっと簡単に稼げるぞ

970NAME IS NULL2017/12/31(日) 07:10:08.80ID:???
where 句のIN演算子の書き方ってモヤっとしない?

971NAME IS NULL2018/01/01(月) 15:34:27.49ID:???
ID / 日付 / 値

という列があったとして(ID/日付でUNIQUE)、それぞれの各行に
「IDごとの前回の日付から遡って1年間の間に値が最大値となる日付」を付与するにはどうしたらいいでしょう?

A | 16-01-01 | 10
A | 16-11-01 | 20
A | 17-02-01 | 15
A | 17-12-01 | 10
A | 18-01-01 | 30
B | 17-03-01 | 15
B | 17-10-01 | 10
B | 17-11-01 | 20

とあったら、上からNULL、16-01-01、16-11-01、16-11-01、17-02-01、NULL、17-03-01、17-03-01が入るような列を追加するイメージです
Postgres使ってます

972NAME IS NULL2018/01/01(月) 15:57:02.83ID:???
>>971
>前回の日付から遡って1年間の間

頭悪くて済まないが、この意味がよく分からない

973NAME IS NULL2018/01/01(月) 16:20:06.66ID:???
>>972
言葉足らずでごめん
日付でソートした際の1つ前のレコードから遡って1年間

A | 16-01-01 | 10
A | 16-11-01 | 20

これだと、1行目はこの前の時点のデータがないからNULLで、
2行目のは1つ前のレコードである16-01-01から遡って1年間を集計期間にしたい

974NAME IS NULL2018/01/01(月) 21:04:00.89ID:iMl2Nb4o
いきなり最終形にしようとするからわからないんだろうな。

975NAME IS NULL2018/01/01(月) 21:30:53.28ID:???
少しずつ実現するのが近道部品を組み立てる組み立てるつもりで考えてみよう

9769712018/01/01(月) 22:29:55.07ID:???
SQLポンコツなんだ…
せめてヒントをくれるとありがたいです

977NAME IS NULL2018/01/01(月) 22:36:14.85ID:g9MeygUN
ID列でグループ化、日付列がcountで2レコード以上のレコードを取得して、日付が最小のレコードを取得する。

あなたのためにあえてSQLは書かない。

978NAME IS NULL2018/01/01(月) 23:05:35.41ID:???
>>971
sqlserverならこんな感じでできる
select * from (
select m.id ,m.日付,m.値,s.日付 as 最大値日付,row_number (partation by m.id,m.日付 order by m.値 desc) as 順
from テーブル as m
left join テーブル as s
on s.id = m.id
and s.日付 between deteadd (yy,-1,m.日付) and m.日付
) as mm
where 順 = 1

979NAME IS NULL2018/01/01(月) 23:08:58.34ID:g9MeygUN
ひどい例

980NAME IS NULL2018/01/02(火) 02:01:15.52ID:???
>>971
select *,
(select top 1 日付 from テーブル where テーブル.ID=前回の日付テーブル.id and テーブル.日付 <= 前回の日付テーブル.前回の日付 and テーブル.日付>DATEADD(yy,-1,前回の日付テーブル.前回の日付) order by 値 desc)
from(
select t.*,
(select top 1 日付 from テーブル where テーブル.ID=t.id and テーブル.日付 < t.日付 order by 日付 desc) as 前回の日付
from テーブル as t
) as 前回の日付テーブル

SQL Serverでやったけど、topと日付計算周りだけ直せば動くんじゃね
パーティション関数とかつかえるなら違う書き方もできるけど
>>978はtypo別にしてもいろいろ残念

981NAME IS NULL2018/01/02(火) 10:42:11.51ID:???
>>980
サブクエリにorder by使えないと思う
オラクルは使えるみたいだけど

982NAME IS NULL2018/01/02(火) 11:12:27.53ID:???
>>981
すいませんtop があればサブクエリでorderby 使える事知らなかった

983NAME IS NULL2018/01/02(火) 11:16:49.66ID:???
>>981
> サブクエリにorder by使えないと思う
SQL-Server 2005以降ならtopを指定してたら使える

984NAME IS NULL2018/01/02(火) 11:29:49.96ID:???
出来れば ostgres をベースに回答してやろうよ

9859712018/01/02(火) 15:04:26.15ID:???
みなさまありがとうございます
相関サブクエリ?で値でソートしたあとの最初のレコードを取ってくれば良いんですね
チャレンジしてみます

986NAME IS NULL2018/01/02(火) 16:06:45.83ID:???
>出来れば ostgres をベースに回答してやろうよ

Postgres ?
なんでPostgresなのかね

テンプレに
【質問テンプレ】
・DBMS名とバージョン
ってあるのにそれを書かない質問者の不手際だろ

987NAME IS NULL2018/01/02(火) 16:08:50.38ID:???
>>986
Postgres使ってます

988NAME IS NULL2018/01/02(火) 16:11:42.06ID:???
>>986
971にpostgresって書いてあるけど、 オストグレスは知らんが

989NAME IS NULL2018/01/02(火) 16:13:16.36ID:???
テンプレ通りではないが、
>>971の最後の行に
>Postgres使ってます
こうあるので

990NAME IS NULL2018/01/02(火) 16:14:09.12ID:???
Symfowareでよろ

991NAME IS NULL2018/01/03(水) 10:35:26.64ID:X70UaZKX
>>980 みたいなのを真に受けるなよ

992NAME IS NULL2018/01/03(水) 22:50:26.68ID:???
具体的な問題点を指摘できんなら黙っとけや

993NAME IS NULL2018/01/04(木) 12:53:23.31ID:49+pCNSV
>>992
select
from (select
group by
having count(*) > 1)
where

994NAME IS NULL2018/01/04(木) 15:47:10.27ID:???
>>993
何が言いたいのかわからない
>>980はすくなくともSQL Serverなら正しく動いた
DBMSによってはサブクエリのorder byとtop(limit)が効かないかもしれんが
ポスグレがそうならそう指摘して正しく動くSQL示せば良い話

995NAME IS NULL2018/01/04(木) 16:07:09.61ID:49+pCNSV
なんでそんなクソSQLをごり押ししたいのか?

996NAME IS NULL2018/01/04(木) 18:43:28.68ID:F4EONRA7
>>992
select
from (select id, min(日付)
from テーブル
group by id
having count(*) > 1)
where

997NAME IS NULL2018/01/04(木) 19:01:47.94ID:???
お前要件取り違えてるだろ

998NAME IS NULL2018/01/04(木) 20:10:33.27ID:F4EONRA7
日付から考えるからおかしくなる。

これがプログラムならそういう順序では考えない。

質問者の「ソート」という言葉に惑わされてるんだろうな。

999NAME IS NULL2018/01/04(木) 20:16:13.07ID:F4EONRA7
正確にはIDでグループ化した日付のMAXと、IDでグループ化したcountの結果の比較だけど、初めから答え書く気はない。

1000NAME IS NULL2018/01/04(木) 21:21:45.75ID:???
ume

10011001Over 1000Thread
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 542日 22時間 52分 44秒

10021002Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php

レス数が1000を超えています。これ以上書き込みはできません。