もはやあってあたりまえの存在なので感情が湧かない

pythonでいい感じにシュガーしてくれるので一番流行りって今なんなの

Aurora触ってみたいけど機会が無い

これがいいとはとても思わないがこいつの変わりが出てこなかったのがすべて

>こいつ好き
>テーブル設計嫌い

これより良いデータ構造でてきても人間に扱える気がしない

Migrationって本当に開発を楽にしてるのかな…
面倒くさくなっただけのような…

FROMから書かせて欲しい

ウインドウ関数使えないDBあるのが絶許

SQLはオワコン！
これからはNoSQLの時代がくるんですけお！！！１１１！！

代わりとか出てくる気がしない

ｺｯﾁﾆｺｲ…

検索が遅いという弱点さえなければ結局RDBが一番いいんじゃよ…

ダイナモDBってのはこいつとは違うの？

じゃあbashのパイプ使ってユニゲージ開発するか？

こいつに詳しくなるにはどうしたらいいの？

UIの操作やM言語を良い感じにSQLにしてくれるパワークエリが有難い…

俺スレ画のこと半分も理解できてないダメダメITエンジニア…

方言きらい…！

DynamoDBはどちらかというとKey-Value型じゃなかったっけ

パフォチューの能力を身につけても給料に一切反映されないと考えるともっともクソな分野かもしれない

ちゃんと組めたぞ！ひでー結果になった！

>SQLはオワコン！
>これからはNoSQLの時代がくるんですけお！！！１１１！！
実際NoSQLでもスケールさせようと思わなければよく動くし実装も簡単だよね

>こいつ嫌い
>テーブル設計嫌い

時系列型とかDWHとかよくわからん

フレームワークのORマッピングに落とし込んだ奴の方が100倍理解しづらい気がする
SQLをモデルのメソッドで全て表現しようとか狂気の沙汰では…？

クエリは書けるけどスキーマがどうとかそっちの話はさっぱりわからん…

自分で組むのはいいけど他人が組んだこれを読むのは死ぬほど嫌い
コメントアウト付いてればちょっと許す

PL/SQL!!!!1!!!!!111!!!!

構造化データはDBで非構造化データはファイルシステム

実際SQL覚えた上でORMの使い方の学習必要になるからねぇ

最近dynamoDBとかmongoDBばかりでRDB忘れそう

>こいつ好き

>クエリは書けるけどスキーマがどうとかそっちの話はさっぱりわからん…
DB「まずDB　次にスキーマ　そしてテーブルを作ります」
俺「スキーマって何者？」
DB「ロールを作りユーザーを作ります」
俺「ロールって何者？」

先にインスタンスな

神ユーザー1つを全ての開発者で使い回す

>フレームワークのORマッピングに落とし込んだ奴の方が100倍理解しづらい気がする
>SQLをモデルのメソッドで全て表現しようとか狂気の沙汰では…？
やっぱり性能求めるとSQLゴニョゴニョしがちだからアクセサーが使いやすければORMじゃなくても…って思う

今だったらGPTに聞けば全部書いてくれるから何も難しくないぞ
マジで日本語出来ればそれだけでいい

昭和100年問題！

sqlどうこうというかRDBに対する理解がないと何も始まらないしnosql採用するかの判断もできない
場当たり的にやるのはまあそりゃできるけど

こいつのこと100%分かってない連中が大抵こいつを使ってるらしいな

JOINに次ぐJOINの連続

3大これどういう意味なんだよIT用語
スキーマ
デプロイ
レプリケーション

100%わかってるヒトなんているの...？国家資格持ちとか？

関連テーブルにも制約があってぇ…とかなるとおつらい

Access使うことになって本当にクソすぎて画像を好きになった

正規化とか忘れちゃった…
テーブル分けまくると使いにくいし性能もでないからみんな経験でやってる

主キーに対してすべての非キー属性が完全関数従属が第二正規形で
すべての非キー属性がどの候補キーに対しても推移的に関数従属していないのが第三正規形だぞ
は？

何入れるかわからないからjson型にするね

mysqlくんは気軽にテーブルロックかけるよね

正規化なんて適当にどうにかなれーでやってる
パフォーマンスは出ない

同僚にこのテーブルインデックス張った方がいい？って聞かれるけどまず俺には
どこで張るべき張らないべきの線引きをするかが分かんね！

>UNIONに次ぐUNIONの連続

これだけで仕事が成り立つからな

インデックスは張れば張るほど
ええ！

JOINいる？(+)でよくない？

JOINはいい
LEFT JOIN
RIGHT JOIN
あなた方はどちら様で…？

正規化はな第6以降もあるんだよ！

世の中にはエクセルをDB代わりに使うところもあると聞いた
システムと同期とれてて手動でも自由にエクセルから書き換えできないとダメなんだって

嫌いだったけど複数人にズボケオされまくったkintoneに関わってからはスレ画の方が遥かにましという結論になりました…

