SQLはよくわからにゃいからシンプルなクエリで済まして親プログラム側でなんとかする

;

SQLは根本の設計が古すぎるからさっさち高級言語だけでDB構築できるようになればいいなって

普通に複数行テキストを複数行に書けるってことだから便利…なのか？

連結とかいらん事しないで

NoSQL！もうこれでええ！

postgresは妙な動きが多いのでmysqlに移行した

>postgresは妙な動きが多いのでmysqlに移行した
MySQL/MariaDBはOracleの次くらいに変な方言多いけど？(ストアドを除く)

そういえばC/C++にもそんな仕様あったな

SQLはベンダーによって自由に解釈し自由に拡張しても良い

>postgresは妙な動きが多いのでmysqlに移行した
俺はmariaDBにした

MySQLはライセンス問題が今後ちょっと怖いね

最近はＡＩくんに丸投げしてる

隣り合う文字列リテラルが勝手に連結されるのはCもなので
何か70年代はそういう流行りがあったのかもしれない

>最近はＡＩくんに丸投げしてる
データ項目が何十項目もあるテーブルに対してのSQLシコシコ書くの苦行だったからほんとありがたい…

Snowflake好き

"foo" "bar" が "foobar" になるのは割と色んな言語であるのではって思ったら
改行を含むとそうなるけど改行を含まないとそうならないって話だった
まあちょっと奇妙ではある
あと行末のコンマ書き忘れたりしてもエラーにならないから普通にバグの元になるなこれ

mysqlやoracleが好きって人は方言が好きなだけと思う
まあ便利な方言あるっちゃあるが

MySQLは使いにくい筆頭じゃないか

たまにマニュアルにない書き方があるのなんなの
そしてなんで一部の人はその書き方を知ってるの

それCやC++でも同じらしいよ

サイバーセキュリティでSQLインジェクションという攻撃手法あるの知ってウヘェとなった

>たまにマニュアルにない書き方があるのなんなの
>そしてなんで一部の人はその書き方を知ってるの
昔は処理系ごとに動作が違うなんてのは普通だったし
マニュアル通りに動くことの方が珍しかったから
丸暗記するしかなかった

その言語のBNFを眺めると予想と違う順番だったりでも正しく動作するのがわかる

>SQLはよくわからにゃいからシンプルなクエリで済まして親プログラム側でなんとかする
データベース管理者から怒られるやつ

触りたくない

>サイバーセキュリティでSQLインジェクションという攻撃手法あるの知ってウヘェとなった
外部から触れるとこにDBあるのが論外というのは置いといて
SQLサーバー自体はセキュリティもクソも無い代物だからハード面で対策するしかないのかなり前時代的だと思ってる
言語レベルで一定のセキュリティぐらい持ってろ

文字列リテラルが連結するのはALGOLあたりからだった気がする
その子孫は同じような仕様を採用してたりする

外部キーの忌避が嫌だけど
ほんとのほんとの大規模は外部キーがほんとにコストになるっぽくて悩ましい

OSS界隈は詳しいことはソース読めみたいなことがまかり通ってきたし
AIはまさにそれができてしまうから…

>>サイバーセキュリティでSQLインジェクションという攻撃手法あるの知ってウヘェとなった
>外部から触れるとこにDBあるのが論外というのは置いといて
>SQLサーバー自体はセキュリティもクソも無い代物だからハード面で対策するしかないのかなり前時代的だと思ってる
>言語レベルで一定のセキュリティぐらい持ってろ
ユーザ(ロール)単位のセキュリティはちゃんとあるでしょ
このユーザはテーブルAは読み書きできるけどテーブルBは書き込みできないとか
文法を見れば分かるけどSQLはユーザが直接クエリを書くことが前提になっていて
プログラムでSQL文を組み立てるから全てのクエリが同じロールから発行されるという現状の方が異常なんだよ

>SQLサーバー自体はセキュリティもクソも無い代物だからハード面で対策するしかないのかなり前時代的だと思ってる
権限制御があるんだからまずWEBアプリに参照権限だけのアカウント使わせるだけで致命的な不正アクセスは防げるよ

弊社は外部キー制約なんてもの一つも付けてないな

json禁止

外部キー制約つけてる現場見た事ない

外部キーなんて意味無いからな…

サブクエリ禁止

外部キーは忘れた頃にテストデータ作るときに引っかかったりしてビビる

