詳細は下記スレをご覧下さい やりすぎ防犯パトロールは創価学会と警察署の仕業だった https://rio2016.5ch.net/test/read.cgi/bouhan/1516500769/0633NAME IS NULL2018/02/04(日) 16:38:15.37ID:ygeeHQOY SELECT "User"."id" AS "User__id", "User"."company" AS "User__company", "User"."name" AS "User__name", "User"."itaric" AS "User__itaric", "User"."system" AS "User__system", "User"."year" AS "User__year" FROM "public"."users" AS "User" WHERE 1 = 1 ORDER BY "User"."itaric" asc, "User"."system" desc
複数ソートを実行したいのだけれども、実行できてる?? 0634NAME IS NULL2018/02/05(月) 07:58:44.26ID:Q16Lz/UI>>633 意味のないダブルクォーテーションと、意味のないWHERE句の条件と、複数ソートという謎の用語がわからない。 0635NAME IS NULL2018/02/05(月) 08:28:06.73ID:??? ダブルクォーテーションはOracleから持ってきたからなのかも 複数ソートは複数キーのことかも Whereはよくわからん
って言うか何を言いたいのかよくわからん w 0636NAME IS NULL2018/02/05(月) 16:22:38.74ID:??? メディアオプションを[追加]にしてジョブで毎日バックアップしていますが これだとどんどんバックアップファイルのサイズが大きくなってしまうので 常に最新の10日分だけ残すというバックアップの方法を教えてください よろしくお願いします 0637NAME IS NULL2018/02/05(月) 19:13:11.77ID:wLbeZJwJ>>634 意味のないレスすんな 答えられんのなら黙ってる事だな 0638NAME IS NULL2018/02/05(月) 22:52:50.94ID:Q16Lz/UI>>637 仮定の話をするのはIT技術者ではない。 0639NAME IS NULL2018/02/05(月) 22:54:32.98ID:Q16Lz/UI Where 1 = 1 だけでSQLがまったくわかってないことがわかる。 0640NAME IS NULL2018/02/05(月) 23:14:09.67ID:??? 少なくとも文法はわかってるようだが? 0641NAME IS NULL2018/02/06(火) 04:47:07.31ID:??? 「WHERE 1 = 1」は↓みたいに書いとくと任意の行をコメントにするだけで条件の入れ替えが簡単に出来るから開発時はたまにやるかもw
WHERE 1 = 1 AND フィールド1 = '○○○' AND フィールド2 = '△△△' AND フィールド3 = '□□□' 0642NAME IS NULL2018/02/06(火) 07:36:44.36ID:AHs/sZxD>>641 やめろ 0643NAME IS NULL2018/02/06(火) 07:49:13.23ID:???>>641 プログラムでsql作る時普通に使うな 0644NAME IS NULL2018/02/06(火) 11:48:04.77ID:??? うん。0 <> 1 も時々 0645NAME IS NULL2018/02/06(火) 20:47:44.36ID:WoDXj185 【有賀さつき(52)小林麻央(34)黒木奈々(32)】 世界教師 マイトLーヤ「早死には原発事故の隠蔽のせい」 http://rosie.5ch.net/test/read.cgi/liveplus/1517828233/l500646NAME IS NULL2018/02/07(水) 03:21:36.81ID:???>>641 0=0 じゃダメなん? 0647NAME IS NULL2018/02/07(水) 21:05:34.23ID:???>>646 ゼロはオーと打ち間違えやすいので避けたい テンキーなら間違えないが ノートパソコンだとゼロとオーは隣あっていて打ち間違えやすい 0648NAME IS NULL2018/02/07(水) 22:14:15.01ID:nx8/8ate>>647 見間違えるのはわかるけど打ち間違えってw それおまえだけだからwwww 0649NAME IS NULL2018/02/07(水) 22:38:55.94ID:??? 配列がランダムに変わるキーボードか? 0650NAME IS NULL2018/02/08(木) 06:50:41.49ID:??? そもそも[O] なんて名前つけないし 0651NAME IS NULL2018/02/08(木) 07:38:34.47ID:??? where 1=1はsql文の慣例句みたいなものでgoogleで検索してもいっぱいでてくる。そんな事で悩む必要はない。 http://kinocolog.com/where11/0652NAME IS NULL2018/02/08(木) 11:53:55.72ID:??? 100文字以内のデータしか入れない場合には nvarchar(100) で良いですよね? 質問1 全角文字で半角文字でも100文字入るんですよね? 質問2 nvarchar(max) にすると無駄にメモリやハードディスクを使いますか? 0653NAME IS NULL2018/02/08(木) 13:35:25.45ID:??? 回答1 Yes 回答2 No varcharは可変長だから入ってる分だけの消費 0654NAME IS NULL2018/02/08(木) 19:08:59.93ID:???>>653 ありがとうございました。 >varcharは可変長だから入ってる分だけの消費 では、カラムが10文字でも100文字でも とりあえずnvarchar(max) を使っておけば良いのでしょうか? どういう場合にnvarchar(100) などを使うのでしょうか? 0655NAME IS NULL2018/02/08(木) 19:18:47.90ID:??? index張らないならMAXでもいい 張るなら900バイト以下でなければならない 0656NAME IS NULL2018/02/08(木) 22:35:21.32ID:??? 教えてください。
とりあえず 658 さんの方法を発展させてやってみようと思います。 657 さんの動的 SQL は便利すぎ。 0660NAME IS NULL2018/02/11(日) 01:14:00.27ID:??? 一時テーブルに検索文字列セットして left joinでlike 演算子で連結してnull のものだけ取ればいいように思える https://teratail.com/questions/659490661NAME IS NULL2018/02/11(日) 04:44:52.94ID:iUCuMXup>>659 動的SQLはできるだけ使わないように。条件の組み合わせが大量になければ、静的SQLで書く。動的SQLはSQLの組み立て方によっては、可読性、保守性がさがり、さらにコーディングミスをおこし、スペースを入れわすれた等おかしなSQLを簡単に仕込んでしまう。 0662NAME IS NULL2018/02/11(日) 04:51:00.67ID:iUCuMXup>>656 それ単にパラメータによって、LIKE用の文字列を作り分けておけばいいだけ。 06636562018/02/12(月) 00:49:37.83ID:???>>660 ありがとう。 left join で like って使えるんですね。 その結果が null のモノだけって発想がありませんでした。 こちらをまず試してみます。
>>661,662 ありがとう。 うん、そう思って動的 SQL は最後の手段にしとこうかと。 0664NAME IS NULL2018/02/12(月) 07:54:28.97ID:??? こうしてまたバカのバカによるバカのためのバカノウハウが広まるのであった 0665NAME IS NULL2018/02/12(月) 09:52:09.80ID:??? スマートな解決策書けてりゃ格好いいんだけどなぁ... >>664だとバカの遠吠えにしかなってない w 0666NAME IS NULL2018/02/12(月) 11:51:24.82ID:tzC/U9n1 結局、RDBになるとSQLが魔法になってプログラムの見た目はシンプルでも、RDBMSの処理が複雑になるようなものを作るやつが多すぎる。
RDBの処理が汚なくなり、無意味に負荷がかかるようなプログラミムを書いても、RDBMSの処理がどう処理しているのか考えないから、珍妙なことを推奨する。 0667NAME IS NULL2018/02/12(月) 12:19:14.11ID:???>>665 そのスマートな解決策()が動的SQLなんよ バカには難しいらしいけんどねw 0668NAME IS NULL2018/02/12(月) 13:30:52.28ID:??? 動的SQLでどや顔 w 0669NAME IS NULL2018/02/12(月) 19:57:26.33ID:tzC/U9n1 データベース板はレベルが低い。リレーショナルデータベースに詳しくもないのにこうだ、これが正解だと言いはる人間ばかり。 0670NAME IS NULL2018/02/12(月) 22:04:38.94ID:??? せめてどこがどう「無意味に」負荷がかかってるのか書けないのかね 0671NAME IS NULL2018/02/13(火) 01:01:59.31ID:mpzcP+RA>>670 検索結果が同じSQLでも、RDBMSではSQLの構文解析(ソフトパース、ハードパース)が行われ、実行プランも作り直しなることもあり、RDBMS側の処理が変化する。
無いものは抽出できない、とは思うのですが… 0690NAME IS NULL2018/02/15(木) 18:56:53.86ID:???>>689 LEFT JOIN
スレチじゃね? 0691NAME IS NULL2018/02/15(木) 19:10:24.66ID:L39WhMJw>>689 自ら吐いた言霊に呪われとるやんw
無いのは売上 抽出するのは顧客
な? 0692NAME IS NULL2018/02/15(木) 21:10:45.04ID:??? SELECT * FROM 顧客テーブル WHERE NOT 顧客ID IN (SELECT 顧客ID FROM 売上テーブル)
みたいな風かな 0693NAME IS NULL2018/02/15(木) 21:23:39.60ID:???>>692 そういうINの使い方は悪手だよ NOT EXISTSかLEFT JOINを使おう 0694NAME IS NULL2018/02/15(木) 21:23:57.09ID:???>>689 >>690で答え出てるけどないものを抽出するんじゃなくて、「売上に紐付かない顧客」を抽出するってこと 0695NAME IS NULL2018/02/15(木) 21:31:33.97ID:???>>694 そういうJOINの使い方は悪手だよ NOT EXISTSを使おう 0696NAME IS NULL2018/02/15(木) 21:40:30.01ID:??? exists は確かにわかりやすい記述だけど遅い 大量のデータで使うとサーバーが唸る できるならinner joinでやったほうがいい http://kkoudev.github.io/blog/2013/09/14/sql/0697NAME IS NULL2018/02/15(木) 23:18:27.60ID:???>>696 NOT EXISTSをINNER JOINにするのは無理だし MySQLはNested Loopしか使えないからね 他の一般的RDBとは事情が違うよ 0698NAME IS NULL2018/02/15(木) 23:21:53.94ID:???>>695 NOT EXISTSのほうがパフォーマンスいいことのほうが多いけど LEFT JOINが悪手ってわけでもないと思うけどな
少なくとも質問者はLEFT JOINを理解してない風なので そっちからはじめたほうがいい 06996892018/02/16(金) 00:03:31.60ID:??? みなさまありがとうございます。 LEFT JOINでできるとは思いませんでした…頭が硬いですね。 教えていただいたNOT EXISTSも調べたところまさにやりたいことでした。 何とかなりそうです。 ありがとうございました。 0700NAME IS NULL2018/02/16(金) 00:31:27.89ID:???>>695 環境、データ、インデックスとかによって違うからお前さんみたいに盲信してるのが一番ヤバイ 0701NAME IS NULL2018/02/16(金) 01:49:40.19ID:nepixz1J 経験上LEFT JOIN でIS NULLのほうが速い場合がほとんど 0702NAME IS NULL2018/02/16(金) 02:02:09.86ID:??? パフォーマンス気にするなら計測すればいい >>700の言うように状況によって結果は変わる https://sqlperformance.com/2012/12/t-sql-queries/left-anti-semi-join0703NAME IS NULL2018/02/16(金) 05:41:07.18ID:???>>692さんみたいな書き方を良くするんですが、これは遅いのですか? 0704NAME IS NULL2018/02/16(金) 05:43:00.22ID:??? あっ、ただ自分の場合は
「WHERE NOT 顧客ID IN (SELECT 顧客ID FROM 売上テーブル)」
ではなく
「WHERE 顧客ID NOT IN (SELECT 顧客ID FROM 売上テーブル)」
と書きます。 0705NAME IS NULL2018/02/16(金) 10:17:03.78ID:??? 売上げテーブルに顧客IDでインデックス貼ってあればそんなに遅くない気もする 0706NAME IS NULL2018/02/16(金) 10:51:09.70ID:??? 692は自分だけど、後でみなさん言われるとおり
SELECT * FROM 顧客テーブル WHERE NOT EXISTS (SELECT TOP 1 FROM 売上テーブル WHERE 顧客ID=顧客テーブル.顧客ID)
のほうが速そうだな 0707NAME IS NULL2018/02/16(金) 12:21:10.95ID:??? 速いとか遅いとか気にしたいんならDBが適切にメンテされているかを考えるべきやな SQLの表記のゆれなど考えるだけ無意味 0708NAME IS NULL2018/02/16(金) 15:52:24.98ID:??? NOT INの場合はパフォーマンス以前に 顧客IDがNOT NULLじゃないと意図した結果が得られない可能性がある
NOT NULLなら意図した結果が得られるけど、速度はDBの最適化に依存 INの最適化レベルが高いDBならNOT EXISTSと同程度の速度に場合もある でもそうならない場合もあるからこういうケースでは基本使わない 0709NAME IS NULL2018/02/16(金) 16:42:30.61ID:G4Vvw6Lg 【アマルガム】水銀を歯に? 厚労省『暴動が怖い』 http://mao.5ch.net/test/read.cgi/doctor/1517058870/l50 【ペットフード】告発したら3人組に棍棒で襲われた http://egg.5ch.net/test/read.cgi/hosp/1517110484/l50 【マンモグラフィー】おっぱい挟んで癌検査…必要? http://egg.5ch.net/test/read.cgi/bio/1517115639/l500710NAME IS NULL2018/02/16(金) 20:39:05.84ID:yNJxj2Lb>>700 環境、データ、インデックスとかによって違うからお前さんみたいに テストした環境でLEFT JOINが速いからLEFT JOINにしてしまう奴が一番ヤバイ 0711NAME IS NULL2018/02/16(金) 20:59:00.37ID:???>>710 うまい返ししたつもりなんだろうけどアホ晒してるだけやぞww 0712NAME IS NULL2018/02/16(金) 21:08:47.07ID:yNJxj2Lb>>711 普通に答えただけだけどうまかったか?w マジかwセンスあんな俺www 0713NAME IS NULL2018/02/16(金) 21:32:20.04ID:??? 誰か試してみてよ 0714NAME IS NULL2018/02/16(金) 21:53:09.91ID:??? 単純なnot inならouter joinと同じ実行計画吐いたきがする