SQL質疑応答スレ 17問目 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
このスレは 「こういうことをやりたいんだけどSQLでどう書くの?」 「こういうSQLを書いたんだけどうまく動きません><」 などの質問を受け付けるスレです。 SQLという言語はISOによって標準化されていますが この標準を100%実装したDBMSは存在せず、 また、DBMSによっては標準でない独自の構文が 追加されていることもあります。 質問するときはDBMS名を必ず付記してください。 【質問テンプレ】 ・DBMS名とバージョン ・テーブルデータ ・欲しい結果 ・説明 前スレ: SQL質疑応答スレ 16問目 http://echo.2ch.net/test/read.cgi/db/1447160858/ >>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制約名をPKのカラム名と同じにするでもいいんじゃね 複合主キーどうするとかあるけどな 主キーは全部”ID”派の人はしらん まあそう言う人は主キー制約の名前なんてそれこそ自動付加でいいんだろう >>741 PKはテーブルに一つなのと制約名で重複しちゃダメなDBMSがほとんどなので 自動付与じゃなければPK_tablenameみたいにテーブル名を入れといたほうがいい インデックスと違ってPK制約名からどの列がPKなのかを知りたいって人いないよね? それに他の制約名と違ってPK制約名は意識的に扱うことが基本ないから自動付与で十分なことが多い SQL ServerやPostgresなんかは自動付与でも分かりやすい名前になる 今回初めて知って嬉しいのはわかるけどこんなにいつまでも引っ張るような話題ではない はいはい 自称プロなら管理の都合上、ちゃんと名前つける( ー`дー´)キリッ だもんねww 話題としては意味はあるけど、SQL質疑応答スレでやる内容ではないな すっごい不評なegov法令検索を設計したのは名古屋大学の外山教授ですか? 不評過ぎます すっごい不評な法令検索つくったくせに賞をもらっている意味不明な教授ですか? データベース板でID見えてるやつは地雷であり荒らしよ 無視推奨 JavaでSQL書いてRDB使いまくりたいんですがそうなるためにこれ読んどけ見たいなのありませんか? DBにデータを記憶するのはもちろんDBから数値や文字列を取り出してjava側で変数に代入したりして使いこなせるようになりたいです。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる