本当にあったやらかしDB設計③【ロジカルクエリー】 - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近システムエンジニアの出てくる海外映画をよく見る人です 今日は「本当にあったやらかしDB設計②【囚人番号テーブル】」に続いてびっくりしたことを紹介します #ロジカルクエリー これ、本当に良く見かけます どういうことかというと、本来アプリケーションで処理するべき機能を無理矢理クエリーに詰め込む、ということです ###何が悪いの？？ DBというのはデータという商品の入った、ただの倉庫です RDMBSという倉庫番が居るため、倉庫に入れる前に商品を検査することができます 倉庫番(RDBMS)は商品を倉庫に入れたり、取り出したりすること

[nakag0711]

そんなバカな。DB側にプロシージャ持った方が一般的には実行も開発も断然早いっつの。ただしDB側の言語環境は貧弱なことが多いが…

[fusionstar]

無駄に複雑なのは「無駄」に問題があるのであってロジカルクエリー自体の問題じゃないだろ。

[yojik]

要件とクエリを設計する人の腕によって全然違うし状況によるのでは?自分は問題が無ければViewを定義する。クエリをViewと組み合わせてシンプル・明確にできるし、ある意味CQRS的な発想になる。

[murasuke]

indexやjoinの仕組みを知らないだけではないか？人間はデータのカーディナリティを考慮して処理なんでできないのだから。まあ、ブルートフォースの方が費用対効果が高い時代なのかもしれないが・・・

[masarizm]

どの層で処理の役割を持つのかの設計はしっかりしないと後で困る。 パフォーマンスはサーバの性能による。 DBサーバの性能だいたい高いので、集合演算とか得意なものはSQLでやったほうがパフォーマンス高い時はある

[tpircs]

残念なSQLは残念でしかないけど、速度を求めるならばアプリでなくDB側で処理するよね。大量のデータをアプリ側に持ってくるとそれだけで通信も処理も重くなる。

[kagehiens]

ロジカルクエリーと適切なインデックスで強烈な高速化を実現できることこそが、商用RDBを使う価値の半分くらいを占めると思う(後の半分は分散DB)ので、環境によるとしか。オプティマイザがしょぼいなら回避すべきかも

[pavlocat]

前PJの数百行に渡るロジカルクエリを見たときはガチで吐き気した　あぁいうのは高水準言語がやる仕事なんや…

[quabbin]

id:nakag0711 同意はするのだけど、二分割帯域幅が細かった時代の名残でもあるかな。最近はストレージエンジンとクエリエンジンを分けたほうが速いという考え方も少しづつ増えてきてる。YugaByteDBとか。