https://b.hatena.ne.jp/entry/s/qiita.com/bouitengineer12/items/e4edbb604c961b7aa993 Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近システムエンジニアの出てくる海外映画をよく見る人です 今... https://b.hatena.ne.jp/techtech0521/20240404#bookmark-4689755954473300514 2024-04-04T13:08:37Z あとで読む https://b.hatena.ne.jp/murasuke/20200816#bookmark-4689755954473300514 indexやjoinの仕組みを知らないだけではないか？人間はデータのカーディナリティを考慮して処理なんでできないのだから。まあ、ブルートフォースの方が費用対効果が高い時代なのかもしれないが・・・ 2020-08-16T10:57:51Z sql database https://b.hatena.ne.jp/yojik/20200811#bookmark-4689755954473300514 要件とクエリを設計する人の腕によって全然違うし状況によるのでは?自分は問題が無ければViewを定義する。クエリをViewと組み合わせてシンプル・明確にできるし、ある意味CQRS的な発想になる。 2020-08-11T04:43:15Z https://b.hatena.ne.jp/yamataku13/20200811#bookmark-4689755954473300514 2020-08-11T03:15:04Z あとで読む https://b.hatena.ne.jp/ayaniimi213/20200811#bookmark-4689755954473300514 2020-08-11T02:33:33Z https://b.hatena.ne.jp/kjtec/20200811#bookmark-4689755954473300514 2020-08-11T02:26:48Z あとで読む https://b.hatena.ne.jp/alcus/20200811#bookmark-4689755954473300514 2020-08-11T02:00:23Z database https://b.hatena.ne.jp/tanavel/20200811#bookmark-4689755954473300514 2020-08-11T01:16:22Z あとで読む https://b.hatena.ne.jp/yste/20200811#bookmark-4689755954473300514 2020-08-10T23:14:10Z あとで読む https://b.hatena.ne.jp/Hiro_Matsuno/20200811#bookmark-4689755954473300514 2020-08-10T21:39:10Z https://b.hatena.ne.jp/hujuu/20200811#bookmark-4689755954473300514 2020-08-10T16:22:29Z https://b.hatena.ne.jp/masarizm/20200810#bookmark-4689755954473300514 どの層で処理の役割を持つのかの設計はしっかりしないと後で困る。 パフォーマンスはサーバの性能による。 DBサーバの性能だいたい高いので、集合演算とか得意なものはSQLでやったほうがパフォーマンス高い時はある 2020-08-10T12:42:24Z https://b.hatena.ne.jp/fusionstar/20200810#bookmark-4689755954473300514 無駄に複雑なのは「無駄」に問題があるのであってロジカルクエリー自体の問題じゃないだろ。 2020-08-10T11:10:13Z https://b.hatena.ne.jp/mstk_knife/20200810#bookmark-4689755954473300514 2020-08-10T10:59:45Z あとで読む https://b.hatena.ne.jp/tpircs/20200810#bookmark-4689755954473300514 残念なSQLは残念でしかないけど、速度を求めるならばアプリでなくDB側で処理するよね。大量のデータをアプリ側に持ってくるとそれだけで通信も処理も重くなる。 2020-08-10T10:43:59Z https://b.hatena.ne.jp/dragons004/20200810#bookmark-4689755954473300514 2020-08-10T09:56:53Z https://b.hatena.ne.jp/charged_m_plus/20200810#bookmark-4689755954473300514 2020-08-10T09:49:04Z https://b.hatena.ne.jp/ant_mugi/20200810#bookmark-4689755954473300514 2020-08-10T08:54:50Z あとで読む https://b.hatena.ne.jp/kagehiens/20200810#bookmark-4689755954473300514 ロジカルクエリーと適切なインデックスで強烈な高速化を実現できることこそが、商用RDBを使う価値の半分くらいを占めると思う(後の半分は分散DB)ので、環境によるとしか。オプティマイザがしょぼいなら回避すべきかも 2020-08-10T08:41:11Z https://b.hatena.ne.jp/pavlocat/20200810#bookmark-4689755954473300514 前PJの数百行に渡るロジカルクエリを見たときはガチで吐き気した　あぁいうのは高水準言語がやる仕事なんや… 2020-08-10T08:21:53Z https://b.hatena.ne.jp/quabbin/20200810#bookmark-4689755954473300514 id:nakag0711 同意はするのだけど、二分割帯域幅が細かった時代の名残でもあるかな。最近はストレージエンジンとクエリエンジンを分けたほうが速いという考え方も少しづつ増えてきてる。YugaByteDBとか。 2020-08-10T06:23:05Z https://b.hatena.ne.jp/nakag0711/20200810#bookmark-4689755954473300514 そんなバカな。DB側にプロシージャ持った方が一般的には実行も開発も断然早いっつの。ただしDB側の言語環境は貧弱なことが多いが… 2020-08-10T06:09:01Z