無念

09:04頃消えます SQLスレ 削除された記事が1件あります.見る

…	無念 すいませんマウスでしか操作できません

…	無念 お前らの作ったカスみたいなUIいらねえから 直接SQLでアクセスさせろや って思うことが多々ある

…	無念 rubyでSQLを隠蔽したアクセスとかなってるの見るといいからSQL書かせろと思う

…	無念 複数テーブルをJOINしたUPDATE文を理論的に説明できない テストして「まあ大丈夫だろ…」で本番環境に投げ込んでる

…	無念 まだSQL書いてんのか？O/Rマッパー使うといいぞ

…	無念 SQL使えれば食いっぱぐれないイメージなんだけど 実際はどうなんでしょう

…	無念 悩む要素がわからない

…	無念 SQL使えるだけじゃゴミだろ。論理設計できてようやく一人前じゃね？

…	無念 >まだSQL書いてんのか？O/Rマッパー使うといいぞ O/Rマッパーでどうやって実行計画制御するんですか

…	無念 >まだSQL書いてんのか？O/Rマッパー使うといいぞ もう10年前くらいからそれ言われてるけど「SQLのほうがメンテ性よくないですか？」と思ってしまう 頭固くて理屈が全然わからん

…	無念 > O/Rマッパーでどうやって実行計画制御するんですか オブジェクト化して使いたいエンドポイントで好きに使えばええだけだと思うが

…	無念 エントリーポイントか

…	無念 もうずいぶん前にOR導入するんで会社で社員向け説明会があった その時はなるほど！と思ったけど 実装する段になって「これめんどくせえ…SQLのが楽じゃねえかよ…」となってその時のまま今に至る 頭固くなってるのは認める

…	無念 実行計画１つ１つのオブジェクトか 胸が躍るな

…	無念 >>まだSQL書いてんのか？O/Rマッパー使うといいぞ >もう10年前くらいからそれ言われてるけど「SQLのほうがメンテ性よくないですか？」と思ってしまう >頭固くて理屈が全然わからん 従来の開発だとデータ構造を決めてそこからシステムを作ってたけど 逆転させてシステムからデータ構造を作るのがO/Rマッパー 要するにクラスとほぼ同じ構造のテーブルが多数できて クラスのオブジェクトをいじるとそれがそのテーブルのデータに反映される仕組み と言えば聞こえがいいけどRDB的に言うとゴミみたいなデータ構造のテーブルが多数出来て非常に小汚いことになる

…	無念 そもそもデータベースって企業が活用中のデータが入ったものが既にあるのが普通じゃないのか

…	無念 >まだSQL書いてんのか？O/Rマッパー使うといいぞ おっそ

…	無念 >SQL使えれば食いっぱぐれないイメージなんだけど >実際はどうなんでしょう 食いっぱぐれないというか 大工がノコギリ使えますと言ってるようなものだよ 出来て当たり前でできないと大工と見なされない だから強みでも何でもない

…	無念 そもそもSQL自体は数日で学べる程度のことだよ

…	無念 チューニング不要な ある程度リッチな環境が前提なんだろうな

…	無念 >そもそもSQL自体は数日で学べる程度のことだよ 浅いところはそうだけど かなり奥が深い言語だからディープな世界があるぞ たいていのプログラマはそもそも深い世界があるということすら知らないけど

…	無念 ORマッパーはSQLがブラックボックスでやり取りされるのがきもい

…	無念 書き込みをした人によって削除されました

…	無念 オブジェクトと対応させたいならKVS使ったほうがいいと思う

…	無念 僕はEntityFrameworkちゃん！

…	無念 >そもそもSQL自体は数日で学べる程度のことだよ サブクエリあたりから「C言語始めたけどポインタでつまづきました…」みたいなハードルのSQL版がある

…	無念 ややこしいことをやろうとすると結局SQLもどきを書く羽目になるし ORマッパーってそんなにいいものかね