>文法を見れば分かるけどSQLはユーザが直接クエリを書くことが前提になっていて
>プログラムでSQL文を組み立てるから全てのクエリが同じロールから発行されるという現状の方が異常なんだよ
じゃあその正しい使い方してるとこがどんだけあるかって考えたら
現実的な人員配置では異常な運用しかできないっていう構造の欠陥なんだよなもう
なんでこんなのみんな使ってんだ

>サブクエリ禁止
参照先のサブクエリが更に別のサブクエリを参照していることなんて何度経験したか知れないよ

>じゃあその正しい使い方してるとこがどんだけあるかって考えたら
>現実的な人員配置では異常な運用しかできないっていう構造の欠陥なんだよなもう
>なんでこんなのみんな使ってんだ
こんなものが普及してしまったから…

ログ検索エンジンとかだとたまに搭載されてるパイプで処理できるSQLっぽいのがあってほしい

サロゲートキーつけてるとこは外部キー制約つけてる気がする

>じゃあその正しい使い方してるとこがどんだけあるかって考えたら

COBOLとSQLは当時の感覚では「こんだけ英語に近いんだから素人でもスラスラ書けるだろ」っていう設計だったんだ

>なんでこんなのみんな使ってんだ

SQL書いたことほぼないから全然わからん
テストしたいだけだからエラー吐くのやめろ

NULL禁止

>SQL書いたことほぼないから全然わからん
>テストしたいだけだからエラー吐くのやめろ
つべこべ言うな勉強しろ
それかAIに丸投げしろ

早く滅びないかなRDBMS

>>SQLはよくわからにゃいからシンプルなクエリで済まして親プログラム側でなんとかする
>データベース管理者から怒られるやつ
横からだけど最低限のデータ取得してるならナンも言われないよ　データ丸々持ってきてるなら色んなところから人が殴りに来るけど

ソフトウェアのくせにプログラミングの文化に全く沿ってないのが気色悪過ぎる

>>>SQLはよくわからにゃいからシンプルなクエリで済まして親プログラム側でなんとかする
>>データベース管理者から怒られるやつ
>横からだけど最低限のデータ取得してるならナンも言われないよ　データ丸々持ってきてるなら色んなところから人が殴りに来るけど
いちいちSQLのしきたりに則ってデータ取り出すなんて非効率だよなあ！？

>早く滅びないかなRDBMS
ぜったいに滅びないよ
「もう終わりだ猫のDB」って言われだしてからもう40年近くサバイブしてきてるのは伊達じゃないぞ

うんこ

ちんこ

まんこ

SQLはAIに聞いたら大体解決するから助かる

もうAI無いと無理だ

SQLはプログラミング言語として終わってる

>ソフトウェアのくせにプログラミングの文化に全く沿ってないのが気色悪過ぎる
手続き型しか知らないだけだろ
Prologとか見たら泡吹きそうだな

データの集まりにSQLじゃなくてプログラミングで処理しろって方が面倒くさくね？

>早く滅びないかなRDBMS
お前が滅ぼしてくれ
RDBMSより良い仕組みを考えて発表するだけでいいぞ

整合性を保ちながらデータを管理する仕組みがRDBしかないから仕方ないじゃん
嫌なら新しい仕組みを作れ

>早く滅びないかなCOBOL

整合性なんかいらんよ

>>>>SQLはよくわからにゃいからシンプルなクエリで済まして親プログラム側でなんとかする
>>>データベース管理者から怒られるやつ
>>横からだけど最低限のデータ取得してるならナンも言われないよ　データ丸々持ってきてるなら色んなところから人が殴りに来るけど
>いちいちSQLのしきたりに則ってデータ取り出すなんて非効率だよなあ！？
これはあるし複雑になればなるほどインデックスが効かなくなる問題もある
そもそもSQLはデータベース側に負担がかかるんだから負荷分散考えるならアプリケーションサーバ側で処理させるべきなんだよね
それができたら苦労はしないんだが

MySQLはシェア高い割に変な方言や謎の独自実装が妙に多いんだよな

>外部キー制約つけてる現場見た事ない
俺つけてたけどやめる時に全部外された
難しすぎてデッドロック誘発装置だったし別にいいのかもね…

AIでも何でもいいから最強のデータベース管理システムを誰か作ってくれよ

>データの集まりにSQLじゃなくてプログラミングで処理しろって方が面倒くさくね？
NoSQLだの作ってもみんなSQLでアクセスしやがる

>MySQLはシェア高い割に変な方言や謎の独自実装が妙に多いんだよな
ポスグレはOracleに似せて作ってるからにてるだけでMySQLは独自路線で行ってたような
なぜかOracleはMySQLの方を食ったんだけど