操作履歴を含めるとほとんど最後まで正規化なんてできないんじゃって思う

先代社長がオラクルは消えると宣言してはや15年…

Oracleは死なんよ何度でも値上げする

20年以上前に中途半端に覚えたSQL知識で
今も戦っていますよ私は

OracleはSIerの素人が設計してもまともな性能出るからな…
おそらくこれからも消えることはない

俺はこいつの事3割程度しか理解してない雑魚だよ

OSSでSQL勉強してから企業でOracle使ったら妙ちくりんな仕様でビックリしたな…
””とかまだNULLなんだろうか

Oracleマジで取っつきにくい

sqliteぐらいが好き

苦手だったけどAIがだいたいやってくれるようになった

>Oracleは死なんよ何度でも値上げする
まじふざけんなよ…

まともなメーカー保証があるという時点でOracle一強だったから…

>同僚にこのテーブルインデックス張った方がいい？って聞かれるけどまず俺には
>どこで張るべき張らないべきの線引きをするかが分かんね！
パフォーマンスに問題がないなら必要ないぜ！

>Oracle Databaseは現在、長さが0(ゼロ)の文字値をNULLとして処理します。ただし、この処理はOracleの今後のバージョンでも継続されるとはかぎらないため、空の文字列をNULLとして処理しないことをお薦めします。

ん゛ん゛ん゛ん゛ん゛！！！１！１！！！！！！！

あくらつな
ベンダーしかく

>OSSでSQL勉強してから企業でOracle使ったら妙ちくりんな仕様でビックリしたな…
>””とかまだNULLなんだろうか
条件にこいつらが絡んだせいでなんで…？ってなるのが通過儀礼まである

>>クエリは書けるけどスキーマがどうとかそっちの話はさっぱりわからん…
>DB「まずDB　次にスキーマ　そしてテーブルを作ります」
>俺「スキーマって何者？」
>DB「ロールを作りユーザーを作ります」
>俺「ロールって何者？」
ぼく「ロープレゲームのあれ」

遅い！実行計画確認！うーん…わからん…

シーケル…

こいつで色々やるとテストできないから止めてくれよな！
でもExcelとかKintoneよりはマシ

>””とかまだNULLなんだろうか
直すと今動いてるクエリがね…

KintoneでExcel勢やAccess勢が幸せになれるんじゃなかったの…？

テスト用のダミーデータ作る作業が一番ストレス溜まるまである

Kintoneじゃむりだよう！

>テスト用のダミーデータ作る作業が一番ストレス溜まるまである
最近はChatGPTがいい感じにやってくれるぞ

メーカーごとの方言はNULLを演算した結果とか日時型の変換とか色々あるから気を付けてね

DBごとの方言が無くなったら起こして

>KintoneでExcel勢やAccess勢が幸せになれるんじゃなかったの…？
（JSバリバリ弄り倒せるなら）なれる

見てくれよこのIS NOT NULLの山

selectとinsertとdeleteしか知らずここまで来てしまった…

OracleとかSQLSERVERとかで微妙に文法違うのやめてくれんか…

>selectとinsertとdeleteしか知らずここまで来てしまった…
ふっザコめ
俺はなんとUPDATEを使った事がある

>>KintoneでExcel勢やAccess勢が幸せになれるんじゃなかったの…？
>（JSバリバリ弄り倒せるなら）なれる
バリバリいじれたとしても幸せかなぁ…？

Cacheこそ至高

稼働中のテーブル拡張絶対やりたくないんだけどおれだけ？

可読性を盾に簡単に簡単にするんだ

>稼働中のテーブル拡張絶対やりたくないんだけどおれだけ？
やりたい奴を摘発する方が早いぞ

弊社のシステムは主要なDB全て動作します！

大変お世話になってるがnullの扱いと日付型に精度を定義できないのはクソだと思ってる

もうよくわかんないよっ！ってごちゃごちゃ書いた時
上の人にすげーな俺こんなの使わないし分かんないよとか言われたけど思い返すとあれ普通に皮肉だったかな…

コメントちゃんと書いてるか書いてないかで現場の質がわかる

>バリバリいじれたとしても幸せかなぁ…？
幸せになれるかはさておきexcelとaccessより多少はマシになるはず
コスト注いでそれなら使い慣れてるexcelとaccessでいいな！ってなるんだけども

>>稼働中のテーブル拡張絶対やりたくないんだけどおれだけ？
>やりたい奴を摘発する方が早いぞ
2人情シス…

なんとAccessならコメントが入れれないんです！
あんしん！

こうして考えるとやっぱりORMは偉大なのだ

>稼働中のテーブル拡張絶対やりたくないんだけどおれだけ？
SELECT *が乱れ飛ぶシステムならやりたくないな…

>やりたい奴を摘発する方が早いぞ
いやじゃそんなことやりtonight

>なんとAccessならコメントが入れれないんです！
>あんしん！
(このuser_numって何……？)

