■
(;´Д｀)＜もーSQLが複雑すぎて大変なんですよ〜
こんな言葉を外部から聞いたりする。
仕様なんざ聞かなくてもこれだけは言える。
( ・ω・)o＜それは設計が悪い。
SelectだろうがUpdateだろうがDeleteだろうがこれは変わらない。
複雑すぎるSQL文になるってのは設計がおかしい。
設計といってもテーブル設計だったり、プログラム設計だったりするのだが、
どちらにせよ回避のしようがある。
そもそも検索と追加更新削除は相対するところに位置しているわけで。
検索性能を求められる照会画面において、
追加更新削除処理が頻繁にあるテーブルを参照しているなんてなーおかしなことなのだ。
正規化しすぎてたくさん*1のテーブルからいろんなデータを引っ張ってくるってのも
アホらしいことなのだ。
照会機能において最も重要な要素を無視しているのだ。*2
データ登録時に正規化のためのプログラムを作るのが大変なのならば。
登録専用のワークテーブルを作り、いったんそこに溜め込む。
それからゆっくり正規化されたテーブルへの再度登録しなおす処理にすれば
ＤＢの負荷や、プログラムの修正負荷は軽減される。
なんでもかんでもダイレクトにやればいいってもんではないのだ。
データ参照時に大変なSQLを発行しつつ照会しなきゃいけない要件があるならば。
検索専用のテーブルを作ってそこに入れれ。( ・ω・)oビシッ
一番ラクチンな方法である。
が。
そうできなければ。
リアルタイムでいろんなデータを参照せな意味が無いといった要件がある場合など、
テーブル作るのもどーなのよといった状況な場合には。
VIEW作れ( ・ω・)oビシッ
SQLの検索コストや複雑さはともかく、少なくともプログラムはひじょーに楽になるはずである。
っというように。
なんしかどうにかすれば回避策と複雑さへの対処法はあるのだ。
しかしてそれをやらない、やれてないといった設計は、
プログラマの嘆きとなって聞こえてくる。
また、状況によっては
( ´Д｀)/先生！新規テーブルとかビューとか作っちゃダメって言われますた。
ってこともあるだろう。
これは最初の設計が悪いのである。
そんな不自由なテーブル設計をした挙句に、
環境まで不自由なものと決めたやつらの責任である。
もっともこれは煩雑なSQL文がたくさん生まれる状況に限っての話だが。
*3
っとはいうものの。
何事にも例外はある。
ちっちゃいシステムとか、利用者数が少なくて、速度的な不満はないという状況がほぼ保証できる状態であるとかだ。
こんなんならわざわざ検索速度向上のための手をうつ必要はない。かもしれない。
多少遅くても不満はないという確約をユーザからとれればこーゆーのでもありかもしれない。
そんなんを踏まえて。
複雑怪奇なSQLを作ってしまったときは。
詳しい人に相談しにいきましょう。
また、より簡単に実現できる方法を模索してみましょう。
そういう努力があってこそ、よりよいプログラム設計ができるようになると思うから。