RDBに文句を言ってる人達はCOBOL時代の固定長ファイルでのデータ管理でも提案すれば良いのでは？

外部キー制約は悪

今だにCOBOLで動いてる銀行お過ぎ問題

>ポスグレはOracleに似せて作ってるからにてる
どこがだよ
Oracle触ったことないだろ

やあ

>今だにCOBOLで動いてる銀行お過ぎ問題
わざわざJavaにしたのに保守企業に移管した途端ぶっ壊してCobolに戻したバカどももいるぞ

SQL99くらいまでの機能は使ってるけどその後25年分くらいのはあまり使ってない
https://atmarkit.itmedia.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html

COBOLは変数のスコープを狭くできればもっと分かりやすくなると思う

まぁポスグレはポスグレで独自の独自関数とか演算子かなり入ってるんだけどね

わからない…俺は雰囲気でSQLを触っている…

結局はどのDBがいいんだい？

もうすぐNoSQLがSQLに取って代わる

>やあ
お前が悪いとは思わないがお前が動いてる環境は大抵悪い

DB2はRDBMSの仕様に割と忠実に作られている気がする
でも実務では使いづらいんだよね…

>>やあ
>お前が悪いとは思わないがお前が動いてる環境は大抵悪い
じゃあ俺にする？

DB(ドラゴンボール)

IMGQLの開発を急ごう

>DB(ドラゴンボール)
ハチャメチャが押し寄せてくる

ポスグレは本体は特にいうことないけど¥で始まる2〜3文字ショートカットコマンドが使いやすすぎる

>DB2はRDBMSの仕様に割と忠実に作られている気がする
>でも実務では使いづらいんだよね…
上流や設計をきちんとしてたら最強DBMSまである
問題はそんな現場はまずないこと

dual表が死んだとか死んでないとか聞いた
oracleしね

>oracleしね
そうだね

>MySQLはシェア高い割に変な方言や謎の独自実装が妙に多いんだよな
「小さく生んで大きく育てる」の典型というか当初は大きくするつもりもなかったから
トランザクションすらなかったんだぞ
PostgreSQLは逆に「とにかく標準をサポートするけど実装は後から」ってポリシーだから
昔は「それ文法上はエラーにはならないけど書いても効果ないよ」ってのばっかだった

>dual表が死んだとか死んでないとか聞いた
>oracleしね
sqlは仕様通りに変な挙動するけどoracleは根本的に解決出来ない糞仕様がある

僕はエンジニア6年生
複雑なSQLが書けない
読めはするが

>僕はエンジニア6年生
>複雑なSQLが書けない
>読めはするが
書かずに済むならそれが一番

嘘か真か「全カラムNULL許容しませぇん！！」みたいな現場は昔はあったみたいだけど今はもうないのかな

千行とかあるSQLなんて俺だって弄りたくねえんだけど仕事なんだよ…

SQLとか正規表現はAIの補助ないときっついからだになってしまった

ちゃんとTABLEが正規化されてればSQLはそんな複雑にならない
問題はそんなDBは滅多にないということ…

よくもまぁこんな複雑なもの書いたな…って先人に感心したりはする

>嘘か真か「全カラムNULL許容しませぇん！！」みたいな現場は昔はあったみたいだけど今はもうないのかな
マスタテーブルでもないとそんなテーブル作る意味ある？

>じゃあ俺にする？
しね
ていうか日立は重電だけ作ってろマジで

postgresがOracleに似てるとは感じないけどOracleが実装してるからpostgresにも実装しようってモチベーションで機能開発されてるのは感じる

>>>やあ
>>お前が悪いとは思わないがお前が動いてる環境は大抵悪い
>じゃあ俺にする？
>お前が悪い

今でもOracle使ってるとこあんの？

正規化したらNULLは必要ない

SQLを滅ぼしても灰からCoddが蘇る

>今でもOracle使ってるとこあんの？
無限にあるぞ
DB2もあるところにはあるしHiRDBもまだある

>今でもOracle使ってるとこあんの？
弊社

ボタン1個でポンと正規化してくれりゃあな
データ取り出してからやるか…

全部Accessとsqlで解決するのは良いけどなんでそれの担当者が引き継ぎしてないんすかね　ずほさん

方言が違う程度でRDBなんてどこも一緒よって感じてる

Oracleなんかレイオフばっかしてるイメージ

そういえばみずほってどうなったんだろう