1本のSQLで取得するのが正義！な現場で20テーブルくらいJOINされてて感動した

>20テーブルくらいJOIN
クソ重くね？

秘技UNIONクエリ！

>1本のSQLで取得するのが正義！な現場で20テーブルくらいJOINされてて感動した
北斗の拳みたい

>>>稼働中のテーブル拡張絶対やりたくないんだけどおれだけ？
>>やりたい奴を摘発する方が早いぞ
>2人情シス…
何も起きないはずがなく…

>>1本のSQLで取得するのが正義！な現場で20テーブルくらいJOINされてて感動した
>北斗の拳みたい
ｼﾞｮｲﾝ
ｼﾞｮｲﾝ
ｼﾞｮｲﾝ

SAPのテーブルデザイン眺めてると…大企業でもこんな感じかって思う…

上司「必要ならビューを作れ」
僕「び…びゅう…？」

管理権限のせいで強引にACCESSで動かしてる我が社
容量上限があるなんて知りたく無かった…

RECURSIVEわかりづらい

>管理権限のせいで強引にACCESSで動かしてる我が社
>容量上限があるなんて知りたく無かった…
もうすぐ会えるね♥

受注・仕入・受注・売上の4種がヘッダと明細でx2で8テーブルだから各種マスタを入れたら余裕だな！

DELETE FROM IMG WHERE username <> 「」

>もうすぐ会えるね♥
もう一回超えたよ！割って繋げたよ！

TRUNCATEぽち

業務システムだとすぐに20テーブルとかにならない？

時代のトレンドはNoSQLだぞ

テーブル数2桁で済むかなあ…

>業務システムだとすぐに20テーブルとかにならない？
マスター系のテーブルだけでもちゃんと正規化していくとあっという間だ

クエリが書ける書けないなんて話よりこの数千万行のテーブルに迂闊にinsertとかupdateかけにいかない慎重さの方が重要だって改修とかリリースの度に思う

こいつは好きだしテーブル設計するのも好きだけど
ユーザーの入れたデータ探して修正してやるのは嫌い

>これがいいとはとても思わないがこいつの変わりが出てこなかったのがすべて
じゃあいいものなんだろ

joinとか面倒なだけだし別々に取得してあとから結合でよくない？

>クエリが書ける書けないなんて話よりこの数千万行のテーブルに迂闊にinsertとかupdateかけにいかない慎重さの方が重要だって改修とかリリースの度に思う
意識的にロック考慮してもロックされてて失敗するした

>joinとか面倒なだけだし別々に取得してあとから結合でよくない？
別にいいぞ
ただ大体の場合はDBに任せたほうが圧倒的に効率いい

とらんざくしょん！
ろーるばっく！
こみっと！

仕事には困らないがつらい

NoSQLって全然イメージ掴めないんだよな
まずトランザクションによるデータの一貫性が保証されていなくてもいいという概念が既にわからん

>ただ大体の場合はDBに任せたほうが圧倒的に効率いい
わかりやすさと速さのトレードオフか...

OracleBronzeだけ取ったけどSQLに触れることなく別業種に転職してしまった
この資格だけだとどれくらい仕事に役立つのかな

いつも気軽にサーバーにSQLでやらせてた結合をPowerQueryにやらせたら5分経っても結果が出なくて
いつも頼ってばかりですまんなって元に戻したよ

VARCHARA！
VARCHARA2！

月次処理でシステムがつまづくとデータ修正マジできっつい

>VARCHARA！
>VARCHARA2！
クソみてえなネーミングしやがって

Bronzeは正直言って何も…

実務には全く関係ないけど
増永良文先生のデータベースの本積みっぱなしだったの思い出した

window関数わからん…

>NoSQLって全然イメージ掴めないんだよな
>まずトランザクションによるデータの一貫性が保証されていなくてもいいという概念が既にわからん
一貫性が必要なのは連番IDとかUPDATEが必要なテーブルだけだからな
UUID使って常にINSERTしかしないなら一貫性は緩くていいんだ

>クエリが書ける書けないなんて話よりこの数千万行のテーブルに迂闊にinsertとかupdateかけにいかない慎重さの方が重要だって改修とかリリースの度に思う
ねえこのクエリ大量データのテストしてる？ディスクの容量が無かった？そっかー…

テーブルとカラムの命名規則が崩壊してどこになにが入ってるのかちゃんと把握してる人がいなくなったのが弊社

>>NoSQLって全然イメージ掴めないんだよな
>>まずトランザクションによるデータの一貫性が保証されていなくてもいいという概念が既にわからん
>一貫性が必要なのは連番IDとかUPDATEが必要なテーブルだけだからな
>UUID使って常にINSERTしかしないなら一貫性は緩くていいんだ
よく分かってないんだけどUPDATEが走るようなシステムには使わないって事なの？

updateは複雑になるから本当に必要な時以外はdelete insertで設計しろって先輩に言われたけどさっぱりよくわからん

数千万だともう重すぎの印象が