…	無念 SQLそのものよりもインデックスという概念が理解しにくかった

…	無念 hogehoge' or 'A'='A 検索っと

…	無念 >ORマッパーはSQLがブラックボックスでやり取りされるのがきもい DB側のログ見ると毎回コンパイルされるようなウンコSQLが流れててDB管理者夜も眠れない

…	無念 >ややこしいことをやろうとすると結局SQLもどきを書く羽目になるし >ORマッパーってそんなにいいものかね 工数や人的ミスを削減するのには多少は効果あるんじゃないの

…	無念 パフォーマンスとかそこまで気にしないような小規模システム向けじゃないかな 少々雑に早く作れるという所が強みなんだし

…	無念 まあ今はメモリ資源が潤沢だから変なSQL実行してもそれなりの速度で動くって言うのはある サーバー集約とかしてメモリ資源が厳しくなると途端に永遠に応答返ってこなくなるようなSQLでも

…	無念 データ件数によるんかね 最適化が必要ないレベルのものにしか使えないってこと？

…	無念 SQLをまともに使えないプログラマでも開発できる とかメリットを説明するけど そもそもそんなプログラマにORマッパー触らせたら 意図せずに更新したりしてバグを作り込みそうなんだけど

…	無念 ORマッピング系の奴はクエリの回数気にせずバンバン投げまくるから 本当にパフォーマンスが必要なら気になる所やね

…	無念 データおかしくなってこれトランザクションどうなってんだって調べようとしても隠蔽されてて全然わからないという

…	無念 複雑なクエリ投げる必要あるならビューで隠蔽したほうがいいのでは

…	無念 >複雑なクエリ投げる必要あるならビューで隠蔽したほうがいいのでは 「複雑なクエリを組む必要はないよ 関連するテーブル全部でselect * して全件ローカルに取ってきてアプリでループして結合すればよい」 ↑俺のORに対する認識はそんな感じ

…	無念 >関連するテーブル全部でselect * して全件ローカルに取ってきてアプリでループして結合すればよい DBA激おこ

…	無念 DBをファイルを保管してるストレージと見なす発想って COBOLとかの時代に退化してないだろうか これは進化ではなく退化じゃないのか

…	無念 SQLに自信があってSQL部分だけ口出しするマンが客にいるとね

…	無念 >SQLに自信があってSQL部分だけ口出しするマンが客にいるとね そりゃ客側のDB管理者は当たり前にSQL部分に対して口出しするだろ 好き勝手にやらせるとDBマシンのメモリ使い切ってスワップさせるようなバカSQL投げてくるのいるし…

…

無念 口マン

…

無念 爺

…	無念 >僕はEntityFrameworkちゃん！ 四年くらい前に触ったことあるけど、使いやすくなってるの？

…	無念 ORはシステムの規模が大きくなっていって気が付くとメンテが恐ろしく難しい怪物になる

…	無念 DB設計とかI/Fの調整しくじると1000行くらいのSQLを組む羽目になる

…	無念 UTFのEMOJIに殺意が沸いた

…	無念 EFってADO.NETが皮被ってるだけなのか？

…	無念 >サブクエリあたりから「C言語始めたけどポインタでつまづきました…」みたいなハードルのSQL版がある サブクエリって単に関数を評価して引数に渡すようなものだしポインタよりは圧倒的に簡単だろ

…	無念 ディレクトリ型DB使ってる案件に放り込まれそうになったから全力で回避してきた

…	無念 oledbとかadoしか知らん... てきとーにSQL投げてるわ

…	無念 雑魚SEだからMySQLしか書けないや

…	無念 Mysqlのフルダンプってそのままauroraにリストアできるのん？

…	無念 たまにEXCELに繋いでデータとる処理作る お客様、CSVになりませぬか？

…	無念 >お客様、CSVになりませぬか？ カンマをエスケープし忘れたデータとかEXCELで編集したせいでハイフン区切りが日付に化けてたりというクソデータが届く予感