俺はもう集計はこれじゃないと困る

正規化しすぎてもパフォーマンス落ちたりするからな

where s.omnk=null
ヨシ

というかDBMSのシェアがmicrosoft・AWS・oracleの三強の時点で世の中の大半はそいつらだろ

俺が担当しているプロジェクトはOracleからSQLServerに移りSQLServerからMySQLに移りそこからさらに実績データ系はMongoDBに移管された
毎回毎回意向が大変だったけどまぁこれ以上は変わらんだろう

集計なんてexcelのパワークエリでええ！

>正規化しすぎてもパフォーマンス落ちたりするからな
これ本当にひどい…なんでRDBの理念に沿うと不利になるんだ

>これ本当にひどい…なんでRDBの理念に沿うと不利になるんだ
io速度は理想通りに動かないからだったか？

>じゃあ俺にする？
おおむねPostgreSQL互換て触れ込みだけど７割くらいしか実装してないよな
昔SHｰ3向けの組み込み開発してたんだけど
CコンパイラがCの文法の8割くらいしかサポートしてなくて
あまりに酷いので電話したら
「そんな文法は実装してません仕様です」
「でも御社はANSI-C準拠って明記してますよね？」
「はい」
「じゃあなんでこれがコンパイルエラーになるんですか？」
「仕様です」
危うく本当に「死ね」って言うところだった

そういや最近Join禁止が話題になってたわ

クックック…

SQLServerってどうなの

>Join禁止
どういうこと…？

Oracleってまだ""がNULLになるの？

>CコンパイラがCの文法の8割くらいしかサポートしてなくて
サポートしてないならいいじゃん
黙っておかしなコンパイルするより

Joint？

>Oracleってまだ""がNULLになるの？
なんすか何か悪いんすか

>>CコンパイラがCの文法の8割くらいしかサポートしてなくて
>サポートしてないならいいじゃん
>黙っておかしなコンパイルするより
でもマニュアルの１ページ目に堂々とANSI-Cフルサポートって書いてあるんだぜ？
裁判になったら100%勝てるレベル

>どういうこと…？
Join自体は死ぬほどパフォーマンスが悪い
のだが大抵の場合DBの最適化とかで問題ない範囲だし
した結果のデメリットが大きすぎるのでJoin禁止する方が大抵ダメ

"" ←無職の職歴
NULL ←「」の職歴

>SQLServerってどうなの
昔は列ストアインデックス使いたいなら候補に挙がってたけど最近だとAzureとかPower BI使ってるならって感じじゃないか
あとはオフィシャルの商用サポートが存在することとかが企業によっては重視されたりするし

SQLiteもいいものだよ

>SQLiteもいいものだよ
Ruby on RailsがVer8で「本番でもデフォルトではSQLite3」に回帰したのは衝撃だったけど
説明をよくよく読んだら納得しかなかった

5年ぐらい経つけど何わかればスレ画いけるっすって言えるのか全然わからん
完全に雰囲気だけで仕事してる

>>Join禁止
>どういうこと…？
RDBをKVSっぽく使おう的な話らしい
たぶん

>"" ←無職の職歴
>NULL ←「」の職歴
触れたら面接官もNULLになるのか

>Join禁止
もちろん今でも大量の実績データにマスタ情報くっつけてBIツール噛ませるとかオンラインゲームみたいに超高頻度にCRUD操作が行われるようなテーブルだと今でもJoinはしないのがベストプラクティスになるけど大多数は禁止する弊害の方が多いよね

Access覚えて勤怠用データベース作って！って言われてテキストとネット元に半年かけてSQLもちょっとだけ覚えたけどもうだいぶ忘れたな…

そんなピーキーなシステムじゃないならSQLServerでいいじゃんとは思う
適当にやってても適当に処理してくれるし

なんでこんなものが廃れずver2もつくられずメジャー独占してるのかが分からん

ちょい前のmysqlってsql99全然対応してなくて話にならなかった思い出がある

JOINする場合プログラム側でやるよりSQL書いたほうか早いし楽じゃない？

>>Join禁止
>どういうこと…？
JOINのコストやロックの問題とかじゃないかな
特にアクセスが激しいサービスだとDB側からオフロードした方がいい場合もある
特定のケースでは有効くらいの認識でいいかと

逆にOracleとかSQLServerとかの商用DBを触らなくなったなぁ…
MySQLかMariaかPostgressかMongoかRedisかElasticSeachかって感じになってる

