23/02/11(土)10:12:45 SQLって... のスレッド詳細
削除依頼やバグ報告は メールフォーム にお願いします。個人情報、名誉毀損、侵害等については積極的に削除しますので、 メールフォーム より該当URLをご連絡いただけると助かります。
画像ファイル名:1676077965593.jpg 23/02/11(土)10:12:45 No.1025224436
SQLってなんでデータベースごとに記述方法や使える関数が全然違うの いじわる？
1 23/02/11(土)10:21:58 No.1025226625
そうだよ
2 23/02/11(土)10:24:18 No.1025227177
SQLは規格あるけど？
3 23/02/11(土)10:25:04 No.1025227390
全然違くはないよ 半端に共通してるよ
4 23/02/11(土)10:25:45 No.1025227539
「なんだこのクソ仕様は⁉︎ 俺の方がもっと優れたもの作れるぞ」とみんなが思った結果だよ
5 23/02/11(土)10:26:16 No.1025227665
同じうちの子なのになんでMySQLとMariaDBですらちがうの
6 23/02/11(土)10:28:40 No.1025228217
>「なんだこのクソ仕様は⁉︎ 俺の方がもっと優れたもの作れるぞ」とみんなが思った結果だよ BASICと同じ轍じゃん…
7 23/02/11(土)10:30:22 No.1025228638
永続性があって何でも入れて返してくれるオブジェクトデータベースがほしい
8 23/02/11(土)10:30:22 No.1025228641
ANSIもISOもメーカーのケツ追って後で標準化するよ
9 23/02/11(土)10:31:02 No.1025228786
>ANSIもISOもメーカーのケツ追って後で標準化するよ ダイヤちゃんみたいにあなた採用です！するよね
10 23/02/11(土)10:31:02 No.1025228788
SQLiteでええ！
11 23/02/11(土)10:31:46 No.1025228957
>SQLiteでええ！ 型なくてもいいけどもうちょっと日付扱いやすく
12 23/02/11(土)10:33:22 No.1025229317
BASICはほぼMSに統一されたからまだ救いはあるだろ SQLには救いはない
13 23/02/11(土)10:34:59 No.1025229676
それでもSQL覚える方がORM覚えるよりは楽かなって…
14 23/02/11(土)10:35:50 No.1025229883
>それでもSQL覚える方がORM覚えるよりは楽かなって… 使いやすいようにラッピングしたのにわかりにくいって言われるのかなしいよね！
15 23/02/11(土)10:36:50 No.1025230129
ORMのほうがバラバラだもんな
16 23/02/11(土)10:37:33 No.1025230306
nullの扱いくらい揃えろや！ 聞いてんのかOracle
17 23/02/11(土)10:37:39 No.1025230320
NoSQLってどうなの？おいしい？
18 23/02/11(土)10:38:54 No.1025230661
SQL直書きのがマシじゃないかは誰もが通る道
19 23/02/11(土)10:38:54 No.1025230664
>nullの扱いくらい揃えろや！ >聞いてんのかOracle 古いoracleでテーブルにas使えなくてハマった… 最近のは使える？
20 23/02/11(土)10:39:06 No.1025230718
ROWNUMが使えないやつはちょっと困った
21 23/02/11(土)10:40:09 No.1025230988
プロシージャとかいう悪の文明
22 23/02/11(土)10:41:13 No.1025231257
>NoSQLってどうなの？おいしい？ redisいい…セッション管理にべんり
23 23/02/11(土)10:41:54 No.1025231427
データベースは古い！KVSならなんでもできる！と言ってた人たちはどうなってるんだろうか
24 23/02/11(土)10:43:51 No.1025231886
>>それでもSQL覚える方がORM覚えるよりは楽かなって… >使いやすいようにラッピングしたのにわかりにくいって言われるのかなしいよね！ 結局どうしてもつい裏側のSQLを意識してしまう… ORMの方を先に知ってたら違ったのかな…
25 23/02/11(土)10:45:23 No.1025232279
インデックスの貼り方とか工夫しなくても内部で勝手に最適化して早くなってほしい
26 23/02/11(土)10:47:03 No.1025232646
>結局どうしてもつい裏側のSQLを意識してしまう… >ORMの方を先に知ってたら違ったのかな… こう書くとJOINしてくれるのかな？してないな…とかなる
27 23/02/11(土)10:47:20 No.1025232737
勝手にやられるとなんか怖い
28 23/02/11(土)10:48:21 No.1025232995
>同じうちの子なのになんでMySQLとMariaDBですらちがうの 養子だったりするから・・・
29 23/02/11(土)10:49:09 No.1025233180
巨大クエリ見るのは嫌になる
30 23/02/11(土)10:50:00 No.1025233408
>養子だったりするから・・・ むしろ実家を飛び出したマリアちゃんよ
31 23/02/11(土)10:50:43 No.1025233612
>>養子だったりするから・・・ >むしろ実家を飛び出したマリアちゃんよ 実家が札束で買われちゃったからな…
32 23/02/11(土)10:53:51 No.1025234424
プログラム言語に色々あるようなもんだと思ってるけど半端に共有してるせいで脳がバグる
33 23/02/11(土)10:54:47 No.1025234671
素直にクエリビルダ使えばいいものを2way SQLでメチャクチャ複雑な条件付き検索書いちゃったやつがあってちょっといじるたびに古文書の解読しなきゃいけない
34 23/02/11(土)10:55:51 No.1025234945
with使ってお願い…
35 23/02/11(土)10:56:28 No.1025235119
空文字≠NULLを標準にした方が悪い
36 23/02/11(土)10:56:29 No.1025235126
>with使わないでお願い…
37 23/02/11(土)10:57:02 No.1025235270
Linux版のMS SQLが互換性とか切り捨てて比較的クリーンでコンパクトになったせいでWindows版より早くなったのは笑えるんだけど笑えね…
38 23/02/11(土)10:57:34 No.1025235394
N+１問題を考えたくないから重そうな処理全てを長いSQLで解決しようとしてしまう
39 23/02/11(土)10:57:49 No.1025235460
可読性が死ぬのはわかっているんだけど生SQLに逃げたくなる
40 23/02/11(土)10:58:26 No.1025235621
PostgreSQLとAmazon Auroraも似て非なるものだよ
41 23/02/11(土)10:58:45 No.1025235713
SQLにさせる仕事とアプリで処理させる仕事はちゃんと分担しようね 設計から逃げるな可読性と保守性を考えろ
42 23/02/11(土)10:58:57 No.1025235763
>データベースは古い！KVSならなんでもできる！と言ってた人たちはどうなってるんだろうか そういう人を知らんけどなんでなんでもできると思ったんだろ
43 23/02/11(土)11:00:02 No.1025236063
○○なら何でもできる！全部解決する！って主張する奴は大抵無理 銀の弾丸などない
44 23/02/11(土)11:01:40 No.1025236484
3重サブクエリやめてくだち…
45 23/02/11(土)11:01:46 No.1025236505
>SQLにさせる仕事とアプリで処理させる仕事はちゃんと分担しようね 了解！EAV!
46 23/02/11(土)11:02:02 No.1025236569
>>SQLにさせる仕事とアプリで処理させる仕事はちゃんと分担しようね >了解！EAV! ころすぞ
47 23/02/11(土)11:02:33 No.1025236705
>>SQLにさせる仕事とアプリで処理させる仕事はちゃんと分担しようね >了解！EVA!
48 23/02/11(土)11:03:02 No.1025236824
JOINで結合したテーブルから絞るのとサブクエリで絞ったテーブルをJOINするのどっちがいいんだろうか
49 23/02/11(土)11:03:43 No.1025237023
>JOINで結合したテーブルから絞るのとサブクエリで絞ったテーブルをJOINするのどっちがいいんだろうか サブクエリをexistsする
50 23/02/11(土)11:04:09 No.1025237134
>SQLにさせる仕事とアプリで処理させる仕事はちゃんと分担しようね 了解！PL/SQL！
51 23/02/11(土)11:05:24 No.1025237467
>○○なら何でもできる！全部解決する！って主張する奴は大抵無理 >銀の弾丸などない うちは上がクリーンアーキテクチャにハマってね…
52 23/02/11(土)11:05:31 No.1025237506
日付ぐらい統一できない？
53 23/02/11(土)11:05:38 No.1025237532
JPQLくんにはお世話になりっぱなしだよ
54 23/02/11(土)11:06:39 No.1025237796
論理削除でお願いします
55 23/02/11(土)11:06:56 No.1025237853
Oracleの複数インサートはいつになったらまともになるの
56 23/02/11(土)11:07:28 No.1025238016
けれどヘルプで入った案件で高速化の為にSQLゴリゴリに書くの好き 単純に書くの楽しいしこうなったの俺のせいじゃないって担保があるから
57 23/02/11(土)11:07:44 No.1025238079
>論理削除でお願いします ぶっさくしろ！
58 23/02/11(土)11:11:54 No.1025239196
Oracleに親を殺されたエンジニアは多い
59 23/02/11(土)11:13:05 No.1025239524
>日付ぐらい統一できない？ ISOで定義はされてるよ 誰も守らないけど
60 23/02/11(土)11:13:07 No.1025239529
なんでNULL比較したらレコード取ってきてくれないんだORACLE… NVLがそんなに好きか
61 23/02/11(土)11:13:49 No.1025239713
外部キーとかトリガーとか代理キーの一意制約を使わないのは深刻な理由があると長らく思ってた たんに使い方知らないだけなのでは？と最近うっすら感じるようになってきた
62 23/02/11(土)11:16:22 No.1025240355
汎用機の頃のリレーショナルじゃないDBのリプレース案件だからな
63 23/02/11(土)11:16:22 No.1025240359
SQLは車のチューニングに似ている
64 23/02/11(土)11:16:54 No.1025240490
12cから19cに移行した途端ファンクションインデックスが使い物にならなくなった！
65 23/02/11(土)11:17:00 No.1025240518
Druid使うことになったんだけどこいつもSQL使えるのか・・・
66 23/02/11(土)11:17:21 No.1025240633
ORMばっか使ってるとSQLの書き方忘れる… Union…with…どこで使うんだっけこれ…
67 23/02/11(土)11:18:41 No.1025240981
>SQLは車のチューニングに似ている すぐ衝突事故おこすからね
68 23/02/11(土)11:18:48 No.1025241002
業務でHiRDBって奴に変わったけどこいつめんどくせ…
69 23/02/11(土)11:18:51 No.1025241018
SQLってなんでマニュアルに書いてない文法でも実行できるの
70 23/02/11(土)11:21:26 No.1025241706
>SQLってなんでマニュアルに書いてない文法でも実行できるの マニュアル読んだことない
71 23/02/11(土)11:21:52 No.1025241815
完全に理解した
72 23/02/11(土)11:22:30 No.1025241972
ORMの吐き出す下劣なSQLを解読するのはもう嫌だ ORMは人には早すぎたんだ
73 23/02/11(土)11:22:51 No.1025242073
いいかこのSQLで取れるのは1万までだ！ 10万で1時間かかったって言われても…
74 23/02/11(土)11:23:21 No.1025242200
>業務でHiRDBって奴に変わったけどこいつめんどくせ… XDM経由で使ったことあったけどこいつSQLみたいな面倒臭い式書けた覚えが無いな 今のバージョンだと良い感じなんだろうか
75 23/02/11(土)11:23:26 No.1025242219
chatGPTに聞いたほうがいいアウトプットになりそう
76 23/02/11(土)11:25:15 No.1025242702
電話完了 だがGoogleには興味ないのでネタバレ 1.初歩的に重複しない文字列を抜き出す 2.おもむろにMySQLを立ち上げる 解のヒント ↓ ①UNHEX関数を使ったAES暗号複合 ②WGS84座標系、ユニバーサルメルカトル図法 ここまできたらサルでも時間をかければ複合化できます。
77 23/02/11(土)11:26:14 No.1025242947
>いいかこのSQLで取れるのは1万までだ！ >10万で1時間かかったって言われても… 何のデータ扱えば10万も必要になるんだよ
78 23/02/11(土)11:26:43 No.1025243087
懐かしいなユニバーサルメルカルト速報…
79 23/02/11(土)11:26:51 No.1025243130
びっぐでーた？ってやつなんでしょ！えーあいが流行ってるんだから早くやりなさいよ！
80 23/02/11(土)11:27:37 No.1025243305
>何のデータ扱えば10万も必要になるんだよ ネトゲのユーザーデータとか……
81 23/02/11(土)11:35:04 No.1025245217
>テーブルにas Oracleだったかどうかは忘れたが from FooTable as F みたいなのは駄目で from FooTable F なら通るものがあるよな つうかむしろasは無いほうが普通だったように思う
82 23/02/11(土)11:35:05 No.1025245223
外部キー制約不要論とかもあって難しい
83 23/02/11(土)11:36:57 No.1025245735
oracleのasは表だけダメで列は良し
84 23/02/11(土)11:37:57 No.1025245980
移行案件とかだと1000万や１億単位もあるのが恐ろしい updateとかが命がけ
85 23/02/11(土)11:38:49 No.1025246207
1億はさすがに無理あるよ！要件見直してくだち！！
86 23/02/11(土)11:41:35 No.1025246934
一億は設計が明らかに悪いので分割して…
87 23/02/11(土)11:43:06 No.1025247356
>1億はさすがに無理あるよ！要件見直してくだち！！ マイナンバーとか人口分のレコードあるんだよね？ どんな管理してるんだろう
88 23/02/11(土)11:43:43 No.1025247493
>>1億はさすがに無理あるよ！要件見直してくだち！！ >マイナンバーとか人口分のレコードあるんだよね？ >どんな管理してるんだろう 請求データが１億越えレコードとかはあった
89 23/02/11(土)11:43:51 No.1025247527
実はインデックスが何かよくわかってない とりあえず張っとくかあ！
90 23/02/11(土)11:45:01 No.1025247830
インデックスというとだいたい木の方で ビットマップインデックスの影が薄い
91 23/02/11(土)11:45:59 No.1025248111
勉強し始めたばっかりだけど掲示板とかチャットのデータベースとして作るだけならそんな複雑なこといらないよね？
92 23/02/11(土)11:46:53 No.1025248312
その昔 バベルの塔という
93 23/02/11(土)11:47:54 No.1025248572
なんでデータベースなのに集計とかできるようになってるの
94 23/02/11(土)11:49:14 No.1025248916
>なんでデータベースなのに集計とかできるようになってるの 集計したのをもとにデータ引っ張るならDBの中でできたほうがお得！
95 23/02/11(土)11:52:47 No.1025249830
>勉強し始めたばっかりだけど掲示板とかチャットのデータベースとして作るだけならそんな複雑なこといらないよね？ 何を以って複雑とみるかによるが正規化を進めれば小さい単純なテーブルが沢山作られることになる
96 23/02/11(土)11:53:55 No.1025250147
構造が同じテーブルがたくさんあったので区分キーをついかして全部まとめちゃいましたよ！
97 23/02/11(土)11:55:14 No.1025250483
MySQLとMariaDBはほぼ同じだから気にしなくていいと聞いた
98 23/02/11(土)11:56:15 No.1025250754
>MySQLとMariaDBはほぼ同じだから気にしなくていいと聞いた そう言ってるとそのほぼに入らないところで苦しんだりする
99 23/02/11(土)11:58:38 No.1025251389
>MySQLとMariaDBはほぼ同じだから気にしなくていいと聞いた フォークしたから元はそうだったけど最近は mariadでOFFSET句使えたりoracleライクな関数増えたよ
100 23/02/11(土)11:58:55 No.1025251465
ほぼ同じだったのなんて10年前までだよ！
101 23/02/11(土)12:00:37 No.1025251927
なんか全部賛否両論だな
102 23/02/11(土)12:00:55 No.1025251992
業務でpostgresqlでselectでデータ取ってくるしかしないんだけどテーブルいっぱい参照する場合with句使うよりtemporary table作ってそこから持ってった方が自分のマシンのメモリパフォーマンス的にはええのん？
103 23/02/11(土)12:01:45 No.1025252230
全部ChatGPTに聞けば ええ！
104 23/02/11(土)12:03:04 No.1025252629
可読性の為にWITH句を使うがパフォーマンス向上に期待して使わないな