SQL質疑応答スレ 17問目 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
このスレは
「こういうことをやりたいんだけどSQLでどう書くの？」
「こういうSQLを書いたんだけどうまく動きません＞＜」
などの質問を受け付けるスレです。
SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。
質問するときはDBMS名を必ず付記してください。
【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明
前スレ：
SQL質疑応答スレ 16問目
http://echo.2ch.net/test/read.cgi/db/1447160858/ よくある質問１
（問）
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に対して最新の１件だけ抽出する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
; よくある質問２
（問）
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
; よくある質問３
（問）
ID HOGE
01 A
01 B
01 C
02 A
03 B
HOGEをAもBもCも持っている、ID：01だけ取り出すにはどうすればよかですか
（答１）
SELECT id
FROM TableName
WHERE hoge in ('A','B','C')
GROUP BY id
HAVING count(DISTINCT hoge) = 3
;
（答２）
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によって文法がかなり違うので注意 よくある質問４
（問）
列の数が可変な問合せはどう書きますか？
（答）
標準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 ううむ、ブロックされてしまいました。どうしたらいいだろう。
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. SQLソースの部分は外しておきます。
よくある質問５
（問）
年月(YYYYMM)を指定し、その年月に対応する年月日を取得したい
例：201006を指定したら、以下の結果を得たい
20100601
20100602
・
・
・
20100630
（答）
SQLでは存在しないデータを生成することはできません。
この問いの場合は素直にカレンダーテーブルを用意しましょう。
どうしてもやりたければ以下のような方法もなくはないですが、
再帰問合せの本来の使い方ではありません。
やめておくことを強くお奨めします。
（PostgreSQLのgenerate_series()関数なら辛うじてセーフかもしれませんが
賛否の分かれるところでしょう。） 以上、テンプレ終わり
よくある質問５のSQLソース部分がアタックと受け止められてしまいました。
そのためソースは省略しました。 ここで募集するのも筋違いだとおもうけど、SQLの文を書いたのを訂正してほしい・・・
中級者には30分ほどでおわる内容かも。
謝礼は7000で、
多分、チョー簡単。
詳しくは
remorse2015@yahoo.co.jp
日曜までとりあえず募集します。
メールで内容確認だけでも良いです/ >>12
お願いできないですか？
ワードに見本表と完成表があってコード書かれているんですが、間違えてる文がある感じです。22ページあったんですが16から全然進まなくて、、、
とりあえず、メールお願いします。
ワードファイル添付しておくります。
支払いはすぐやります。 ワードファイル送りつけられても迷惑メールからのゴミ箱インよ 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個くらいやれば終わりです。 金もらって引き受けるほどの仕事じゃないようだし
そういう手間かけるくらいなら、ご自身で治した方が良いのでは？ > SELECT *FROM 氏名表 AS A
> WHERE A.番号IN
> (SELECT 番号
> FROM 成績表
> WHERE 点数>=500)
これは何が間違ってるんだ？ >>16
inをjoinに置き換えろって話のようにみえるけど
joinしたビュー作っとけばもっと楽かもしれんぞ
そもそもそんなことする必要があるのか
一度inとjoinで実行計画見といた方が良いんじゃね
>>18
文法的に間違ってるってなら、番号とINの間に空白がないとかじゃねw これについてはインラインビュー(FROM句の副問い合わせ)はやめた方がいいな。
WHERE句で絞った方がいい。 実行計画見るまでもないレベルのデータ量な気がするが。
何やっても数百ms程度で戻る気が。 >>21
その理由は？
単なる性能的な話なら、まず実行計画見るよって事だし
whereがどうこうじゃなくて、inの方だと、結果セットに点数含まれないのが問題なんじゃないのか
>>23
データ量は示されてないし、実際のテーブルレイアウトがどうなってるかもわからんし
まあ、性能的な問題じゃないと思うけど >>24
> データ量は示されてないし、実際のテーブルレイアウトがどうなってるかもわからんし
> まあ、性能的な問題じゃないと思うけど
氏名表：1,000レコード未満
成績表：100,000レコード未満
くらいかなと。
まあどんなクエリ書こうがたいしたことないと思うが、性能云々ならindexを貼るくらいでいいのでは。 答えたい気持ちは分かるがお前ら7000円をどうやって分けるつもりなの？
そういう事は最初にキッチリ決めとかないと後々遺恨を残すぜ 僕のために争ってくれてありがとう。
依頼する人は見つけたから大丈夫だよー
これで単位も一安心 >>24
理由も何もまずはSQLの普通の書き方しろってことだよ。 >>24
INリストには数の制限があるからな。
OR条件の羅列にすぎない。 ↓これ何？
26 NAME IS NULL 2016/07/15(金) 18:52:57.55 ID:OwU9VU0D
答えたい気持ちは分かるがお前ら7000円をどうやって分けるつもりなの？
そういう事は最初にキッチリ決めとかないと後々遺恨を残すぜ すみません、以下、質問させてください。
親テーブルAに対して子テーブルBとCがあり、
レコード数がそれぞれ、
A:B = 1:5、A:C = 1:20 の関係です。
この時、A１レコードに対して、
Aに紐付くBとCのレコード全てを最小のIO回数・データ量で取得したいです。
普通にA、B、Cを結合しただけでは
B×Cの組み合わせまで取得してしまい上手く取得できませんでした。
A:B、A:Cと別々に結合して取得するしかないのでしょうか。
DBはOracleです、よろしくお願いします。 >>33
リレーションの説明がありませんので、答えようがありません。 B×Cの中から自分が欲しいものを条件で絞り込むんだよ。その条件が無いから全部出てくる。 >>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)
… 質問がいまいち理解できん
そもそもIOとか、SQL書いたとおりに実行されるわけじゃないんだが
ほしい結果がABとACの二つあるなら、２回やるしかないわけだが、どんな結果を望んでるんだ >>38
俺もI/Oについては突っ込みたかったが、そもそもRDBの理論、概念を否定する内容だからスルーしたw >>36
その3つのテーブルをaという列だけで結合すればいい話なのかな？
Aテーブルの1レコードに対して20レコードがセットになればいいの？ BテーブルとCテーブルにリレーション、関連性があるのかないのかはっきりしてくれ。
AテーブルのとあるレコードはBテーブルに子レコードがあり、Aテーブルの別の種類のレコードはCテーブルに子レコードがあるようにも解釈できる。
どっちなの？ >>44
それはRDBMSのことであって特定の製品を指しているわけでもない。 >>45
ワケ分からん事言ってないで必死でググって顔真っ赤にして感謝しろよw
今頃もう真っ赤っ赤かなw RDBMSはSQLの処理の方法にRDBMSに任せるのがRDBなんだよ。
どう処理するかの手続きを指定するのはするのはRDBではない。 とりあえず書き込む前に書こうまず読み直してとりあえず書こう 【BS11:エンターテイメント】 ＜関根勤 KADENの深い夜＞放送時間：毎週木曜日 よる11時00分〜11時30分 #bs11 http://www.bs11.jp/entertainment/5749/ ジョインで連結しまくったクエリに
ORDER BY で並び替えかけると
えらい遅くなるのですが
改善する方法はないのでしょうか？ ジョインしたかどうかとソートの速度に関係はない
ソートのキーとなる列にインデックスを張っておけばソートが不要になる場合がある
ソートキーが複数のテーブルに跨るとすると話は面倒臭い
VIEWにインデックスを張れるDBMSならそれで解決するのも手 >>53
インデックスの貼り方がわるいのか
リレーションに関するカラムを中心に
インデックスはっても遅いんです。
特に GROUP BY と ORDER BY の組みあわせ GROUP BYもあるならmaterialized viewにしてインデックス張るしかないかな
メモリをひたすら積んでメモリソートでごり押しという手もあるが テーブルレイアウトと実行してるSQL全部書けば
ある程度汎用的なインデックスのアドバイスができるかもしれんが
まあとりあえず実行計画確認しろ 【質問テンプレ】
・DBMS名とバージョン
この辺も書いておくといいぞ うちのダイニングのテーブルの配置はどう言ったらいいでしょうか 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｜
として、縦持ちにしたいとします。
問題は、この２つのテーブルをどうリレーションさせるかです。
例えば 次のようなレコードが入っているものを次のようにリレーションしようとします。
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件表示とか リストで出力すると この例では田中が３つでてきてしまうので
GROUP BY で ID をまとめます。
その際 ORDER BYをかけると 何千件とかになると
パフォーマンスが非常に落ちてしまいます。
※ ORDER BYがなければパフォーマンスはそれほど問題はありません。
パフォーマンスをなるべく落ちないように
縦持ちカラムを組み合わせるにはどうすればいいでしょうか？ それだとGROUP BYよりEXISTSのほうがよくね？
select T1のカラム
from T1
where exists (
select *
from T2
where T1.MAIN_ID = T2.MAIN_ID
and T2の条件
)
order by T1のカラム >62
>GROUP BY で ID をまとめます。
それだとIDと1:1に結び付かない項目は全て不定だぞ
つまり結局T1のみselectするのと同じになるわけだが
それならまずはT1のソート項目にインデックス張って見るとか
ああ、またMySqlか
SelectとGruop ByとOrder ByとWhereと全部書いたフルのSQL晒せ ない項目ってどういう意味だ？
インデックスは項目（の組み合わせ）に対して作るものだぞ 質問です。
学生メール表 学籍番号 氏名 メールアドレス
教員メール表 教員番号 氏名 メールアドレス
補習予定表 教員番号 授業id 日付 連絡事項
授業名表 授業iD 授業名
授業展開表 教員番号 授業id 学籍番号
これで生徒に知らせる時のER図をつくるとき、
いらない情報はどれですか？
学生メール表⇔授業中展開表⇔授業名表⇔補習予定表 >>67
必要最低限にしてもいいけど、実際にはいちいち結合しないと取得できないので重複して持つこともある。 ちなみに>>67はおかしいですか？
先生にしらせるときと生徒に知らせる時でER図を書きなさいって問題なんですが 問題に書いてあることを誤読や読み落とししている気がする。 まずER図書いてみろって話だが
エスパーすると授業展開表.教員番号か補習予定表.教員番号
各テーブルの主キーが不明なんでどっちにしろ正確な答えはだぜんぞ ・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
お知恵をお貸し下さい。
お願いします。 名前テーブルも作ってそれと外部結合すりゃいいじゃん。 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) 表示をその順序にしたいと言うなら、
その順序指定になるカラムを追加したら？ >>76
> これにdddを1の下に追加して
できない
上とか下の概念がないから 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 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; >>74
普通は名前のマスタテーブル用意しとくんじゃね
まあ、なければないで効率とか考えないなら
select distinct 名前 from ...
とかで代用できなくもないけど
>>76
すくなくとも、RDBでそれは基本的な考え方から外れてるから無理
データ補完とか、順序付けされてないデータの順序とか、設計考え直せ >>75,81
ありがとう。
75 で言われてハッとして distinct で作った名前の一覧と月の一覧とを掛け合わせて、
これと元のテーブルデータを外部結合して行けました。 SQLと直接関係ないのですが
お名前.comSDサーバーの データベースって
sshで入って dumpコマンドでエクスポートできないので
バックアップを取ることができないのですが
なにかうまく取る方法ないですか？ >>83
お名前.com sdサーバー データベース バックアップ
でググったらすぐに見つかったが？ ○前提
会社id、名前や所在地などが入っている会社テーブルと、
会社id、従業員名、性別などが入っている従業員テーブルがあるとして、
（プログラム側で外部から受け取った）会社idから名前や所在地を得て、かつ、その会社の従業員を列挙表示したい
○質問
こういうとき、DB側、SQL側としては、会社テーブル・従業員テーブルそれぞれ1回ずつ2回SELECT発行するしかないでしょうか >>85
joinを知らないとか分からないとか、そういうレベル？
とりあえず>>1読んで出直して >>86
joinすると全レコードに>>85で言う会社テーブルの名前、所在地などが入ってきませんか
返してもらうデータ量よりクエリ発行回数を気にするべきなんでしょうか
また>>85には書いていないことですがjoin対象が複数あったら、など考えるとどう考えたら良いのか >join対象が複数あったら、
複数joinすれば？ 深く考える前にやってみればいいんじゃないかな、とか。 >>87
>データ量よりクエリ発行回数を気にするべきなんでしょうか
そんなもんはケースバイケースだからすきにしろ
もともとクエリ発行回数を問題にしたのはお前だろうが >>85
その前提なら
> 会社テーブル・従業員テーブルそれぞれ1回ずつ2回SELECT発行する
でいいと思う この場合それぞれ2回ずつSELECTが正解じゃね？ 従業員に付与される会社情報の多さが気になるなら2回でいいんじゃね
というか自分も2回だね >>85
〇足りない情報
どんなときに使う処理か（バッチ？それともユーザー操作に対する応答？）
出力はどのような形式か（画面表示？CSVファイル？）
データベースを配置しているサーバーと出力を得るクライアントの構成は？（例：PostgreSQLto
Apacheが同じサーバーにあり、クライアントはWEB表示で結果を得る。サーバーはAWSに配置しており、ネットワークの転送速度は毎秒１MBr程度が期待できる）
レコードは何件あるのか。レコードあたりの容量は？要求されるレスポンスは？（1秒以内に出力完了など）。 転送速度が極端に遅い場合はローカルにデータベースをもってジョインするのも選択肢としてあり得なくもないが（2層方式も含めて検討だろう）
それだったら出力結果を圧縮して転送だろうな
HTTPで出力する場合は例えばgzip圧縮すりゃ設定いじる程度の工数で済むしな 月額2000円くらいの予算でvps借りるとしてmysqlで最大どれくらいのトランザクションを捌けるもんなの？ どこで質問したらわからないんですが総合スレってありませんかね？ Mysql で 出力データーを
20.00 → 20
21.40 → 21.4
23.05 → 23.05
20.10 → 20.1
みたいに少数以下の語尾のゼロを取ることをMySQL内ですることはできないでしょうか？ truncとかfloorとか
文字ならsubstrみたいなやつで アドバイスをいただきたく
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
)
/ >>109
/があるあたりでOracleだと思うが、なんで並列処理化するとか考えないの？ というか、ふつうにhoge=trim(hoge)で良い気がするんだが
なんで自己結合する必要があるんだ それか元のテーブルをRENAMEして
新しいテーブルにINSERT SELECTしたら？
表領域足りんのか 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';
という簡単な形で出せたのですが、時刻を指定する方法が分からず詰まっています。 >>113
and date_format(record, '%H:%i') between '09:00' and '12:00' >>114
できました！ありがとうございます！
date_format関数について勉強しておきます >>114
こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか? >>116
> こう言うのがササっと書けるようになるには何年くらいのSQL修行が必要ですか?
本読まないでしょ。
初心者でも入門書を2,3冊こなせば書けると思うよ。 短いやつをちょっとずつ書けば慣れるけど
MySQLの方言だからねえ、、、 確かにここのレスを見ただけだとササっと書いてるように思うのも仕方がないだろう
だけど……裏では必死でググってんだぜオレたち 👀
Rock54: Caution(BBR-MD5:8368d31ad5c810f9ab23ea9fefa156d2) >>117
入門書を二冊も読んだら上級者でしょ？
それもかなり上のクラスの sql初心者で2、3行程度の簡単なsqlしか実行した事がないんですが、世の中では何百行、何千行のsqlを実行する事もありますか？ 100行程度なら描いたことがある
メンテナンス性を考えると
あまり長くしないようがいいように思う >>122
相対的には上級者になるのかもねｗ
絶対的にはもちろん違うけど >>124
自分がかなり上のクラスの上級者であると自己判定していて、自分のクラスになるには入門書2冊が必要だった、ということかも 入門書を何冊読んでも入門書レベルの知識しかつかないという、ごくあたりまえの話 >>121
そんな複雑なやつを書く前にストアドとかビューを組み合わせるとかを検討する
そんなの書いたら検証がえらいことになる 聞いた話でそれを見たことはないけど、1000行くらいのが出来上がったとかなんとか。
見たくもない（ある証券系のシステムでのお話） 問い合わせ文じゃなくて、ややこしいストアド書くなら数百は余裕であり得るだろうけど 行が増えざるを得ない状況がストアド開発には多すぎるからなぁ
つまり複雑度はなぜ行が多いのか次第 >>121
カラム数が多くて、改行してたらあっという間。 >>131
> カラム数が多くて
それはそれでどうかと思うが... 二つのテーブルを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行とかいく。 カラム数はシステムが古かったり、考え方が古いひとが作ったものをだったりするとコントロールできない。 わざわざ1カラム1行でクエリ書いて行数多くてメンテナンス性落ちるなら本末転倒 >>137
>>134みたいなケースで言うと、行数が多くてメンテナンス性が落ちるということはない。
逆に、1行に複数カラムを羅列される方がメンテナンス性が落ちる。 お前らの言うメンテナンス性ってテキストの編集しやすさの事だったんかｗ >>140
保守、仕様変更でSQLの構文が書き直されるようなのは馬鹿のやることだろ。
リスク高すぎ。 可読性が低くてメンテナンス性は高いという状況が思いつかない >>141
>保守、仕様変更で
手を入れないといけないときは
なるべくSQL(ストアド)の変更だけで留めようと努力するけど違うのか >>143
> なるべくSQL(ストアド)の変更だけで留めようと努力するけど違うのか
QiitaをkickされたSQLおじさん信者か何かか？ >>145
SQLおじさんってどなた？
ORMおじさんは知ってたけど >>146
SQLおじさん、Qiitaに炎上記事投稿 周囲の反応と垢BANまでの流れ
http://togetter.com/li/1047474 教えてください
アクセスを使ってます
INSERT INTO 日時(日付,時刻)
SELECT 日付,時刻 FROM 日付,時刻
WHERE (日付,時刻) NOT IN(SELECT 日付,時刻 FROM 日時)
データをクロス結合して重複分を排除しつつ日時テーブルに書込みをしたいのですが、
上のSQLではエラーとなってしまいます
自分でも調べてはいるのですがどうにも分からず頼らせてもらえればと思います
よろしくお願いします それクロス集計じゃなくてただの直積じゃないのか…？ すみません、教えていただけますでしょうか。
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する形になると思うのですが、
よい方法があれば教えていただけないでしょうか。 >>154
もしかして"10.90.10"で一つの項目に入っていて
そのうちの"10.90"と突き合わせたいとかいう話？
leftとmid組み合わせるとかinstr使うとかlike使うとか、いくつかやり方は思いつくけど
悪いことは言わないからまずDB設計見直せ >>155 早速のレス、ありがとうございます。
>>もしかして すみません、なぜか切れてしまいました。
>>もしかして"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円
のような感じです。
データベース設計を見直したいのですが、もうシステムが動いてしまっていて、
変更がちょっと難しい状態なのです、、、
社内用のシステムでお客様で使っているものではないのが救いなのですが。 テーブルAに一列追加して
B用のキーを追加した方がいいぞ
キー列が変わることなんざ無いだろうし、insertするとこだけ弄ればいい
既にある列も３０分もありゃ出きるやろ
そしたら普通にインナージョインで処理できる >>158
それselect * してるやつがいたらこける可能性ある ＞社内用のシステムでお客様で使っているものではないのが救い
社内システムには直すお金がかけられないとかあるあるだけど
それ救いじゃなくて呪い（負債）だからな >>159
Accessの場合大分こけないはず
フォームとかではいちいちフィールド名指定するし
Select * のフィールド数不一致でエラー吐くパターンがむしろ想像できん
ソースは小規模Accessをフィールド建て増ししまくって用途10倍以上に増やした俺
まぁ、
A inner join B On A.ID like B.ID & '*'
でも動くだろうけど、ミスによるバグがクッソ増えそうだし嫌だわ わざわざ abczz じゃなく abdzz にしてる意図が気になるな >>162
likeしたときに
abc-とabcde-だと被るからじゃない？ >>157
> データベース設計を見直したいのですが、もうシステムが動いてしまっていて、
> 変更がちょっと難しい状態なのです、、、
正しいデータベース設計後、古いテーブルと同じ形式のViewを作ることができれば、
現行システムに影響を与えることなくデータベースの変更が可能。 >>165
view賛成
ま、弊社の場合はviewだらけで訳が分からなくなってるけどね（笑 >>157
クエリ追加したいってことは、少なくとも何らかの変更／追加があるわけで
そのうえでそのテーブルレイアウトで自分でクエリ書けないんだろ
だったらテーブルレイアウト直すべきだと思うけどね
ま、動いてて変えられんとかいう状況ならそのシステムに似たような事してるとこあるだろ
>>165-166
普通のDBMSならビューで逃げる手はあるけど、ACCESSって結構テーブルとクエリで扱い方に差があるからなぁ >>165
accessで困ってる初心者に追加可能な選択クエリとか書けるかっていう疑問はあるけど出来たらそれで良いかもね viewじゃ更新できないカラムのsqlあったらどうすんの oracleのmergeについて質問です。
oracleは11gを使っています。
とあるテーブルにmergeを使ってpkのレコードが無ければレコード追加、レコードがあれば何もしないというsqlがありました。
このようなsqlで行が無い場合はinsertと同じようにロックを取得すると思うのですが、
既に行がある場合ってロックは取得されるのでしょうか？
リファレンスを見ると細かいケースに言及せず、mergeの表ロックモードはsxとあるので、更新処理の有無に関わらずforupdateと同様にロックされるのかなぁと思っているのですが、、 【質問テンプレ】
・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の値を結合したいです。
よろしくお願いします。 group_concat()があれば簡単なのに
Access用にはDJoinという関数を作って公開してる人がいたみたいだけど
ページが消えてる AccessならVBAでID受け取ってNameをカンマ連結した文字列返す関数作ればできんじゃね >>174-177
返信おそくなってすみません
質問に不足してた部分があったので
また質問しなおしたいと思います
どうもありがとうございました ・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月までの会計年度の行を取りたいのですが、そのようなことは可能でしょうか お願いします select * from table where year*100+month between 201704 and 201803;
じゃだめか？ (year=2017 and month>=4) or (year=2018 and month<=3)でいいだろ IIf(Month<4,Year-1,Year) AS 会計年度
見たいなカラム持ったクエリ定義しとけよ あ、なぜかACCESSだと思ってたw
標準的なSQLならCASEでビューか
まあ、わかるだろ >>179
性能は知らん
where make_date(year, month, 1) between '2017-04-01' and '2018-03-31' 日付を分割してintに入れる糞実装、未だに存在するのかよ どうでもいいけど言うならせめて糞設計だよね
実装てｗ 設計：年・月を保存する
実装：年・月を別カラムにする number(8)に日付いれるのが好きなフレンズもいるな 俺は >>180 支持だなぁ
速度的にも見た目的にも >>180
会計年度中も指定できるので非常に参考になりました
他の方法も含めご教示ありがとうございます 年月を保持する要件で、データに意味を持たない日の情報が含まれるって、良いのでしょうか
バグを産む可能性を秘めてるような >>197
あり得ない月とかを突っ込める方が恐いわ >>198
そんなもんなんぼでもあるわwお前ビビりすぎw バグというより、データベースに事実にない情報を含めるとか違和感が numberでもバグを産む可能性を秘めてるし
どっちのリスクをとるかだけじゃね 年月のみを管理したいっていう場合に
・日付としての正当性は保証されるけど不要な日の情報を持つ
・日付としての正当性は保証されないけど不要な情報を持たない
のどちらがいいか？
って話でしょ
個人的にはデータの正当性の方を重視するかな そして2017/4/1と2017/4/2など
同一年月で複数レコードできてしまうのでした 年月情報をユニーク制約を保持する仕様で日付計算のためにdate使ってたら、皆さんはどう思いますか もうUNIQUE制約のある年月列と日付計算用の列を分けろよ レコードの入力時に日付が何入っていようと、1にしてしまえば良いだけだろう そんなもん制約がなければ全く信用できん
本当に頭が悪いなお前ら >>205
2017/00 とか 2017/13 とか入ってるのとどっちがいい？ 1日の0時になっているか確認するcheck制約つければいい そもそもカラムが年と月別なんだからcheck制約でもMonth>=1 and Month<=12でいいから簡単だろ
プログラムも同様
まさか日付を変換して1日かとかやるとか？
いらない情報付与からして、そんなのうちでは許されないわｗ >>182
後の人間を苦しめるコードをまき散らすのは止めよう 3年分取ってきてと言われて初めて問題に気付くパターンや where fiscal_year(year, month) = 2017
みたいな感じで関数使うかビュー使うほうがロジックが一箇所に集まっていい気がする
パフォーマンス気にするレベルならcalender yearとは別にfiscal yearをデータに持たせるかな あと fiscal_year(date) みたいにオーバーロードしとけば
インターフェースが統一されて使いやすい SQLにオーバーロードあるんですか？どんなRDB？ え、、、普通にあるでしょ
むしろできないDBってどれよ そうなんか、OracleとPostgreSQLで出来てるから普通なのかと・・・ てか、そもそもOracleでも単純なオーバーロードってあったっけ？ このケースはComputed Columnが使えればそれがいいと思うけど
Postgresでは使えないから関数オーバーロードしとくって話
Computed Columnなら使えるDB多いだろ
SQL標準ならView使えって話かもしれんがViewは管理上のオーバーヘッドが高くなる傾向があるから
使わなくてすむケースならなるべく使わないようにしてる >>228
会計年度を必要とするたびに繰り返し同じことをするのでよければね
年度別に集計したい場合とかしんどいし俺はごめんだわ 普通に関数でいいと思うんだが、あえて(関数?)オーバーロードって言ってるのはなんで？ >>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 つか、いたるところで会計年度を意識するようなシステムなら、会計年度カラムを作っとけばいいよな >>232
where句も入れて何回繰り返すのさ
面倒くさいとは思わないの？
単発の作業ならわからんでもないが会計年度みたいなのは1回じゃすまないだろ
>>231
日付型でデータを持ったテーブルがあったり
日付型に徐々に移行したい場合に同じ名前で扱えるとうれしいから
会計年度って概念をDBに反映させる一つの手段 >>234
> 面倒くさいとは思わないの？
いや、まったく
>>232レベルのクエリなら1０秒もかからずタイプできるだろ >>234
> where句も入れて何回繰り返すのさ
ストアドでも似たようなもんだろ。
select fiscal_year(year, month), sum(hoge) from fuga group by fiscal_year(year, month)
しかもストアド使うと、year, monthにインデックスあっても使われないし。 kantomi@qiita_banned < ストアド！ストアド！ >>235
面倒くさいと思わないならいいんじゃね
>>236
asで名前つけとけばgroup byでは繰り返す必要ないよ
たとえ繰り返しが必要だったとしても概念をその名前で直接扱える状態と
毎回展開しなきゃいけない状態では全く意味が違うんだけどね
インデックスは必要ならはればいい >>233
算出できる情報を別途カラム作って持たせるのは最終手段 >>180 重み付けの定石
>>182 単年度でしか動かないクソ
>>185 意図が分かりやすい
>>217 ビジネスロジックをDBMSに持たせる派とアプリに持たせる派で戦争勃発 >>234
fiscal_year(year, month)って関数自体はまだなにもオーバーロードしてないだろうが。 >>241のどこが馬鹿なのか論理的に説明できないやついるの？ >>240
分解せずに日付型で持っていればよかったって事だな
以降>>188へ戻る 管理上のオーバーヘッドってのがユーザ側の話なのかシステム側の話なのかしらんが
関数オーバーロードができたとして、それがビューより管理が重いとか信じられん
会計年度が必要ならそう言うビュー作れ、で終わりじゃないのか インデックス張るなら、ロシア方式が一番いいよな
トリガーで仕掛けておけば気にしなくて済むし >>239
> インデックスは必要ならはればいい
本末転倒だな
普通にクエリ書けばインデックス使えるのに、ストアドにしようと思うとさらに何かしないといけなくなる
つか、ストアドの結果にインデックス貼れないDBもあるんじゃね？ >>239
> asで名前つけとけばgroup byでは繰り返す必要ないよ
その手段が使えるDBでは、>>232も同じことが言える
> 毎回展開しなきゃいけない状態では全く意味が違うんだけどね
例えば四半期ごとの集計がほしいとか、移動平均がほしいとかいうことになったら、
そのたびにストアド作るのか？
増殖しまくりだな ん？ >>232 だとインデックス使われないだろ
>>217-218 >>185 のような関数だともっと使われない
>>182 のように or あると、うまく使ってくれるか怪しい >>251
> ん？ >>232 だとインデックス使われないだろ
where書いてないからね
>>232は、集計がしんどいという奴へのレス
>>182 のように or あると、うまく使ってくれるか怪しい
大抵のRDBMSだったらうまく使ってくれるんじゃね？ それより決算月が変わる可能性について考えたほうがいいと思う >>251
> >>217-218 >>185 のような関数だともっと使われない
こういうバカ避けのためにわざわざ「性能は知らん」って書いてあるのにバカはそれすら理解できないんだな w
インデックス使いたいならdate型にしとけよ >>254
year, monthにインデックス張ればいいだろ
アホか ビューのコストが高いというのがparserの話だとしたら、単純なビューなら最近では全く問題にならない
まぁ、大抵の場合、クエリ1回につき＋1ms未満だろう。
（さらには、直近のparse結果をcacheしている場合もある） >>256
> year, monthにインデックス張ればいいだろ
インデックス張っても関数の引数にしちゃったら使われない >>256
バカってこれだから...
複数の列に張るより単一の方が有利だろう
そんなことも理解できないのかよ w そんな理由だったらオレもアンタをバカ呼ばわりしていいかな 不利っつっても、比較が1回か2回かって違いくらいしかないだろ。 ここを2つに分けるかどうかの是非はともかく
キーが2つになるから絡むつにしようとかおかしいだろｗ
まあこのケース、月なんて12通りしか無いんだし複合キーで >複数の列に張る
こういう言い方しているところを見ると、複合インデックスの仕組みをわかってないんだろう。 yearのインデックスとmonthのインデックスを別々に張りそう >>250
>その手段が使えるDBでは、>>232も同じことが言える
そんなんわざわざ言わんでもわかっとるがな〜ww
>増殖しまくりだな
増殖して何か問題あるの？ >>246
システム側の話
組織構造なんかも大きく影響するから環境による
導出列はビューを使うっていう規約があってそれに従ってるようなところならオーバーヘッドも少ないだろうね
ただ関数よりビューのほうが管理の厳格度というか管理レベルが高いのは一般的じゃないのかな？
管理レベルが高ければその分のオーバーヘッドはかかる
それに同じような年・月で持ってるテーブルが10個に増えたら10個ビューを追加することになる
そういうのが嫌だからComputed Column的な機能があるDBが多いと思ってる >>264
お前こそわかってないだろ w
>>180, >>182 みたいに複合インデックスの各々の列を別々に大小比較で使うとインデックス使えないぞ 使われないインデックスと、使えないお前らの脳ミソ達。 >>182は(orは別として)yearとmonthの複合インデックスの教科書的な例だと思うが。
つか、>>180と>>182を同列に並べている時点でお里が知れる。 >>267
管理レベルってのがなんだかわからんが
ビューの方がより厳密に適用される分、問い合わせ時のシステム的なオーバーヘッドは小さいだろ
実行計画もより最適化できる
つか、ユーザー側／システム側って切り分けが、どっちも人員の切り分けだと思ってる？
>それに同じような年・月で持ってるテーブルが10個に増えたら
同じものが分散して存在してたら、その時点でテーブル設計が間違ってるわ >>270
実行計画見てみ
複合インデックスの仕組み知ってたらそんなアホな発想はできないよ おまえこそ見てみろと言いたいが。
念のためだが、ヘボいオプティマイザがorのせいでスキャン範囲の限定に失敗するのは
「複合インデックスの各々の列を別々に大小比較で使うとインデックス使えない」てのとは
関係ないからな。 >>274
> orのせいで
バカを晒すのはほどほどにしろよ 今どきは>>182でも(year,month)のインデックスがあれば
（そしてそれを使ったほうが速いとDBMSが判断すれば）
使うDBMSのほうが多いと思う
パフォーマンスに関しては昔の定石を今はあまり気にしなくても
良くなっていることが多いので必ず実機で試してから語ったほうがいい >>276
それはyearを使わずにmonthだけだった場合だな。こんな初歩的な勘違いしてたのか。 >>278
バカはこれだから...
わざわざ
> インデックスの構造をより深く見ていくと、この理由がはっきりします。
って言うところまで引用してるだからその下読めよ
理解できるかどうかは知らんけど w year, monthにインデックスの件だけど、PostgreSQLなら使われるけどなぁ
ほかのDBだと使われなかったりするのか？ 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 実行計画見るような人なら当然わかっているだろうけど、統計情報がとられていなかったり
選択されるレコードの割合ががテーブル全体に対して大きい場合はインデックススキャンが
選択されないから注意な。 インデックス使われないマン ＝
オーバーロードマン ＝
Computed Columnマン まさか今どき、インデックスがあれば必ず使うとか思ってるんだろうか
ルールベースとコストベースの違いも分かってない？ >>285
おいこら
インデックス使われないマンと一緒するなよw お前らが馬鹿なのは使う必要のないインデックスについて延々と話してることだけどな >>282
それ >>287 が書いてる通り Bit Map Index Scanだよ
URL読めばわかると思うけど
> ビットマップスキャンは、一度に全てのタプルへのポインタをインデックスから取り出し、
----
インメモリな「ビットマップ」データ構造を使ってソートし
----
> 物理的なタプル位置の順にテーブルのタプルにアクセスします。
つまりyearとmonthに対して個別にインデックス張っときゃソートなんて要らない
要するに >>264-265 をディスってるだけなんだが w 結論
>year, monthにインデックス張ればいいだろ
>アホか まあ、日付型とか言ってる奴は決算月の考慮どうするんだろうと思うわ >>297
決算月と日付型との間に問題があるなら後学のために披露しては？
それか質問なら>>1読んでからどうぞ >>287
データ量が多いというのは1億レコードとかそんな単位？
>>282は100万件だったけど、1000万件でも同じだよ。
>>288
そういう話じゃない。
ストアド作って、where fiscal_year(year, month) = 2017とやると通常はインデックスは使われないが、
普通にクエリ書けば、適切な場面でインデックスが使われるという話だ。
> ルールベースとコストベースの違いも分かってない？
PostgreSQLの話になるが、PostgreSQLにはルールベースのオプティマイザはないよ。
>>295
コメントの意図がわからないんだが。
> つまりyearとmonthに対して個別にインデックス張っときゃソートなんて要らない
それ、monthに対するインデックスの意味ないよね。 >>303
> データ量が多いというのは1億レコードとかそんな単位？
> >>282は100万件だったけど、1000万件でも同じだよ。
マジで仕組みを理解してないんだな w
そっちのデータ量じゃなくてインデックスの方
要するに年と月の数の話
> それ、monthに対するインデックスの意味ないよね。
ないと本気で思ってるなら真面目にもう少し勉強した方がいいと思う >>304
> マジで仕組みを理解してないんだな w
わかるような単語使いましょう。ちゃんと用意されてるんだから。
> 要するに年と月の数の話
カーディナリね。
> ないと本気で思ってるなら真面目にもう少し勉強した方がいいと思う
どういう意味があるんだ？ >>305
> カーディナリね。
それを言うならカーディナリティな
> わかるような単語使いましょう。
でかいブーメラン乙 w
きちんと理解せずに背伸びするからそう言う間違いをしちゃうんだよ
> どういう意味があるんだ？
普通にインデックスとして使われるだけだが？
なぜmonthは使われないと思ったんだ？ >>306
> それを言うならカーディナリティな
知ってるなら最初から使おうな。
> なぜmonthは使われないと思ったんだ？
使われないから意味ないんだよ。
まぁ、monthを軸にした検索をすれば使われるだろうが、今回の流れとは関係ないね。
俺がコメントを続けた意味が理解できてないようだから、再説明しとこう。
>>295
>>282
> それ >>287 が書いてる通り Bit Map Index Scanだよ
> URL読めばわかると思うけど
これが意味不明なんだが。
bitmap index scanだから何？ 脇道の細かい議論しても仕方がないから、論点を絞ろう。
君が主張したいのはこれか？
>>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)」に対してインデックスを貼ることができる
・（蛇足）そこまでするなら、普通にクエリ書け >>307
> 知ってるなら最初から使おうな。
ちゃんとした知識持ってる奴なら >>287 のリンク先読めばわかるし
それでわからんような奴にカーディナリティとか言ってもしょうがないだろ
さすがに中途半端にカーディナリとか言う知ったかさんの存在までは想定しとらん
> 使われないから意味ないんだよ。
なぜ使われないんだ？
に対して「使われないから」って日本語大丈夫か？
> まぁ、monthを軸にした検索をすれば使われるだろうが、今回の流れとは関係ないね。
>> (year=2017 and month>=4) or (year=2018 and month<=3)
で関係ないと考える奴にどう説明しろと？
> bitmap index scanだから何？
>>287 のリンク先読めよ
それでもわからないと言うから >>295 でも説明してる
さらにそれでもわからんと言うならわからない箇所を引用してくれ
すごく中途半端な知識で語ってるようだからどこがわからんのか予測できないし >>308
> ・year, monthにインデックスを張れば、>>179のような会計年度別集計などの場合にインデックスが使われる（もちろん、使った方がコスト的に有利な場合）
複合インデックスの話だよね？
それならBit Map Index Scanになるから実行時にインデックスデータについてソート処理が走るんだよ？
そこ理解してる？
ちなみに俺は
> インデックス使いたいならdate型にしとけよ
って言ってるから普通にIndex Scanするだけなのでソート処理なんて要らんから なんでBit Map Index Scanになるのが当然のような言い方なんだか。 そろそろ結論出して終わりにしてください
結論がまとまらないなら､両論併記で良いと思います お互い相手のことを馬鹿だと思っているなら
馬鹿相手にムキになっている自分を恥じたほうがいいと思うが いや既に結論出てるけど理解できない人が食い下がってるだけ >>180で答え出てるから後は設計スレでしてくれ
閑古鳥鳴いてるからウェルカムだぞ >>310
> それならBit Map Index Scanになるから実行時にインデックスデータについてソート処理が走るんだよ？
> そこ理解してる？
その「ソート処理」は、計画ノード種別の「ソート」じゃなくて、Bitmap Index Scanのアルゴリズム上、実装コードで
ソートが必要だということじゃないの？
実際、>>282の実行計画には、「ソート」はないわけで。
で、アルゴリズム上、ソートが必要だとして、何か問題でも？
> > インデックス使いたいならdate型にしとけよ
> って言ってるから普通にIndex Scanするだけなのでソート処理なんて要らんから
Index Scanの場合も、aggregateするときに、実装コードでソートが必要な気がするが。
（ソートせずに何回もループしてもいいが、多分ソートするんじゃないかと思う） >>309
> なぜ使われないんだ？
なぜもクソも使わないんだよ。
> >> (year=2017 and month>=4) or (year=2018 and month<=3)
> で関係ないと考える奴にどう説明しろと？
関係ないね。
関係あるというなら、テストデータ作って実行計画出してみな。
> すごく中途半端な知識で語ってるようだからどこがわからんのか予測できないし
俺がお前に言いたい言葉だな。 親切なので、year, monthに個別にindexを張った場合の実行計画を取ってみた。
https://explain.depesz.com/s/UapJ
書き忘れたが、
> インデックス使いたいならdate型にしとけよ
大本の話は会計年度で集計するときの話。
date型なら会計年度を取得して集計する必要があって、そこでストアドやビルトイン関数使うと
日付カラムにindexあっても使われないって話な。
さらに言えば、会計年度カラム追加しろとかいう話なら、今のままで複合インデックスつけて普通に
検索しろってこった。
（何度ループするんだよ） さらにおまけ。
# \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になってますが。 これにもレスしとこう。
前提として、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 >>324
まあ、微粒子レベルで俺が間違ってる可能性があるからな >>325
お前が>>323なら、おかしいのはお前の相手の方だから心配すんな
>>268からずっとおかしい
相手するだけ無駄 今時、コストベースがどうこうとか言う奴だからな。
10年以上前にちょろっとDB触ったレベルの奴じゃね？ ・ストアドにしてオーバーロードしろ
・インデックス使いたいならdate型にしろ
・date型にしないなら個別インデックスにしろ
・Bit Map Indexガー
・ソートガー
全部同じやつでしょ
最初からおかしい >>329
式なんか使わずに普通にクエリ書けと何度言ったら Local and global coordinate system ・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でいけるでしょうか？よろしくお願いします。 >>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 ;
間違ってたらごめん >>332
グループ化で複数レコードが存在存在するnameを排除すればいい。 複数レコードが存在するレコードを削除すればよい、ではなくてか。
having count(*) = 1 みたいに。 まとめると
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件でちゃうような select * from テーブルデータ where col_a in (select col_a from テーブルデータ group by col_a,col_b,col_c having count(*) = 1); a,b,c以外にも表示したいときはそうなるか
まあ (a,b,c) in (select a,b,c ｆrom 〜 ) とかになるだろうけども 項目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位でも大丈夫でしょうか。
検索したところ、２項目の入れ替えはこれでよいようなのですが、
複数（多数）の場合でもよいものか教えていただきたいです。
よろしくお願いします。 >>342
ありがとうございました。自信を持って（？）作業します。 >>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
というような処理が行われる レスありがとうございます。
>>344 >>345
検索して調べたときに知ったのですが、
postgreSQL,SQLserver,おそらくoracleは大丈夫。
MySQLは、左から順に評価するので、たぶんBはDの値になるようです。
みなさん一時項目を使ったり、足し算引き算をしたりして工夫されているようです。 mysqlは(1,2,3,4) -> (4,4,4,4)になるよ
クソ え、SQLってこの程度のことも規約で決まってなかったのか >>345
>>346
質問者じゃないけど、参考になる例題でした。 一時テーブルを作成して、更新後の並びになるようにコピーする
元テーブルのレコードを削除して、一時テーブルからコピーする
なんてやるのはどうなんだろう？
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; 【テンプレ】
・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被り数のように、「被ってる行」をカウントしたいんですが、
方法がさっぱり思いつきません。
何卒ご教示くださいますよう、お願いいたします。 >>350
SQLが通るかどうかは置いといて、結果の並び順は保証されていないので
キーを使うなどしないと「たまたま」動作したということになると思います。 >>351
元テーブル名が分からなかったので、partsと仮定した
http://ideone.com/wZK0bA >>353
ありがとうございます！印刷して家宝にします！！！ >>354
列の並び順を替えるにしても、行の順が元テーブルと違っちゃうかも
しれませんよという話です。
キーの部分を書くのが面倒で省略したということかもしれません。 行の順序が変わったとしても、それが何か影響を与えるとは思わないんだが 初めて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に入れてみたんですが、
これが全く変わりません。 straceしてみてどの設定ファイル読んでるか確認してみたら？ 久しぶりに来た半初心者なのですが、上の方の議論で出てた会計年度の話は、単に引き算を利用してはいけなかったんでしょうか
4ヶ月引いて１日足して、としてやれば安定して通常年度に戻せる気がするのですが 日付から年度を求めたい、という話？
そういうのでもいいけどそれ間違ってるからね どの話をしようとしているのか分からん
4ヶ月引いて1日足すというだけでも
30日に1日足したら31日になるのか1日になるのかどう判断するんだ？ >>363
ほんとだ
なんで足す１出てきたし４なんですかね
なんにせよありがとう 例えば、左から右に行って、
途中でジェイってなって、そのまま終わったらいいかと思うんですが。
新しいSQLの概念というか。 間違えた。 >>386じゃなく>>366だった^^; >>372
月末の次の日が1日じゃないケースってなに？ >>371の言う「翌月の1日前」が「翌月の1日の1日前」という意味なら、ってことだろ。 おまえ、そんな頭のレベルでよくSQL云々出来るなぁ IPAの試験が、読解力を試されるような問題だらけになるわけだ。 複数の同一形式の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
何で? ・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.名前 >>381
tableA は
日付、名前、国語、英語
です。 >>381
SELECT tableA.名前,AVG(tableA.国語）AS 国語平均,AVG(tableA.英語）AS 英語平均
FROM tableB
inner join tableA
on tableA.日付 >= tableB.採点開始日
AND tableA.名前=tableB.名前
group by tableA.名前
でいいんじゃないかな >>383
ありがとうございます
join したほうがいいのかな
これを参考にしてやってみます。 >>384
データ量はたぶんたかだか数万レコード程度だろうから、どんなやり方でもパフォーマンス的には気にする必要ないと思うよ >>383
横からだが、fromとwhereで結合しても、joinで結合しても
書き方が違うだけで同じだぞ
パフォーマンス気にするなら、使ってるDBMSの実行計画読めるようにならないと
事前に結合した実データ(のテーブルやビュー)用意するんじゃなければ
SQLの書き方では差がでないのが原則 じじいが嘘を広めていることもあるから混乱するんだよな。 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時間、補習 他人にわかる説明ができるようになったら解決するんじゃないかな。 >>388
tableBとtableCはビューB,、ビューCをだしたいに訂正します。
ビューCはビューBの部活、学校、補習の合計時間をだします。
tableA は1時間間隔で 活動した予定にOKが付きます
６時と７時は部活をやっているので２時間になります。
そのあと学校が５時間
その次は部活と補習がOKになっていますが
補習がOKなったら、学校がOKになるまで補習の時間なので
補習が２時間になります。
この流れで↓の結果が欲しいです。
ビューB
時間、活動
2時間、部活
5時間、学校
3時間、補習
2時間、学校
4時間、部活
ビューC
7時間、学校
6時間、部活
3時間、補習
SQLだけで書くのは見当がつかないのでアドバイスお願いします。 SQLだけで書けないと思ったのにSQLスレなのか
DBだけでやれない想定として、どういう風に実装予定なの？
ざっくりでいいからさ(Java使って、とかWindows上でとか) SQLだけでできるかわからないので質問しました。
今回のような内容はSQLでやるべきではない?SQLでできてもものすごくめんどくさい?
の状態です。似たような内容を何件か取得したいと思っているのでしりたいです。
SQLだけでビューB、ビューCをだせるなら、Windows上のアプリ でそれを取得してCSVデータにするのが簡単だと思っています。
SQLだけで無理ならtableAのデータからCSVデータを作成のつもりです。 ビューとして取る必要があるの？
画面に表示したいとか？
取得したデータをそうしたいの？ ビューとして取れるようにしておけばそのままCSVにだすだけで簡単なのと、
画面に表示したいと思っています。
取得したデータの操作は考えていません。 データが絶対に１時間間隔で抜けはないってならSQLだけでできるんじゃね
俺ならBはtableA を時間でソートして、ホストアプリでブレークチェックしながらカウントして表示するけどな >>388
は１時間間隔でなっていますが
秒単位で間隔は一定ではないです。
すみません。
Windows上のアプリはあまり動作増やしたくないなと思っていたんですが
SQLだけでやろうとすると
大変?って感じなのかな 普通データベースの動作を増やさないように工夫すべきなんだけどな > は１時間間隔でなっていますが
> 秒単位で間隔は一定ではないです。
意味不明だし後出しフラグ立ってるしすまんが抜けさせてもらうわ mdbファイルをDSNで一般に公開する方法を教えてください。
perl公開ならiisを使えばよいことは分かります。
pdf公開ならftpサーバを使えばよいことは分かります。
mdbファイルはiisを使って公開できるのでしょうか？
iisには接続文字列の設定がありますが意味が分かりませんでした。
odbcad32.exeはネットワーク越しは無理みたいでしたし。
ACCESSというお高いソフトにはmdbファイルを公開できる
サーバ機能が含まれているのでしょうか？ >>402
データベース（ファイル）を一般公開してはいけません mdbはファイル共有型だから
そのmdbファイルをファイル共有できるようにすればOK
とレスしてみたけど
そのレベルで一般に公開するのはやめとけ さすがにイントラでってことなんだろうけど、それでも公開はまずいっしょ 漏れをそのレベルとしか見れない人よりはレベル高いと思ってる。
ここまで6件のレスがついたが誰人答えを知らないほどレベルの高い質問をしてしまった。
漏れよりレベルの高い人を待つ。
合計7人が回答をお待ちしています。 >>409
とりあえず2chで質問とかアホなことしてる時点で低レベルやぞ？ 分かっておる。しかしそんな漏れよりももっとレベルの低い人が見つかった気がして
ちょっとうれしくなった。
あんたも答える知識の無い低レベルだな。
FileMaker入れて漏れは今解決したよ。
7人の戦士のうち結果的に漏れが一番レベルが上になったようだ。
ばいばい。 低いレベルというか専門性が違うだけでしょ
SQLスレで聞くのも違う気がするし 聞けるスレがないと言うのも気の毒だったけど
しかし、もっと違うアプローチをすべきだとは思った MDBファイルはADOを使ってPHPからアクセス出来るので
IIS上で上手くやればWebサイトとして構築出来るんじゃないかな？ 彼はデータのを表示させるためなら、どんな方法でもよいとしか言ってないぞ？ FTPでファイル転送してるらしいから、mdbファイルを渡せばいいんじゃないのか？ >>414
Webサイト構築したいとか言う話じゃないし、それが出来るレベルの人間の質問でもないけど
>>415
彼って誰だよ
表示出来ればどんな方法でもいいとか誰がいってるの？
mdbをDSNで直接指定できるようにするにはファイル共有でアクセスできるようにすればいい
それを一般に公開するかどうはやる奴が決めればいい >>418
でも、iisやftpの話を出してきてるし
一般に公開する方法ってことだから
内容を表示出来れば要件は満たしそう >>402 は何を公開するとも言ってない。
Perlのスクリプトを公開するのもコードを公開するとも受け取れる。
PDFファイルはなぜかFTPでダウンロードさせてるあたりから、助言する段階の情報がまだない。 PostgreSQLでいうと、port 5432をインターネットに公開したいってことでしょ >>420
>mdbファイルをDSNで一般に公開する方法を教えてください
って言ってるけど？ ここのスレは>>411にとって
>漏れよりももっとレベルの低い人
の集まりで
>答える知識の無い低レベル
らしいから、そんなのこちらが考えるだけ無駄 WebブラウザでAccessの画面を開きたいレベルの話だと思うけどな。
PDFファイルをローカルで開いていることもわからないくらいだから。 すいません質問です
記事テーブルとカテゴリテーブルがあるのですがそれぞれのID部分を post_id category_id とするのか、単に id とするのかどちらがいいでしょうか? ネーミングの問題？自分で作ってるものなんだろうけど、3ヶ月後の自分は他人なんだから、そんなしょーもないところで
手を抜かずにちゃんとした名前、この場合ならpost_ , category_ 等々にしたら？ >>426
そのIDが同じものでないなら、ただのIDという名前はやってはいけないレベルの命名。 作った当初は覚えているだろうけど
何年か経ってSQLソースを見た時に
「このidってなんだったっけ？」
てことになる 普通にidでええやろ
category.category_idとかアホみたいやん デフォルトは主キーがIDのフレームワークもある時代に何言ってんだか >>434
データベースに詳しくないのが無茶苦茶なことをやるんだよな。 ナチュラルジョインも知らないのが設計するとそうなる。 皆様ありがとうございますm(_ _)m
idは他のテーブルでも使用されるので post_id などに統一しようと思います どんなテーブルだろうが id は id やろ？
テーブル見ればなんの id か分かるだろ？
アホはアホなとこに神経使うんだな(笑) maker.code (PK)
product.code (PK)
設計はともかくこういう命名規則も許せないのか、気になるところね id列にも名前に修飾詞をつけておくとusing句が使いやすいというメリットがあるんやで
なんでも原理原則に従うのがいつも最良の方法とは限らんのや テーブル以外のidも意識しろって話でしょ
全部idだとどこの何のidか意識する必要あるし、外部キーとしてidが多々あるとNGだね ナチュラルジョインも知らないのが設計するとそうなる。 >>444
最近覚えた言葉を使いたがるやつっているよね 同じカラム名で意味の異なる属性は、RDBではないな。そのテーブルの主キーではあるが、業務上、意味がない値を格納するだけだとしてもよろしくない。MS-Accessの古い慣習の影響か。 あのさぁ、1プロジェクトで数百以上のテーブルとか普通にあるんだけど、それぞれユニークなカラム名付けるのか？ カラム名が同じなら、その項目同士にリレーションシップがあると考えるのが標準SQL。 >>450
リレーションシップは外部キー制約があるかどうかではない。 >>442
て言うか単一テーブルだけでないなら普通そうするよね テーブル名指定するなら、テーブル名をコラム名の一部に使うのと同じ事になる 考え方の違いだな。
テーブルはエンティティを表すとするならカラムはその固有の属性だが、もともとのリレーショナルモデルでは
先に属性があってその関係をリレーション(テーブル)として表すわけなんで、同じ属性が異なる複数の
リレーションに含まれ得る。 すみません、SQLの実行の順番ってどうなってるのですか？
select
hoge
from
tableA
inner join (...) subQuery1
on(...)
inner join (...) subQuery2
on(...)
みたいなsqlがあるとき、どのどこから実行されるのですか？ from→where→group by→having→select→union等→order by
の順に実行したかのような結果になる（from内のjoinは左から）
内部動作として実際にこの順で実行しているかはまた別の話 サブクエリもfrom句の内なんだからそのように解釈すればいいだろう。そもそも何を問題にしているのかわからん。
>>460の質問はおかしい
>>460の質問はインラインビューについて聞いている
>>460の質問はインラインビューについて聞いているが質問がおかしい
どれ？ >>466
初心者なんだから、そんなのあたりまえだということがわからない。
話をすっとばしてはいけない。 その「あたりまえ」は>>462の知識を前提にしているんだから順序はそれでいいんだよ。何をすっとばしたって？
それにそもそも、>>460がそのあたりまえのことを理解できない初心者だと決めつけるのもおかしいだろう。
一連のレスを見返してみると、お前は中身のないケチをつけるしか能がないのか？しかも支離滅裂。 すみません。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までの全レコードが検索され、
その上で内部結合の結合条件のレコードが抽出されるのですか？ 概念的には各サブクエリは独立して実行されると考えてよいが、
それをjoinした結果からは区別がつかん場合もある。
もちろん実際の実行順序は別の話。 >>470
同じSELECT文の中で同じテーブルを検索したら、それはそれで結果のビューができるという考え方でよい。
RDBMSによって内部の実装は異なるし、データの統計情報によっても処理方法は異なる。 >>470
内部結合だから結合条件によっては、同じ結果になるか、初心者にありがちな検索結果からSQLが正しいかどうかを確認してるのか？ 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で出来ませんか？ インジェクション扱いされて
SQL文、書き込めない。 ＞a_price1がnullでないならそれを採用、
＞a_price1がnullならprice1を採用
ｃｏａｌｅｓｃｅ(a__price1,price1) as a_price1
全角を半角に直して >>478
その引数を最初から評価して最初にNULL値でない引数を返す
ということで最初にa__price1を持ってくるということですか。
ありがとうございます >>479
彼は関数を使えと言ってるけど、CASE式でもいいけどな。 476です。あ〜、case式ですか
case when a_price1 is null then price1 else
a_price1 end as a_price1
でも出来ました。ありがとうございます。 IDEなんかに出てくるフォルダがスキーマってやつだよね？
でテーブルがあると
スキーマとテーブルの間のフォルダみたいな奴はなんなの？ >>482
どのRDBMSかわからないが、GUIのツールによっては、他のユーザーのスキーマ、データベースオブジェクトがぶら下がっているかのように見えるものがある。 ExcelでWith使いたいんですけど、何とかなりません?
もちろん、With〜End WithのWithじゃなくて、SQLのWithです。 >>485
その説明では何を言ってるのかわかりません。 temp table的な使い方のWITH句について言ってるんだと思うけど
DBサーバー、DBドライバ、実際のクエリ、この辺りの情報そろえて
DB製品スレかExcelスレで聞いたほうがいい ネット上でよく見かける困ったバカの特徴
自分が理解出来ないとすぐに相手の言語能力不足を指摘する(しかも割と本気) >>491
仮定での回答ほどたいへんなものはない。 >>486
>>487
いや、485にも書きましたけど、SQLのWithですって。
VBAのWith〜End WithのWithじゃないです。
>>488
そのWithです。
Excelスレって、そっちの人達じゃわからないですよ。
あと、DBサーバーとかDBドライバって、
使えるかどうかは、それに依存するんですか? >>494
!?
SQLって小文字使えるでしょ!?
少なくともExcelなら、SelectとかFromとか、小文字使えますよ。 >>485
相手のDBMSによるので最低限何のDB使ってるのか書け
接続方法等によってSQLの発行方法が微妙に違うからそれも書け 自分が分かっていない事を分かっていないんだろうから何を言っても無駄 >>493
推測するに、ODBCかなにか使って、外部のDBを扱いたいのだろうと思う
その場合、外部のDBが何であるか、例えばOracleとかMySQLとか
そして、そのDBに対してどのような接続方法をするか、
質問する際にそういう情報として出さないと、誰も回答しようがないと思う
Withが使えるかどうかは、相手次第 >>493
ExcelスレってのはExcelのVBAスレな
>使えるかどうかは、それに依存するんですか?
依存する場合もあるし、君が何か間違えてる可能性もある
そもそもサーバー側がサポートしてないケースだってあるだろ
エラーが出てるならそのエラー内容も含めて関連スレで聞きな
SQLの文法でエラーになってるならここで聞けばいいけど ExcelのシートにADOで繋いでクエリかけたいとかなら無理だぞ
VBA使ってるなら文字列生成を工夫して省力化できるかもしれんが。
ちなみにWITH句もしくはCTE(Common Table Expressions)といったほうが通じる >>501
完全に間違った推測ワロタｗ
しゃべるなバカｗ >>507
おまえ、質問者だろ？
前もそういう態度だったよな？ >>508
違うわｗ
質問に群がる教えたがりのバカを笑ってるだけだｗ
お前みたいなバカなｗ >>497
>>501
相手方は、AccessかExcelかCsvです。
接続方法は、MsQueryかADOしか分かりません。
>>503
そのExcelのVBAスレなんですけど、
そっちは、普通の使い方をする人がメインで、
SQLとかWindowsAPIとか、マイナーなのはあんまり話が通じない・・。
ここも、WithがSQLのWithだとわからないで攻撃してくる人がいましたけど、
あっちはもっと酷いです。
>>506
無理なんですか・・。
ありがとうございました。 >>512,513
お前らの頭なw
なんでバカのくせに教えたがるの？w 「話が通じない」んじゃなくてお前の書き方がヴァカなんだよ >>516←自分のバカをバカにされてバカにしてる奴が質問者だと思いこみたい救いようのないバカw >>514
そもそもあなたの言葉は非常にわかりにくく、大半の日本人は理解できませんよ？ 言い方が悪いけど、頭の悪い女性が書く文章に似ている。 >>519
だから悪いのはお前の頭だと何度w
とはいえすかさずバカ特有の論理性を欠いた女性蔑視発言をねじこんでくるあたりはさすがだなw
バカオブザバカの称号をお前に授けようwww いつものクズがVBAスレから出張してきててﾜﾛﾀｗｗｗ >>518
それはそうです。
分かる人(Withというキーワードだけでピンと来る人)に向けて書いてますから。 with自体について突っ込まれているんじゃないってことすら読み取れないのか。
ざっと見まわしても>>494ぐらいしか見当たらんけどな、そういうのは。 >>523
だから、どこでSQLのwith句をどう使おうとしているのか、どう書こうとしているのか、頼むから書いてくれ。 暇な人(分かるとは言っていない)だけが答えてますから。 >>525
>相手方は、AccessかExcelかCsvです
らしいから、Jet(ACE)だろ
少なくとも俺の知るバージョンではCTEは使えないから
回答として、できないで終了でいんじゃね Excel VBAスレにいるいつもの奴だからスルーで
自分で質問して自分で回答してる奴ね
お前らどうせ分からないだろ、俺が一番詳しい（ｷﾘｯ
って態度で質問してる
誰かが回答するとすぐ回答者を装って嫌違うってレスしてくるからすぐわかるぜ >>530
だからそのwithじゃなく雑誌のwith >>1
【緊急】
すき家の定食に衝撃異物！
ずさんな管理体制が明らかとなった
指摘したその時！わざとらしく店員が声をあげごまかした！
229 名前:やめられない名無しさん [sage] :2017/08/29(火) 07:31:54.64 ID:EfhOnUp0
俺の朝はいつもすき家
楽しみにしてたのに・・今日に限って朝定食にしたんだ
見てくれ、これが証拠
店員さんも驚いて声をあげてる・・
https://www.youtube.com/watch?v=wjD4hUeU-CA
ちなみに半分食べた
お客様センターが通じない・・病院行く・・
(´・ω・｀)すき家が大好きだったのに・・ LEFT JOINで結合した際に、対応するレコードがない場合
値がnullになりますが、元のテーブルのデフォルト値にするにはどうしたら良いでしょうか？
SELECT句で各clumnにIFNULLは使いたくないです
MySQLを使っています
よろしくお願いします LEFT OUTER JOINの話かな？
どっちにしろ、そんな方法はない
IFNULLで地道に埋めるしかない >>534
CASE式、COALESCE、IFNULL, サブクエリ、デフォルト値有りの一時テーブルへINSERTとかかな
IFNULLを使いたくない理由が手間のみなら諦めたほうがいい
真っ当な理由があるならCASE式での代替を考えるといいのでは >>535
>>536
そうですか・・・
clumnの数がかなりあるので糞面倒ですが地道にやります
ありがとうございました ソース全部手で打ち込んでいるのか？
環境が分からないけど、
大概のエディタって置換機能あるだろう 単純な繰り返しならエクセルの計算式でsql文作ってコピペすれば楽チン すごくたくさんあるならSQLを生成するスクリプトを書くとか SELECT *, "default" AS [name] FROM foo
こんな感じでfooテーブルのレコードに任意の値をくっつけたものを出力可能
NOT EXISTSとかのサブクエリと組み合わせて、EXISTS側とUNIONで合体する
自分ならまずやらない方法ではあるが
単発のSQLじゃなくアプリケーションで使うSQLだとすると
DB設計かアプリケーション設計かどっちか考えなおしたほうがいいかもね CentOS6 + mysql 5.57
社のシステムなので、アップデートやインストール、ログ設定の変更ができない前提です。
まず前置きですが
既存のデータをDB化する一環で、大量（毎日80000行）くらいのinsert文を実行しなければなりません。
insert文自体は、既存のテキストデータから必要事項を抜き出して私が組み立てています。
元のデータはwindowsだったりワープロ専用機だったりですが、最終的に全てUTF-8に変換しています。
まぁこの処理自体はマクロ等駆使してやっているので問題がないのですが、元々のテキストに本来SQLで避けなければならないような半角記号とかが含まれている可能性がありますが、そこまでのチェックは物理的にできません（やっていません）。
一応、改行を\n、半角の引用符号は全角に、程度の処置はしています。
で、この大量のテキストをsource文で読み込んで処理するのですが、所々warning＊＊みたいな表示がでているのがわかります。
登録済み行数のチェックくらいはできますが、フィールドの中身が正しく登録されたかどうかまでのチェックはとても手が回りません。
そこで質問なんですが、SQLを実行する前にエラーになりそうな箇所を知る方法、あるいは、実際にエラーやwarningが出た行を知る方法（ツール、設定）がないでしょうか。 改行コードを入れてはいけないとか
引用符を入れてはいけないとか
そんな「俺ルール」はDBにとっては知ったこっちゃないので
まずはその「俺ルール」を正確に定義しないと何も始まらない >>543
エラーが出た行が分からない理由がよく分からない
自分ならINSERTじゃなくインポート(LOAD)使う
8万行くらいならよっぽどレコード長が長くない限りすぐ終わる
でDBからデータをエクスポートして元データと差分比較して検証する
検証が完了したらインポート先のテーブルから本番テーブルへデータ移行する
まあ100件くらいの少量でやり方を確立してから本当に必要な量でやったほうがいいよね あとSQLの質問じゃないしMySQLスレで聞いたほうがいいんじゃないの？ エラーハンドリングのやり方がわからないという意味なのかな？
それなら製品ごとにやり方違うからMySQLスレで聞いたほうがいいと思う >>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 >>543
＞チェックはとても手が回りません。
なんで？時間が無い、技術が無い？ もうSQLというより、IT技術者の初心者の質問だよなw >>551
宇宙飛行士は頭がいいというよりは、超絶バランス感覚がある人でないとできない。
頭が良すぎる人には向いてない。 自分は生まれつきもの凄く頭が悪いのですが、東京大学理学部数学科に入って数学を学びたいという目標があります。
生まれつきもの凄く頭が悪い人でも、人並み外れた努力を積み重ねれば、その目標を実現することはできると思いますか？
どうでしょうか？ >>553
東京大学に入ることは努力で可能なことです。そんなに難しいことではありません。
高校生までに東大に合格するような勉強方法や、強い意志がみなないだけです。 insert into >>553(atama)
values
select エッセンス from ドラゴン桜; MySQL5で1つのカラムに空白区切りの単語がはいっているとします。
テーブル構成は以下の通りです。
id｜word
.1｜バナナ
.2｜バナナ みかん
COUNTで集計したいのですが、
空白文字で区切って「バナナ:2」「みかん:1」のようにすることって出来ますか？
（空白区切りじゃなくてカンマ区切りでもいいです）
別に単語分割したテーブルを用意するのではなく、
1つのテーブルでカラム内の値を分割して集計する方法があれば教えてください 各DBでのやり方見たら分かると思うけど
そのケースをSQLで処理するためには
単語分割したテーブルを用意するのと同じような処理が必要 関数従属性の話って「意味論」でいいんだよね?
ある「カラムAから -> カラムB」の従属性があるかどうか
って現在のテーブルに格納されている値を見比べるだけじゃ
わからないよね？
もしカラムAとカラムBの値が全く同じ組み合わせで対応している
ように見えても、それが偶然これまではそうなだけなのかもしれないし、
「A -> B」が「値を見る限り従属している」のが分かったとしても、
それが「直接従属している」か「推移的な従属」なのかって、
値を見てもわからないよね？
カラムの意味を考えたり、値を格納している実装を見ないと
「どんな従属性なのか」ってわからないっすよね？ 今あるデータがすべてならばデータを見れば判断できる。
それ以外のこれから入れるデータがあるのであれば当然、今あるだけのデータからは判断できない。 意味論て言ってるのにデータを見ただけで分かるわけないだろ
頭が悪い奴だなｗ >>565
「意味論だよね？」って確認してるの。
関数従属性について図で例示されてる解説があるだろ？
でもこういうのみてもさっぱり理解できないから、よく考えたら
例示では理解しにくい概念なんじゃないかって思ったんだよ。
やはりそうなのか。 うん、関数従属性はデータからだけじゃわからないよ
既存のテーブル構造が関数従属性を100%表現できている場合は
データじゃなくその構造を見ることでどういう従属性があるか理解できるかもしれないが
現実には100%表現できてることなんてまずないからね 集合論を知っていればわかるように、集合自体が構造を表す。
つまり、テーブル内のデータが全体集合なのであればそこに存在する従属性はそれでわかる。
現実的には全体集合を得られていることなんてレアケースだろうから、そのときは
「(いま得られている)データからだけじゃわからない」ってことになるが。 >>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 }
これが全体集合だったとして、ここに存在する従属性がわかるなら教えてくれよ 3番目のカラムを除く組み合わせほぼ全てだろ？
Aならばタコスだし2017/08/13だし、ドンタコスならばBだし12だ。 質問スレで念のために自分の聞きたい質問がスレの主旨に合っているかを問うのだが
その問い自体が既にスレの主旨から外れているという矛盾を抱えた石橋叩きの人生
生きるのが大変そうですね BigQuery ってなんだ？
ってググったら Google のサービスか
何を聞きたいのか知らんけど普通に Google に聞けよ MYSQLで
まったく同じ構造の表三つを、
表１ 表２ 表３
１ null １
２ ２ null
３ ３ ３
null ４ null
５ null ５
nul ６ ６
のように結合したいのですが、どのようなSQLにすればよいのでしょうか
表は三つあるのですが、どこがデータ量が一番多いのかはわかりません 推測するに各テーブルがカラム1個で、
全データを列挙したいんじゃ？ つまり、こういうことか？
select 表１.カラム１,表２.カラム１,表３.カラム１
from
(select カラム１ from 表１
union
select カラム１ from 表２
union
select カラム１ from 表３) t
left join 表１ on 表１.カラム１= t.カラム１
left join 表２ on 表２.カラム１= t.カラム１
left join 表３ on 表３.カラム１= t.カラム１ SQL Server 2014 で教えてください。
１）
select * from tableA join tableB;
や
select * from tableA left join tableB;
と書いた場合、上は inner join、下は left outer join と同等でしょうか。
引き継いだコードが上のように書いてあるのですが、join で検索を掛けても inner join とかの記事しか出てこず。
２）
テーブルから特定の値のレコードを検索する場合、
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 の方が圧倒的に速いのですが、そういうものなのでしょうか。 >>581
ありがとう。
1) は動作結果からそう考えていたのですが、仕様的確認をとれて助かりました。
2) はそうですよね。SSMS の実行計画は見ていたのですが、そういう差があること以上のことは分かりませんでした。
教えていただいた方法でも調べてみます。 サブクエリでの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条件など索引に関係するものが無ければ）なら、並びを変更される要因がないので、同じ結果となる」
との回答をもらっていますが、
もしよろしければこちらの有識者の方のご意見も頂けると幸いです。
よろしくお願い致します。 その回答した人は、ROWNUMがOracle固有の疑似列だということを知らなかったんじゃないかね。
ちゃんとそれがわかるように質問した？
あとOracleの場合でも、順序はROWNUMで得られるけれども出現順が保持されるとは言っていないと思う。 >>583
保証されないって思っておいた方がいいと思う
> たとえば、次の問合せは、小さい順に10個の従業員番号を持つ従業員を戻します。
これは
「小さい順に10個の従業員番号を持つ従業員」を戻します
であって
小さい順に「10個の従業員番号を持つ従業員」を戻します
じゃない
> 「サブクエリーでソートされた結果を出力するだけ（joinやwhere条件など索引に関係するものが無ければ）なら、並びを変更される要因がないので、同じ結果となる」
これOracleサポートの正式回答ならとりあえずは信じていいと思うけど、バージョン変わった時も保証されるのかを聞いておいた方がいいと思う
そもそも普通に
order by num asc
を追加しとけばいいだけじゃないの？ でたらめアドバイスだらけだが、OracleのFROM句の副問い合わせは、インラインビューと呼ばれ、並び替えも含めてインラインビューの結果そのものを、再度、検索する。
rownomをSELECT句に書いて、別名を付けるのは一般的ではない。 >>584,585
ご回答ありがとうございます。
別場所で質問した際は、oracle11gで、と前置きしていましたが、回答者の方がoracle固有の疑似列と知ってらっしゃったかは分かりません…
お二人に指摘頂いてるリファレンスの解釈については、確かにそのとおりですね。
公式の見解を聞きたいですが、サポート契約が無いのが辛いorz >>586の方もご指摘ありがとうございます。
確かに、リファレンスにもROWNUMにasで別名を付けるソースではないんですよね…
ただ、既に稼働しているシステムのソースがROWNUM別名形式でして、弄くる箇所は最小限にしたいなあ、と。 >>588
そもそもrownumをSELECT句に挙げる慣習はOracleにはない。
最近、SELECT句で選択していない項目は条件で使えないと思っていたベテランがいたがw 既に稼働しているシステムのソースをなるべく弄らない方針にすると
負債がどんどん貯まっていって見るのも嫌になるのでおすすめ >>583
外側のクエリでサブクエリの並び順を変更する要素がなければ、サブクエリの並び順のまま出力されるけど、それは現状の実装がそうなってるだけ
外側にもサブクエリと同じorder byを付けとけばオプティマイザが2回目のソートは不要って判断してくれるから心配なら付けといて損はない >>592
それはおかしい。
間違いは素直に認めろ。 インラインビューをサブクエリとわざわざ曖昧にしてるあたり分かっているとは思えない。 >>590
row_numberは記述が冗長になるのと、機能を拡張しすぎていてかえって分かりにくくなってしまう。 >>592
あなたはrownumはフェッチ時に番号が振られるのを理解してないのだと思う。
番号を付けるときにorder by rownumしても何の意味もない。 >>597
アウターにorder byがなくてもオラクルが順序を保証してくれると主張してるの？
最低限、何を主張したいのか分かるように書いてくれる？ >>596
Oracle方言よりANSI SQL使うに越したことはない >>598
rownumという列があるわけではない。
並び順はorder byを指定しないかぎりは保証しないというSQLの規格とは関係ない。
Oracleは内部的なことをSQLに書いているだけで、SQL ServerのTOP関数も内部では二度SELECTしていることが多い。 >>600
で？
保証してくれるの？してくれないの？ rownum絡みの仕様変更はずっとアナウンスされていない。 order byがなければ順序は保証しないとマニュアルに明記されているにも関わらず
rownum使ったtop-N最適化のケースは例外的に順序が保証されると言うならその根拠が必要だよね どういう思い込みなのか、rownumの変な使い方にこだわって、やってもかまわないが、変な人を貫きたいというので答えたのにな。
さらにオラクル社のいうこと、伝統、実装も突っぱねて、さらにオラクルでは、リソース食いのrow_numberを使用しようともしている。
どのRDBMSも標準化SQLが先にあって作られているわけではないから、標準SQLの方が性能も動きも読めないうえに、バグにあたる可能性がある。
さらに標準化SQLの構文を拡張してるから、どんどんわかりにくくなる。
なんで調べないのかな。
rownumは列じゃないんだよ。
インラインビューのorder byは意味があり、入れ子のrownum同士は別物。
オラクルではインラインビューのorder byは意味があり、インラインビューをSELECTするSQLではrownumをorder byをするのはかまわないが滑稽。
使い方は自由だからそう書きたいならそう書けばよい。 >>604
どういう初心者なのか知らないが、ソートしたものの中から、初めの何件かを取得するというSELECT文は、Oracle Databaseではインラインビューでソートしてrownumで絞り込む構文になっているだけ。
他のRDBMSでもOracleと同じものもあれば、ひとつのSELECT文で表現するものもある。
SQLの見た目で判断しているようでは、データベースをやめた方がいいよ。
どうしてソートしてないのに先頭何件かが取れるのか考えろよw 諦めろお前らはとっくに ID:oX0yCwR9 にマウント取られてんだよw >>604
Oracle Databaseは保証しないことは書いてあっても、保証するとは明言していないのが特徴。
こんな実績があって有名な話題で、さらにorder byを特殊なOracle構文にも摘要させたがるのは、世界初のリレーショナルデータベースのオラクルが憎くて、標準SQL側の攻撃のようだw 内部実装についていくら書いても
オラクルが順序を保証する根拠にならないよ
ただの無意味な長文 >>610
じゃ、保証してないんでしょ？
保証してんの？ >>586
一般的な書き方かどうかはどうでもいいけど
>並び替えも含めてインラインビューの結果そのものを、再度、検索する。
のソース教えてくれ
とくに、並び替えも含めてってとこな
これが正確で保障された動作なら、ORACLEにおいては保障されてるって話になるな >>613
なんねーよw
再度検索した後の結果セットの並び順が
その理屈でなんで保証されるんだよ Oracle初心者が調べもせずに教えろと騒ぐスレになったのか。 例の目的を達するにはこう書くと決まっているのに。rownumは値が固定のカラムではないと何度言ったらわかるのかw >>614
保障されないならrownumでトップnとか取れないって事になるぞ
あれは単に行のフェッチ順のはずだから
でも実際にはあちこちでORACLEのトップnのクエリの例としてあがってるからな
>>616
理屈も解らずにただこう書くと言われても納得できない方が普通じゃないかね だから保証されていることを保証しているのかとアホみたいに聞くからおかしなことになる。
オラクルはインラインビューにあとからorder byを導入して、レコードの並び順を固定している。
だからインラインビューをSELECTする場合にはorder byがいらない。
だいたいマニュアルでも書籍でもネット上でもさんざん説明されているのに、オラクルスレでもないここで聞いている行為がおかしい。 Oracleスレでやれよ
ここSQL全般スレなんだから方言とか実装の話なんかいらん >>617
top-Nを取得することと、取得した結果セットの並び順がどうなるかは別の問題だってのが分からない？ 下のが質問者が引用してたリファレンス原文だけど結果セットの並び順については何も言及されてない
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 でもって>>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 >>619
保証されてるというソースがあればみんな納得するよ >>619
> だからインラインビューをSELECTする場合にはorder byがいらない。
> だいたいマニュアルでも書籍でもネット上でもさんざん説明されている
ネットや書籍はどうでもいいからどのマニュアルのどこに載ってるか示してくれ >>625
マニュアルは外国に丸投げしたせいか、劣化が激しく、間違いや変な説明が多いので、マニュアルが正ともかぎらないし、あえて言及してないことも多い。 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によって行が順序付けられた後で生成されます。」 そのトップレベルのSELECTの結果の出力順が
インラインのORDER BYの順序と同一であることが
保証されてるかどうかって話じゃなかったの？知らんけど。 「ORDER BY句を副問合せに埋め込んでROWNUM条件をトップレベル問合せに置いた場合、行の順序付けの後でROWNUM条件を強制的に適用させることができます。
たとえば、次の問合せは、小さい順に10個の従業員番号を持つ従業員を戻します。
これは、上位N番のレポートと呼ばれることがあります。
SELECT * FROM
(SELECT * FROM employees ORDER BY employee_id)
WHERE ROWNUM < 11;
前述の例では、ROWNUM値はトップレベルのSELECT文の値です。
これらの値は、副問合せ内のemployee_idによって行が順序付けられた後で生成されます。」 >>628
rownumは主問い合わせの列で、その値は副問い合わせの結果と書いてある。
これを根底からくつがえすなら、あらゆるシステムで問題になっている。
これは内部的にソートされるから結果的に並び順が同じたぐいの話ではない。 うんだからROWNUMの値がインラインのORDER BYに紐付いてるのはわかったよ
そのROWNUM < 11なトップレベルの問合せはROWNUM順になるのが保証されてるのか
ってのが上の人らの指摘なんじゃないの？
個人的には保証されてるかどうかはどうでもいいんだけどズレた内容でドヤ顔されるのはうざいし インラインビューのorder byは無視されているのではなくて、order byの結果セットを返す仕様で、rownumは結果セットのフェッチ順。
構文が気持ち悪くみえる初心者がいるのは理解できるが、SQL ServerのTOPの方がよほど気持ち悪い。
レコードに位置の概念があったり、位置の概念がないと思いながらもソートがいきなりできると思い込むITオンチと話すときりがない。 誰でも知ってることをドヤ顔で永遠と書いた挙句に最後は八つ当たりww >>631
それは構文がそう見えるだけだろうが。
rownumの値は副問い合わせの結果で、かつrownumは主問い合わせの取得順。
Oracleの構文になんでそんなに文句があるのか。
外国人はデタラメが多いから気をつけろよ。 実際にこの話題は仕事でも若い人ほど、標準SQLが先にあって、OracleがそのSQLの仕様に沿って作られていると勘違いしているのか、引っかかって面倒なんだよな。
最近もSQLはこう書くとこうなるみたいな話をデータベースに詳しくない人間が言い始めると、面倒だからそれに従うしかない。 批判されていると思い込む恐怖心はわかるが、ネットとはこういうところです。 >rownumは主問い合わせの取得順
これは間違いないんだが、その肝心の主問い合わせの取得順が
副問い合わせのORDER BY順にならなければトップn取れないわけだが
（最終的な出力順はその通りとは限らんでも良いけど）
これがORACLEでは保障されてるってなら
マニュアルのどこに書いてあるか言えばいいだけなんだがな
ORACLEには仕様ではないが過去の実装からそうだと決めつけられてることが結構あって
ORACLE自身も影響範囲がでかすぎて、おいそれと変更ができなくなってる
これもその一つだと思うけどね やりとり見てないまま横から失礼だが
普通は row_number() over 〜 使うんじゃないの >>640
top-N集合の取得は保証されてるよ
それはリファレンスのrownumのところ読めばわかるじゃん >>641
そうね
今はfetch first/next使う どうでも良いからOracleのスレでやれって アフォどもが ソート条件のあるカーソルでフェッチ順がソート条件通りにならないという主張はただの知識不足としか思えない。 >>640
なんでオラクル社の説明をねじ曲げて解釈するのか？
例のrownumの件は、ドキュメントでも主問い合わせのrownumは、副問い合わせの結果が値で、主問い合わせの疑似列であると説明している。 >>645
もうやめたら？言えば言うだけバカがよけいにムキになるだけだぞw >>647
SQLは仕事上、間違いを主張しまくる人間が多いから、ここでもとにかく誤りを正さないと生活がめちゃめちゃになる。 >>646
>>623でオラクルのエンジニアが並び順は保証されてないとハッキリ言ってるじゃん
彼が間違ってて君が正しいと言える客観的根拠が全く提示されないから説得力ゼロ
今のところ”ソースは俺の頭の中(ｷﾘｯ”な状態 >>645
君以外誰一人としてカーソルのフェッチについての話なんてしてないよ >>650
SQLが何なのかわかってない。いい加減にしろ。 >>649
その人が間違ってるのに、なぜオラクルエンジニアの私が間違ってると決めつけられなきゃいけないのか？ >>646
主問い合わせのrownumは主問い合わせのフェッチ順のはずで
>副問い合わせの結果が値
なのは、「主問い合わせのフェッチ順が副問い合わせのorder by順」な結果に過ぎないんじゃね
で、今問題なのは
「主問い合わせのフェッチ順が副問い合わせのorder by順」
なのは実装なのか仕様なのかって話なんだが
（主問い合わせの出力順が主問い合わせのフェッチ順通りかどうかは別の問題）
ま、どっちにしても個別DBMSの話だから続きはオラクルスレでやってくれればいいけど 不思議なのは、Oracleがインラインビューにorder byの仕様をあとから追加して並び順を付けたのに、なぜ並び順が不定と言い張っているのか？
最近のマニュアルはどんどん表現が変わって、Oracle Databaseの歴史まで間違いを埋め込んでいる。
いまでも使われているバージョンなのに誤情報が書かれているから、仕方がない側面もある。
オラクル社がわけのわからない外国に仕事を投げてたり、データベースに詳しくない人間に仕事をさせるからおかしくなる。 >>655
それはOracleの構文が実装に近いから、標準SQLや他のRDBMSのSQLと比べるとそう感じるだけだと思うよ。
ソートはSELECTがネストするのに、構文ではネストしてないように見せているから初心者はそう思ってしまう。
結合もそうだけど、結合するとループのネストが発生することも知らないプロも多い。
あまりにしつこいから、時間があったら、実行計画を書くよ。 サブクエリでorderby使えるようにしているオラクルがバカなんだよ
オラクルなんて使うなよ >>654
別に決め付けてはないだろ
オラクル社のサポートチームの主張が間違ってて
自称オラクルエンジニアの主張が正しいことも可能性としてはゼロではないと思ってるよ
だからきちんとした根拠を提示しろって言ってんの
でも散々的はずれなことを書いてきて
やっと提示されたソースが>>627みたいなレベルだから
今のところ誰も信用しない サポートチームという言葉は間違ってたか
どちらにしろThomas Kyteが間違ってて君が正しいという根拠があるんなら出してみれば >>655←わかったけど意地はってる人
>>659←まだわかってないバカw Oracleスレに行かないのはOracleスレにもっと詳しい人がいるからやろなぁ >>661
はあww
馬鹿が追加されたか…
パッケージソフトにおける外部仕様と内部実装の違いの意味を理解してないから
内部実装について延々と無駄レスしてんだろ >>657
まさかと思うけど、一般的なRDBMSの実行計画で結合はネステッドループしかないと思ってるわけじゃないよな
で、オラクルがサブクエリのデータを扱う方法が、サブクエリの順序を保障した方法しか選択しない仕様なのかどうかの問題だと思うんだが
>>658
多くのRDBMSでサブクエリのOrder Byは意味を持つようになってると思うけどな
ただしそのサブクエリ内でトップなりオフセットなり取るっていう前提で
rownumみたいにそのサブクエリ内ではOrder Byに影響されない変な疑似列使うのが悪いだけで
昔ならともかく今どき書くべきクエリじゃないなと
ORACLEにはそんな過去のバッドノウハウがいっぱいあるけどな
>>661
別に意地張ってるわけでもなんでもなくて、初めから仕様か実装かって話をしてたはずなんだがね
その区別すらついてないから実装をグダグダと説明してたのかね マニュアルは信用ならん！
AskTOMの回答は間違ってる！！
俺が正しい！！！
またすごいのが来たね
ジャイアンも真っ青 残念、やっぱり>>664も本質的にはバカだったかw あえて最初の質問>>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が自分でマニュアルで規定している。） >>667
あなたの考えだと、インラインビューの並び順指定をわざわざ付けたのは、ROWNUMのためという主張になるが自分でもおかしいと思わないのか？
どうもSQLがどう処理されているのかをあまり知らないからそんなヘンテコな発想になる。
副問い合わせの結果セットの並び順が不定なら、結合もグループ化もできないことになる。 >>670
SQLがどう処理されてるかと、仕様として保証する動作かどうかは関係ない
それすら分からわないから一人でヘンテコりんな珍回答を繰り返す まあしかし、メーカーに「保障された実装」とメーカーが発表した「仕様」でどれほどの違いがあるのかという
保障された実装というものを考えると実装の区別もどうでもよくね
つうことでこの話終わりにしようぜ >>670
>副問い合わせの結果セットの並び順が不定なら、結合もグループ化もできないことになる。
ここでいう不定って、もとのORDER BY以外の順序の可能性があるってことで
たとえばハッシュジョインならハッシュキー順に、ソートマージならその結合キー順にならんでる可能性があるんじゃないかね >>672
仕様として約束された動作でなければ断りなく変わりうるから
明確にアナウンスされる仕様変更とはベンダー側もユーザー側も対応が違ってくる
その違いが重要じゃないと言い切れる場合を除いて区別は必須 >>673
もともとの質問者はリレーショナルデータベースでは、ORDER BYしないかぎりはレコードの並び順は保証しないという仕様から疑問に思っただけだと思われる。
内部的にソートが発生するSQLだったり、並び順があるインデックスが使用されたり、たまたま実際のデータ格納順が同じで、ORDER BYがあってもなくても結果が同じなのと、RDBMSの仕様はまったく異なる話。
そもそもORDER BYは、結果に対する並び替え指示だから、イメージとしてはSELECTを二度行っているようなもの。 >>583の元の質問をさせてもらった者ですが、話が大きくなり申し訳ありません。
議論を止める権利などは無いと思いますが、
私個人の問題としては(一旦は)解決しているので報告させて頂きます。 律儀やね
ORDER BY ROWNUM じゃなく
ORDER BY 点数 DESC って書いておくといいよ
サブクエリ内と同じ表現ね >>678
ありがとうございます。今後、修正する際は気をつけます。
また、幾つかのレスで「Row_number()を使えば」とアドバイス頂いています。
仰るとおりで、Row_number()であれば心配しなくて済みそうですが、
何年も前に客先に納品しているシステムでして勝手に修正は難しい状況です。
作るときに気が付いて欲しかったなあ・・・ いい加減オラクルスレでやれっつてんだ、このクソボケ こんな過疎板でキレることじゃねーだろww
約1名を除いてwww >>679 の発言を見てるとまだ勘違いしてるようだな。 よ〜し今年中にSQL理解できるようになるぞ〜（＾〜＾）
よろしく！ ジャン＝ポール・サルトルさんとデニス・リッチーさんはどっちの方が天才ですか？ SQL超初心者です。
特定の列を主キーにする場合、主キーの名前をその列名と同じにすると何か問題出ますか？
主キーはどんな名前がお勧めですか？ >>689
そんな疑問持ったことなかったなw何も考えずにPK_hageとかしてたけどw
おまえセンスいいかもw >>689
制約には名前をつけることができるが
主キー制約の場合はテーブル毎に一個しか持てないので
名前をつけようがつけまいが利便性は特に変わらない
（ので、主キー制約自体に名前をつけることは通常ない） >>694
名前の無い主キーを作成出来るのですか？ 主キーの名前って言えば普通は列名のこと
PK制約の名前とは別だよ
CREATE TABLE Persons (
ID int NOT NULL PRIMARY KEY,
…
↑こう書けばDBMSで規定されてる命名ルール使ってPK制約名が付けられる >>696
「主キー制約」と「PRIMARY KEY 制約」は別物と言う意味に解釈できるのですが、
それで良いのでしょうか？ >>697
それは日本語で言うか英語で言うかの違いで同じ 制約に名前をつけなかった場合、OracleならSYS_○○、
DB2ならSQL○○など、システムが勝手につける名前がつく >>697
主キー列(カラム)は、そのテーブルで主キー制約がある列(カラム)のこと。
単に主キーというひとが多いからよくない。
主キー列はただの列名。主キー制約名は主キー制約名。
主キー制約に名前をつけなくてRDBMSが自動的に名前をつけるが、プロなら管理の都合上、ちゃんと名前をつける。 CREATE TABLE Persons (
…
PRIMARY KEY (ID)
…
こう書いても同じでDBが自動で名前を付けてくれる >>697
主キー制約 = PRIMARY KEY 制約 だよ。(主キー=PRIMARY KEY)
ひとつの列が主キーであるなら、その列の名前＝主キーの名前、という理解でよい
主キーの名前の付け方にはいろいろな流儀があるが、
SQLを利用するフレームワーク (例えば Ruby on Rails)との関係で
id という名前にすることが最近は多い
>>690 が書いているように、pk_hage みたいな人も多い
(「サロゲートキー」で検索するといろいろ出てくるはず) >>704
PK_hageはプライマリキー制約の名前で列名じゃないよ >>702 が書いているように、
RDBMSに主キーの値を自動的に割り振らせたいようなときにも
列名を id とする たぶん主キー制約名で一番多い命名は、PK_(テーブル名)。 >>705
制約名にすることが多いけど、列名にする人もいる
(質問者はそのあたりがごっちゃになっているっぽいけど) 制約名と列名を混同している人がいるな
複合キーの場合どうすると思ってるんだ？ ただ"ID"という名前の列を作って主キー項目にするのは、たいしたデータベースを必要としていない人の習慣。 主キー列名、主キー制約名、インデックス名がちゃんと説明できるレベルの人は、この板にはほとんどいない。 create table hoge (id integer primary key)
とした場合、制約名はシステムが勝手につけた名前になる
create table hoge (id integer constraint hage primary key)
とすると制約名はhageとなる >>711
SQLは同じ名前の列は、同じ属性と見なすから標準SQLでもナチュラルジョインがあるわけで、良いはずがない。 >>713
あんたどのRDBMSの方言で説明してんの？ >>708
お、そう
それはアンチパターンだね
>>710
トレードオフだからね
君はそれを知らないだけ >>716
何がトレードオフだよ。自分自身の関心事かそうでないかだろ。
有名なフレームワークやパッケージでもDBにうといのか、ひどい設計はよくある。 >>708
ごっちゃにはなっていません。
最初の質問に書いたように列名と主キー名をあえて同じにすると何か困る事が有るかどうかを知りたかったのです。私はPK_派です。 >>720
「主キー名」って何を指しているの？ 主キー制約の名前？ 制約名は重要なものじゃないから自動でつけられるだろ。制約だけ削除したい時にしか使われないと思う。
だから好きにすればいい。 >>722
なるほど。その言葉の使い分けはとても重要なので今後気をつけてー >>720
主キー制約のことを単に「主キー」とは呼ばないから
それだけは覚えといてよ 試したことも試そうと思ったことも無いけど、制約名ってカラム名とかぶっても大丈夫なのか？
それと他のテーブルとかぶっても良いのか？
SQLServerの2008R2だと
>制約名は、テーブルが所属するスキーマ内で一意である必要があります。
って書いてあるんだが だめだから自動のはSYS_連番とかになってるよね
自動付与のやつだとキー重複とかでエラーになったとき
エラーログとかでぱっとわからないからPK_表名にしてる。
インデックスの名前付けにいつも悩む。
表とか列とかつなげてくと長くなるし・・ 自称プロはOracleしか知らなそうだし、Oracle知らなそう >>730
自分は意味のあることは書かず、他人批判、もっと言えば第三者から見ても嫌なやつと思われる言動をするのは、よほどひねくれているぞ。 >>723
制約が重要でない？
まあ汎用機世代の人間がテーブル名もカラム名も重要ではないと言うのと同じ感覚なのか？ >>728
そもそもの>>689の話は、制約名を列名と同じにするって話じゃなかったのか
できるDBある？そんなことはできないで終わりの話じゃないのか DMLで多用するテーブル名、カラム名と基本的にDDLでしか使用しない制約名、インデックス名とじゃ
命名の重要度が違うのは当然だろう。 >>731
批判に見えましたか！
自覚があるんやなぁ 案の定質問の意味すらわからない奴が答えたがって場を荒すいつものパターンw >>733
できるのか
できるということはシステム的には問題ないって事だな
分かりにくくなったり手間が増えるかもしれんが
じゃあ、ＰＫ列名を全テーブルに対してユニークにする派の人なら
PK制約名をPKのカラム名と同じにするでもいいんじゃね
複合主キーどうするとかあるけどな
主キーは全部”ID”派の人はしらん
まあそう言う人は主キー制約の名前なんてそれこそ自動付加でいいんだろう >>741
PKはテーブルに一つなのと制約名で重複しちゃダメなDBMSがほとんどなので
自動付与じゃなければPK_tablenameみたいにテーブル名を入れといたほうがいい
インデックスと違ってPK制約名からどの列がPKなのかを知りたいって人いないよね？
それに他の制約名と違ってPK制約名は意識的に扱うことが基本ないから自動付与で十分なことが多い
SQL ServerやPostgresなんかは自動付与でも分かりやすい名前になる 今回初めて知って嬉しいのはわかるけどこんなにいつまでも引っ張るような話題ではない はいはい
自称プロなら管理の都合上、ちゃんと名前つける( ｰ`дｰ´)ｷﾘｯ
だもんねww 話題としては意味はあるけど、SQL質疑応答スレでやる内容ではないな すっごい不評なegov法令検索を設計したのは名古屋大学の外山教授ですか？
不評過ぎます すっごい不評な法令検索つくったくせに賞をもらっている意味不明な教授ですか？ データベース板でID見えてるやつは地雷であり荒らしよ
無視推奨 JavaでSQL書いてＲＤＢ使いまくりたいんですがそうなるためにこれ読んどけ見たいなのありませんか？
DBにデータを記憶するのはもちろんＤＢから数値や文字列を取り出してjava側で変数に代入したりして使いこなせるようになりたいです。 >>752
どれ使って良いかよく解らないんですが今はスッキリ解るシリーズのＳＱＬの本読んでます。
MySQLかpostgreSQLがよさそうだなと思いますがSQLserverの無料版もよさそうだなと思って迷ってます。
>>753
使い方はよく解りませんがＪＤＢＣって言うの使えばどのＤＢＭＳでも多少ルールが違えど似たような扱いができるんですよね？
スッキリ解るシリーズの実戦編に少し書いてあった気がしますがほんの少しだけだった気がします。
なんかJavaとDBの連携した使い方がみっちりつまった本ってありませんか？初学者でもわかるようなので・・・ その選択肢はWindowsで動かす予定かな
DBはDBで単体でまず扱えるようにならないとあとあときついよ >>754
Javaデータアクセス実践講座
中で使ってるのはMySQL
javaとSQLがそれぞれわかっていることが前提条件になっているとは思う
一応これでJavaからMySQLに接続してどうのこうのってのは出来るようになった。 Javaというより、RDBの勉強の方がいいと思うけどな。JavaとRDBのやり取りは、知らないフレームワークを介さないのであれば難しいわけではない。 >>757
>知らないフレームワークを介さないのであれば
学ばないでいつ知るんだよｗ
JDBCならともかくHibernateにしろSpring Data JPAにしろ
中身を把握するにはそれ相応の学習コストが必要 >>758
JDBC以外は全部、Java EEじゃないんですけど？
JDBCと言ってるのにいきなり謎のフレームワークを使えとはトレーナーとしてもありえない。 >>756
ありがとうございます。その本買ってみます。 >>759
トレーナーとして？
プロの次はトレーナー なんでそんなにプロにつっかかるん？
ふいんき悪くなるからやめたら？ SQL初心者です。
カラムをNULL許容型にするのは良くないと言った説明をいろんなサイトで見ます。
実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか？
DBを使いまくっている専門家の人の意見をお聞かせください。 >>765
専門家じゃないけど
> カラムをNULL許容型にするのは良くないと言った説明をいろんなサイトで見ます。
必要ないなら非許容にするべき
理由は一番下のリンク先とかを読んでみて
> 実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか？
そのケースなら俺は普通に使う
ただNULLの扱いは初心者にはちょっと直感に反するところがあるから注意が必要
https://codezine.jp/article/detail/532 >>765
リレーショナルデータベースではデータがない、値がないことを単にNULLと定義しているので、勘違いしないように。 自分はNULL活用してるけどな
0や空文字 と 未定義(未入力) とは意味合いが違う
フラグを別に設けるのも嫌だし
最近は言語側でも int? n; みたいなことが出来るようになって嬉しい >>770
NULLを検索するという設計がおかしい。 あれ、WHERE 項目 IS NULL ってインデックス効かないの？ NULLを検索する設計がおかしいとは思わんが
インデックスが効くかどうかはDBMSによる 「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの？ NULLを検索が多発している時点で考え方がおかしい。 >>774
言わんとすることはわかるが、なんで未入力とわかっている状態を検索して再度、確認する設計なのか？ だから、「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの？
机上じゃなくて現実の運用場面を経験したことないのか？ >>776
完全に入力が完了しないとコミットできない仕様(打ちかけを許容しない仕様)は
ちょっとユーザーフレンドリーじゃないと思うよ？ >>777
そもそもNOT NULLにしなくてはいけないと思い込んでいる初心者の話だろうが？ >>765
バグを生みやすいからNOT NULLにできるんならそうしたほうがいい
といっても全部排除するにはそれなりの手間がかかるので落とし所を決める必要がある
単にデータが無い状態を表現する場合じゃなく
データが「まだ」無い状態を表現する場合にNULLがよく使われる
簡単にデフォルト値が決められるようなものはNULL許容にしない >>778
入力完了済みのデータと入力途中のデータを一つのテーブルで管理するなら
完了済みかどうかの状態を管理するカラムを用意してそれを検索するんじゃないの？
特定のカラムがNULLだからXXという状態だと判断するって方法は極力避けたほうがいいと思うよ NULL許容はC#用語か。RDB用語で言ってくれ。不親切。 >>764
この流れを見れば
ふいんき悪くしてるのが誰かアホでも分かるよね？ この質問、例の人の自演だろ
あんま相手しないほうが良さそう nullはminとかmaxとかの集計関数で無視したい場合とか
更新が必要な項目で未更新状態の意味合いで使うな そういえばオラクルはキー項目でもnull許可できる糞仕様だったな
またオラクル使いか Oracleでもさすがに主キーにNULLは入らない
外部キーには入るがそれは別に普通のこと
それよりOracleは長さゼロの文字列とNULLが同じ意味になるという
糞仕様をいつまでも捨てられずにいることが問題 ま〜たこうやって、ボラクルの話になっていくのであった。 >>788
>nullはminとかmaxとかの集計関数で無視したい場合
条件で絞ればいいだけじゃないの？ 正規化してテーブルを増やしてデータの一貫性を保ちやすくするのは解ったんですが
テーブル増やしたらデータを追加するとき複雑になりませんか？
あっちのテーブルに日付情報入れて利用者ＩＤいれてこっちのテーブルに金額入れてとか混乱しそうな気がしますが NULL使わない人はデータが無い状態をどうやって表現するのですか？ NULLは必要だよ。
例えば日付型の生年月日があるとして、
NOT NULL なら default値はどうすんの？ 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への外部参照制約で表現できる NOT NULL縛りの是非はともかく、手間としては正規化とたいして違わない気がするが。
正規化を「いちいちそんな面倒なこと」と言う奴は少ないだろう。 null 可能列が10個あったら表が10個増えるのか w
まあ頑張れやとかしか言えない 単純に10個増えるとは限らないよ
派生関係でうまく処理できる場合もあるけど
任意項目があるたびに派生関係を作っていくのはあまり現実的ではないよね 思いつきでアホなこと言ったばかりに言い訳が苦しいなw >>800
で、外部結合して結局項目ｂがNULLになるのな >>810
ならなかったらそもそも>>796への答にはならんだろ そもそも「データが無い状態」という情報をどうしても記録しておかなければいけない状況ってのはそうそうない
そのシステムの性質にもよるけど 閉世界が前提だから、「データがある」状態だけ記録しておけばそれが存在しなければ「無い」だと思うが。
明示的に「無い」ことを記録しているわけじゃないだろう。 >>814
いやそういう禅問答的な屁理屈を言われても「その通りですね」としか言えんけどw
何か反論したい事でもあるの？ >>812
外部結合の結果とはいえ、デーが無い場合はNULLになるってことだ
直接テーブルに入れてないとは言えNULL使ってるわけだから>>796の回答足り得てないと思うけど? >>815
データが無いことを記録する必要があるかどうかという問い自体がナンセンスということ。 >>812
それってb列に直接null入れるとのたいして違わなくね？ >>816
NOT NULLにしたとしても外部結合したらNULL発生しうるじゃん
そうすると>>796への回答足り得ないの？ 派生関係はNULLを使わないために導入するものじゃないから話が噛み合わないのかもね >>817
ん？つまりnot null制約自体の存在を否定したいのか？ 「データが無いことを記録する」手段が唯一NULL許可フィールドのみなのであれば
NOT NULL制約と関係なくはないのかもしれんが、まぁ、関係ないよな。 >>822
いや論じる事がナンセンスなんだろ？
その事と関係あるとかないとか唯一とか関係ないよね？
お前は何を言いたいの？ 質問者の>>796、とりあえずどうにか話の方向をどうにかしてくれよ。
nullの話は簡単に結論が出るようなもんじゃないんで、いつまでも続けられても鬱陶しいだけなんだ 人と違ったことを言わないと気がすまない人っているね
俺は俺はってw こんな過疎スレで話が続いても誰も困らんだろ
それより質問者を含めスレ読んでるやつが
多くの選択肢を知ることができるほうが意義があると思うぞ 禅問答は傍で見ているとうざいが、かといってテーブル10個作るのは面倒だなんてレベルの話ばっかりでもなぁ。 >>823
「必要性があるとないとにかかわらず、意図的に「記録」するまでもなく、
「データが無い状態」というのはデータベース上のデータ自体で表現される
ものだから、>>813で書いている言明はそもそも意味がない」
本来なら「その通りですね」で終わってた話。 >>827
無意味なテーブル作るのなんか、たとえ1個でも願い下げだわ
作るのが面倒とか以前の問題 >>819
>>796は、NULL使わない場合を想定した質問だぞ
データがない場合はNULLですだと、そもそもの質問の前提が成り立ってない
>>820
>NULL使わない人はデータが無い状態をどうやって表現するのですか？
に対する答えとして派生関係を出してきたはずだが
>>828
意図的にデータがない状態を記録するのに、NULLを使う手法はありかなしかって話をしてたんだと思うけど
そんな要件は現実的にあり得ないってならまあその意見もわからんではないが
実際のシステム設計じゃままある要件なんだがな
いい加減スレ違いなのは確かだし、これ以上は設計スレあたりで ちょっとした疑問なんだが、
ユーザーと所属するグループ、チームを表すテーブルを作る場合、カラムの命名についてはどっちが主流なんだい？
パターン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句の書き方が気にくわないとか色々あるだろうけど、一先ず置いといて、
命名として、どっちなんだろうなと思って >>836
JOINの結果NULLが現れるから回答になってないってのはさすが屁理屈が過ぎるだろう。
>>796の前まではフィールドのNOT NULL制約について話していたわけだし、>>796も
それを踏まえた質問ととらえるのが自然。 >>833
どっちが主流かは知らんけど俺はパターン1 >>833
プライマリキーとそれ以外のカラムでは扱いが違う
プライマリキー以外のカラムにテーブル名を単純なプリフィクスとして使う人は少ない
プライマリキーについてはDBよりの人はuser_id派が多めな印象
アプリよりの人はid派が多い印象(言語やフレームワークにもよるが)
個人的にはuser_id派 >>835
>>836
サンクス
後だしで悪いが、
idはpk、
pk以外のカラムについては、name以外の話はなしでおなしゃす。
(nameはこうするとかのみで)
話が膨らんでしまうと発散して意味を成さなくなるので。
ちなみに自分はパターン2派。
関連がが分かりやすいので。
けれども、パターン1でも、テーブル名から予測可能だし、そもそも関連については外部キーで定義しろよと思うので、思想の話かなと。
職場でも、両派いるので、時流はどちらなのか知りたい次第です id派は基本的に全テーブルのプライマリキーをidという名前にする前提なので
単に命名の問題じゃなく設計に関わってくる問題
この辺読んで両方の意見を参考にするといいと思う
https://softwareengineering.stackexchange.com/questions/114728/
idじゃなくbug_idにしようぜってのがSQLアンチパターンにも出てくる >>838
サンクス
参考も読ませてもらうよ。
そんなあなたは、設計も命名も自由にできるとして、どっちにするの？ >>833
状況によるんでどっちが主流とか無いんじゃね
ＯＲマッパーとか前提で、IDやSQLをあまり意識しないでいいなら１
生SQL扱うなら、本来の考え方からいけば２だろうな SQL Serverの管理ビューは１で
Oracleのデータディクショナリは２だな
他のDBMSはどうだろう 論理レベルで複合キーやナチュラルキーのテーブルを
物理レベルでどう扱いたいかが重要な分岐点 >>844
同じものには同じ名前をつける
違うものには違う名前をつける
これが原則
たとえば標準単価と販売単価を、同じ単価と言う項目名で定義するのはよろしくないだろ
ここ設計スレじゃないしこれ以上はどっか別のスレでよろしく >>846
何で列名だけで判断してるんだ？
標準価格.単価 と 販売価格.単価 が同じものに見えるなら病院に行った方がいい そんな紛らわしいこと実務でやる奴いたら、とっちめられるぞ >>846
何をもって同じとするのか
何をもって違うとするのかの基準が違うから
id派とuser_id派に分かれるんだよね
例えば各テーブルに内部的な管理用としてレコードの更新日時を記録する場合
最終更新日時とかの名前でどのテーブルも同じカラム名でも別におかしくない
レコードの更新日時という意味で同じだから
id派の考えはその延長 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
) >>852
無理矢理すぎる理屈だな。
登録・更新者、登録・更新日時の項目は、結合項目として使用するなどどいう話は、あなたの中でもないだろうに。 そうかなあ
テーブル名もカラム名の属性を表してるわけで
テーブル名をテキトーにつけてなけりゃ
情報の一部だべ >標準価格.単価 と 販売価格.単価
テーブル名まで書くんだったら、最初から
>標準価格 と 販売価格
で良いんでは >>855
テーブルの論理名はエンティティ名といって、適当に名前をつけていたら、混乱するだけでよいことはない。 >>856
彼はオブシェクト指向とごっちゃになっているのだろう。 価格というテーブルがあって
商品：外部参照(商品マスタの主キーを参照)
適用開始：日付型
適用終了：日付型
区分：0:標準 1:販売
通貨記号：USD/JPY・・・
単価：通貨型
という感じに定義されていて
標準価格や販売価格が実はテーブルじゃなくて、
価格テーブルを元にしたビューだった
という風なら理解できるぞい >>859
価格というテーブルには、
標準価格か販売価格のどちらかしか
入らなくなりませんか？ user_id派は昔ながらのリレーショナルモデル、id派はERモデルの発想だろう。
そのへん区別できてない人も多いけどな。 >>849-850
爺は早めにくたばれよ w
>>856
テーブル名書かないの？
単一テーブルしか扱わない時はいいけど複数テーブル使ってる時にテーブル名を書かないとかその方がどうかしてると思うけど
>>858
はあ？
ひょっとして
ドットで繋いでる⇒オブジェクト指向
とでも思ってるのかよ w
全然関係ないだろ >>859
そのケースで標準価格と販売価格を一つのテーブルで管理するメリットって何？ >>861
リレーショナルモデルとERモデルの違いについて、簡単にで良いので説明してくれ >>862
>複数テーブル使ってる時にテーブル名を書かないとかその方がどうかしてる
複数テーブル使うときにテーブル名で「修飾」しないで済むようにしましょう、ってのが根本にあるわけで
そのためにjoinにusingとかあるんだが
まあなかなか現実的にはそうすると項目名がやたら冗長になったりするから適当なとこで妥協するんだけどね
個人的な感覚では
標準単価なんかは妥協する必要のない範疇
更新日時なんかは妥協して問題のない範疇
IDなんかが議論の分かれるとこなんでよく話題にされる
まあ、宗教論だよ >>865
>標準単価なんかは妥協する必要のない範疇
>更新日時なんかは妥協して問題のない範疇
この線引を明文化して規約にしないと
同じデータベース内でブレた命名基準が使われて
一番使いにくい物ができあがる 更新日時は文字通り誰が解釈しても一意になりそう
標準単価は、何を指すのかな？
商品なら、定価だったり、希望小売価格だったり
賃金なら、時間給か日給か月給？
その現場毎に決めるんだろうな >>852に書いてるようなデータベース上のレコード最終更新日時と
ドメインで意味がある更新日時(サイト更新日時とかスレ更新日時とか)だと解釈違ってくるよね
システム的な事情で「スレ」テーブルのデータを更新した場合でも
ユーザーが目にするスレ更新日時は更新されない事も有り得る >>864
先に属性があって、それらの間に何らかの関係が存在するときにそれをリレーション(テーブル)として
表現するのがリレーショナルモデル。属性はテーブル固有ではないのでそれ自身識別できる名前に
することが多い。
問題領域からエンティティを抽出してそれに含まれる属性を記述するのがERモデル。基本的に
属性はそのエンティティ固有のものだから他のエンティティと属性の名前が重複しても気にしない。
ただしERモデルをRDBに落とし込む際は他エンティティとの関係を表す参照フィールドが必要になる
場合があるが、これはそのエンティティに属するものとは言えないため必ずしも一貫性はない。 c1,c2,...,c10と言う10個のカラムがあって、その中のどこかにkeywordが有るか判定するなら
c1 like %keyword% or c2 like ...
みたいに10個並べればいいですよね。
ではkeyword1とkeyword2が有るかどうか判定するなら同じくずらずらと条件を並べるしか無いですか？
もっとスマートに簡潔に書く方法は有りますか? >>871
なるほど。
実際の開発の現場でもそういう手法を使うんですか？
ずらずら並べる方法と連結する方法とでは、どっちが検索が速いでしょうか？ LIKE検索の時点で似たり寄ったりだし
どうしても早くしたいなら全文検索エンジンとか使え
http://www.clear-code.com/blog/2015/5/25.html >>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するか >>870
そんなSQLが必要なテーブルがおそろしいわ。 c1...c10が等価で交換可能なのだとしたらそもそも第1正規形じゃないから実際の開発の現場で見かけるのは稀。
等価じゃないのに「その中のどこか」なんて問い合わせするのも稀。
「実際の開発の現場」じゃまず現れないレアケースなんで「スマートに」なんて期待するな。 >>875,876
正しい設計のデータベースにも普通にありふれたテーブルですよ
経験不足なんですねあなた達 自分が面倒見ているサイトで
ユーザーにアイテム検索させる時に
このようなSQL書いてるな そんな面倒なのを非手続き型SQLでやろうとする発想がすごい。 >>876
バカ設計はどこにでもある。稀じゃない。 >>876
例えば社員情報を氏名、役職、所属、電話番号、社員番号の一部で検索するとか普通にあるけど？ >>874
すみません、このコードを試してみたのですが外部結合など
初めてやるので実行するとエラーしました（SQL ServerとMySQL）。
このサンプルコードは、完全なSQL文ですか？
それとも概略を示したものですか？ >>884
SQLがいいか悪いかを無視しても少なくともLIKEの前にANDがない。 シンタックスすら覚束ないのに善し悪しを語りたがるバカｗ ああ、間違ってるな。
ただあのSQLのkeywordとはなんだろうな。 >>884
何をもって完全とするかは君にしかわからないけど
SQL ServerでもMySQLでも問題なく動くよ
外部結合もやったことなくて何のエラーが出たかも分からないようなら
自分の今のレベルを素直に受け入れてLIKEでベタ書きするのがスマートだと思うよ >>874
ウンコード・マニアがSQLに対応していたらかなりいい点が貰えそう なんだかよくわからないけどとりあえず煽ってみるウンコバカw このスレは想像、想定で回答する人間が多くて驚く。エスパーなのか？ 案外おっさんがいるんだな。
エスパー魔美を連想するとは。 >>895
クエリ書くのはSQLのほうが簡単
MongoDBでクエリ書くのもそんな難しいわけじゃないけど
JavaScriptやmap/reduceの基本理解は必須 簡単か難しいかは比較対象によるからね
SQLと比較すれば難しいし手間もかかる
SQLは全くの素人でも3日程度の研修受ければ
自分が欲しい結果を取得できるレベルにはすぐなれるが
JavaScriptだとそうはいかない 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 >>898
3日でSQLマスターするってスゲえな
どうやるんですか？ >>902
マスターは言い過ぎ
文法を理解して自分が欲しい結果を取得するためのクエリが書けるようになるレベルな
ちゃんとした会社の研修コースを受ければいい
本で言えばスッキリのレベルなら2日コース
ゼロからはじめるのレベルなら3日コースが標準 なぜsqlもmongodbも初心者レベルなのに答えようとするのか select ...
where カラム名 like '%'
みたいなwhere条件を追加した場合、このwhere条件が無い場合に比べて
検索時間が遅くなったりしますか？ そりゃDBMSのオプティマイザの賢さ次第だな。試してみればいい。 >>905
やってみなはれ。
やらなわからしまへんで。
鳥井信治郎 で、遅くなったとして「じゃ条件つけるのやーめた」なんて出来るのか？ クエリ組み立てる側で手間かければできないことないだろ。
もともと意味のない条件をつけるのがおかしいわけで。 >>905
ただSQLだけで遅いの速いいうのはナンセンス。 どんなSQLだけだったら遅いの速いのいうのはナンセンスじゃないんだこれ？ 質問させてください
番号 住所
(number) (address)
1 東京
2 大阪
3 東京
住所でGROUP BYして番号順に並べたい
さらに住所の合計を取得したい
SELECT *,SUM(address) FROM table_addr GROUP BY address ORDER BY number DESC;
これだと番号順に並びません。どうしたらいいでしょうか？よろしくお願いします。 番号順って、小さい順にしたいの？それとも大きい順？ >>913
レスありがとうございます
一応DESCですがASCでも構いません >>914
SELECT MAX(number) AS number, address, COUNT(address) AS kensu
FROM table_addr GROUP BY address ORDER BY MAX(number) DESC; 自作自演なのか？
なんでsumがカウントの間違いだとわかるのか？ まあ住所の合計って意味わからんからな
よく気づいたと思うけど GROUP BY とORDER BYって同時にできるの？ >>919
グループ化したものを並び替えることはできる。
並び替えたものをグループ化しても意味がない。 >>920
へえー
じゃあグループ化してないカラムを並び替えすることは出来る？ SQLってcasesensitivitieじゃないんですよね？コマンドを小文字で書いても良いですか？
いちいちcapslock雄の面倒 SQLって英単語の羅列で構造がぱっと見わかりにくいから、昔は予約語だけ大文字にするとかあったけど、
最近はエディタでハイライト(色分け)できるのが普通だから全部小文字でも全然問題ないな。 小文字でも普通にオッケーなんですか
sqlite のクエリを書くのにpythonのIDE使ってるんでsintax highlightは効かないので見にくいかもしれない
一長一短すね 使ったことあるのは oracle, SQL-Server, PostgreSQL, sqlite3, MySQL だけだけど、全部小文字でも問題なかったな 一行に詰め込もうとかしなければ小文字でも読めるやろ 英文(って言うかアルファベット)の大文字の綴りなんて、まず読みにくいだろ？ 大昔はコンソールから大文字しか打てなかった時代があった COBOLも小文字
というかcase insensitiveやで COBOLは今は大文字小文字混じりだよ
FORTRANもね
SQLは特定の場所以外大文字小文字関係ない
内部では処理系によって大文字か小文字に変換して処理する 板違いかもしれませんが、hirdb詳しい方いませんか？いたらhirdbのストアドが使い易いか教えて下さい。使ってるのみたことなくて… >>938
ネットに公表されているマニュアルを見たのか？
ストアドは標準SQLだから標準SQLとかけ離れていることはない。 >>940
みました。標準的にみえるけど、あまり使われてないDBMSだから落とし穴がないかこわくて。そもそも自分がそんなにストアド使ったことないから判断しかねるのもあります。
それと、過去ログにはトリガー設定して自動で動くようにはできない？？との記述もあって… 名前 年齢 住所の他にその人がどういう人なのか0個から複数の属性を持たせたいのですが
配列にするってのはデータベース的によくないんですよね？
そこは属性テーブルを別個作って
さらに属性と個人テーブルを関連付けさせるための関連付けテーブルを用意すればいいのでしょうか？
個人テーブル
ID 1
名前 山田太郎
年齢 38
住所 東京都
属性テーブル
ID 1
属性名 会社社長
関連テーブル
ID 1
個人ID 1
属性ID 1
こんな感じですか？あと関連テーブルの個人IDと属性IDは外部キーでいいのでしょうか？ 変な感じɿ(｡･ɜ･)ɾ 1:nなら属性テーブルが直接個人IDもってても良いんじゃね >>945
レスありがとうございます
なるほど
この情報が社内情報のようなものならそれでよさそうですね
実際はn:nの情報になります
外部キーはよくわからないのですが参照のようなもので
deleteされて整合性がとれなくなりそうなときにうまく解決してくれるようなものなのかなと
（子テーブルで親の参照がなくなることを警告出したり、整合性とるために削除したり？）
もうちょっと勉強してきます Googleのアドレス帳なんかは任意の項目が入力できるから
>>943みたいになってるんじゃないかな ほとんどの場合任意の属性を記録するのはシリアライズしたテキストで十分なんやで
オーバーエンジニアリングにならんように気いつけや NOSQLとかならわかるけどシリアライズしたテキストをRDBで使ったら負けかなと思ってる 逆だわwスキーマレスなNOSQLならなんぼでもオレオレ属性持てるやんw おまけみたいな項目だけテキストで持つとかでもええやん
ゼロイチ思考は損よ >>950
シリアライズしたテキストなんて曖昧なデータぶっこむのもOKだけど
RDB使ってんなら関係性重視したいよねっていう >>952
お前がやりたいなら止めはしないけどお前が重視したいらしい関係性て
おそらく関係モデルの関係とはなんも関係ない関係性やでw RDBじゃないDBMSの選択肢が極端に少ないって実情があるからな ＞おそらく関係モデルの関係とはなんも関係ない関係性やでw
それはない
正規化から勉強しなおしだな >>955
いやあるからわざわざ言っとんのやでw
意固地のベイビーちゃんやなw >>955
要件もはっきりしてないのに
> それはない
って言い切る奴はバカ認定してもいいかな？ 奇をてらわずに>>943でいいじゃんな
スループット確保したいとか入力値が無法地帯でモデリングしようがないとか
そういう時に初めて検討すりゃいい KVS
ID 1
VALUE {
"name": "山田太郎",
"age": "35",
"addr": "東京都",
"attr": [
]
}
これじゃRDBの意味がない KVS
ID: 1
VALUE: "山田太郎"
ID: 2
VALUE: "35"
ID: 3
VALUE: "東京都"
にすると扱うのが却って難しい >>960
えっ？
どこがブーメランなんだい？
ちょっと説明してみ MariaDB(MySQL)で質問です
Userテーブルがあり、各ユーザーはpointというint型のフィールドがあります
このpointの合計がx以上になる分だけのユーザーをソートして取得したいと考えています
色々と調べたり試行錯誤してみましたが限界を感じましたので
どうか皆様の知恵をおかしください。よろしくお願いします pointの合計ってなに？なんか計算をしたいの？
・Userテーブルがある
・各ユーザーはpointというフィールドを持つ
ちゃんとテーブルの構成を書かないとこれだけじゃよくわからない ユーザーIDでgroup by し sumでpointを集計
order by ユーザーID
んでhavingで sum(point) > x
みたいな？ 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
J7FO55UASR >>968
でも、君あちこちにコピペしてて苦労してそうじゃん
もっと簡単に稼げるぞ where 句のIN演算子の書き方ってモヤっとしない？ 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使ってます >>971
＞前回の日付から遡って1年間の間
頭悪くて済まないが、この意味がよく分からない >>972
言葉足らずでごめん
日付でソートした際の1つ前のレコードから遡って1年間
A | 16-01-01 | 10
A | 16-11-01 | 20
これだと、1行目はこの前の時点のデータがないからNULLで、
2行目のは1つ前のレコードである16-01-01から遡って1年間を集計期間にしたい いきなり最終形にしようとするからわからないんだろうな。 少しずつ実現するのが近道部品を組み立てる組み立てるつもりで考えてみよう SQLポンコツなんだ…
せめてヒントをくれるとありがたいです ID列でグループ化、日付列がcountで2レコード以上のレコードを取得して、日付が最小のレコードを取得する。
あなたのためにあえてSQLは書かない。 >>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 >>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別にしてもいろいろ残念 >>980
サブクエリにorder by使えないと思う
オラクルは使えるみたいだけど >>981
すいませんtop があればサブクエリでorderby 使える事知らなかった >>981
> サブクエリにorder by使えないと思う
SQL-Server 2005以降ならtopを指定してたら使える 出来れば ostgres をベースに回答してやろうよ みなさまありがとうございます
相関サブクエリ？で値でソートしたあとの最初のレコードを取ってくれば良いんですね
チャレンジしてみます >出来れば ostgres をベースに回答してやろうよ
Postgres ？
なんでPostgresなのかね
テンプレに
【質問テンプレ】
・DBMS名とバージョン
ってあるのにそれを書かない質問者の不手際だろ >>986
971にpostgresって書いてあるけど、 オストグレスは知らんが テンプレ通りではないが、
>>971の最後の行に
＞Postgres使ってます
こうあるので >>992
select
from (select
group by
having count(*) > 1)
where >>993
何が言いたいのかわからない
>>980はすくなくともSQL Serverなら正しく動いた
DBMSによってはサブクエリのorder byとtop(limit)が効かないかもしれんが
ポスグレがそうならそう指摘して正しく動くSQL示せば良い話 >>992
select
from (select id, min(日付)
from テーブル
group by id
having count(*) > 1)
where 日付から考えるからおかしくなる。
これがプログラムならそういう順序では考えない。
質問者の「ソート」という言葉に惑わされてるんだろうな。 正確にはIDでグループ化した日付のMAXと、IDでグループ化したcountの結果の比較だけど、初めから答え書く気はない。 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 542日 22時間 52分 44秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