下手な言語学ぶよりSQLできたらずっと飯食えるんじゃね？

>JOINする場合プログラム側でやるよりSQL書いたほうか早いし楽じゃない？
楽だし確実だよ
プログラム結合でもできるけどバグの温床になりやすいし

>下手な言語学ぶよりSQLできたらずっと飯食えるんじゃね？
最近はSQLをカリカリにチューンするような場面も減ったしなぁ…

>下手な言語学ぶよりSQLできたらずっと飯食えるんじゃね？
SQLとR言語と統計検定受けておくと食いっぱぐれないぞ

>なんでこんなものが廃れずver2もつくられずメジャー独占してるのかが分からん
自称ライバルが軒並み自滅してるだけだから…

sqlに限らず単純に結合処理させるのくそ重い

>sqlに限らず単純に結合処理させるのくそ重い
だからjoinは悪なんですね

AND 1=1;SELECT * FROM user;

>下手な言語学ぶよりSQLできたらずっと飯食えるんじゃね？
DBMSじゃなくてSQLってことならもうすぐAIに仕事取られるよ

沢山痛い目を見てきたから外部キーと制約はちゃんと貼れってずっと言い続けてる
嫌がる人も多いけど特に外部キー

>AND 1=1;SELECT * FROM user;
お馬鹿！

生成AIに最強のDB作ってもらおうぜ

SQL書くのつまんね…だからAIにほとんど書いてもらって助かってる

結局「確かにこの部分はNoSQLに置き換えたほうが早いんだけどRDBひとつでも十分だよね」って判断になりがちなのよね

>生成AIに最強のDB作ってもらおうぜ
最強のDBが出来たとして移行は誰がやるんで？

外部キー入ってるとデータメンテが面倒くさいんだ……特に順番入れ替え

一時期もてはやされてたMariaDBは今どうしてるんだろう
みんなMySQLに戻ったのかな

最近はORMapper使って抽象化されてるから生のSQLを書く機会すら減った

>結局「確かにこの部分はNoSQLに置き換えたほうが早いんだけどRDBひとつでも十分だよね」って判断になりがちなのよね
巨大システムでも無いと普通のDBMSで十分かなって…

>>下手な言語学ぶよりSQLできたらずっと飯食えるんじゃね？
>DBMSじゃなくてSQLってことならもうすぐAIに仕事取られるよ
いやDBAも要らなくね？
自然言語で質問したら答え返ってくるんだから

SQL文を書くだけならAIがやってくれるから
これからの人間がやる事はその精査

そんなベストプラクティス全部踏襲しないといけないような要求厳しいプログラムに携わりたくない！

>一時期もてはやされてたMariaDBは今どうしてるんだろう
>みんなMySQLに戻ったのかな
うちの会社の担当システムは基本MariaDBにシフトしてる
まぁ困ってはいない

対策してない方が稀なのはそうだけど万一成立するとだいぶまずいから人のシステムにSQLインジェクションを投げるのはやめとこうな！

ETLツールに頼ろう

何らかのフレームワーク使ってればほぼ無効化されるよねSQLインジェクション
たまに自作フレームワーク使ってたりSQL直呼びしてると引っかかるけど

>外部キー入ってるとデータメンテが面倒くさいんだ……特に順番入れ替え
非定期のデータメンテの為にデータの完全性を落としたり存在チェックのコードを書くようにしてたら本末転倒だよぅ！

インストールベースで考えたら世界さいつよDBはSQLIte3なんだよね

>インストールベースで考えたら世界さいつよDBはSQLIte3なんだよね
航空機に搭載できる基準を満たしているRDBMSは世界でSQLite3だけだよ

>SQL文を書くだけならAIがやってくれるから
>これからの人間がやる事はその精査
AI用に項目名変換するの面倒なりね

SQLiteの何がすばらしいってSQLite本体のコードよりテストコードの規模の方がはるかにデカい
全てのプロジェクトがそうあれ
うｎ無理

>>外部キー入ってるとデータメンテが面倒くさいんだ……特に順番入れ替え
>非定期のデータメンテの為にデータの完全性を落としたり存在チェックのコードを書くようにしてたら本末転倒だよぅ！
と言うかデータのソートをシーケンスのPkeyではやらずにソート項目は別で用意しておくのがいいね…

>SQLiteの何がすばらしいってSQLite本体のコードよりテストコードの規模の方がはるかにデカい
>全てのプロジェクトがそうあれ
>うｎ無理
SQLite3本体は15万行
テストは1億行だそうな