TDD(テスト駆動開発)とRDBは相性が悪い？

SQLがテストコード化できない

SQLをテストコード化する方法ってあるんですかね？ちょっと調べた限りはない気がしている。

テスト用のDBを立ててCRUDのお掃除の仕組みを作るとかが落としどころなのだろうか。どうあがいても、テストコード単体に閉じない何らかの構築が必要になる気がする。

SQL沼つらい

SQLのテストコードとか言ってる時点で察することかもしれないが、今扱ってるシステムは、大量かつ複雑なSQLに依存したつくりになっている。行数もさることながら、使っているRDBMS特有の関数や使用もゴリゴリ使いまくっている。

テストケースを洗い出すのも、手動でDBをチマチマいじりながらテストするのも、非常に辛い。

テストが辛いため、既存のSQLを触るのが嫌になる。だから、既存のSQLにWHERE句を1行足しただけみたいなSQLが脇からポコポコ生えて沼が深くなっていく。

アプリケーションで頑張れ？

SQLにロジック依存した設計がそもそもイケてない。アプリケーションでドメイン定義して、どうぞ。

と言いたくもなるが、訳もなくSQL依存しているわけではなく、専らパフォーマンスが理由でそうなってるのだと理解している。

件のシステムは巨大かつデータ量が半端ないため、速度やメモリ節約の観点から、RDB側でテーブルをJOINしまくってヒント句などを駆使してパフォーマンスを出さざるを得ないのだ。少なくともチーム内ではそのような理解に落ち着いている。

この問題をうまく設計やツールで対処する方法はあるのか？