TDD(テスト駆動開発)とRDBは相性が悪い？
SQLがテストコード化できない
SQLをテストコード化する方法ってあるんですかね？ちょっと調べた限りはない気がしている。
テスト用のDBを立ててCRUDのお掃除の仕組みを作るとかが落としどころなのだろうか。どうあがいても、テストコード単体に閉じない何らかの構築が必要になる気がする。
SQL沼つらい
SQLのテストコードとか言ってる時点で察することかもしれないが、今扱ってるシステムは、大量かつ複雑なSQLに依存したつくりになっている。行数もさることながら、使っているRDBMS特有の関数や使用もゴリゴリ使いまくっている。
テストケースを洗い出すのも、手動でDBをチマチマいじりながらテストするのも、非常に辛い。
テストが辛いため、既存のSQLを触るのが嫌になる。だから、既存のSQLにWHERE句を1行足しただけみたいなSQLが脇からポコポコ生えて沼が深くなっていく。
アプリケーションで頑張れ？
SQLにロジック依存した設計がそもそもイケてない。アプリケーションでドメイン定義して、どうぞ。
と言いたくもなるが、訳もなくSQL依存しているわけではなく、専らパフォーマンスが理由でそうなってるのだと理解している。
件のシステムは巨大かつデータ量が半端ないため、速度やメモリ節約の観点から、RDB側でテーブルをJOINしまくってヒント句などを駆使してパフォーマンスを出さざるを得ないのだ。少なくともチーム内ではそのような理解に落ち着いている。
この問題をうまく設計やツールで対処する方法はあるのか？
ミナミヌマエビの飼育数
ミナミヌマエビ(チェリーシュリンプ)の適正飼育数
よく分かんないんですよね。
どれやねん、となってしまいますが。
最近の個人的見解
エビに限らず、「環境維持に必要なえさの量」で「水槽環境の代謝量」が分かるんじゃないかと最近は思ってます。
安定維持できてる環境ならば、外部からのインプットは基本的に餌と光しかないので。光量と飼育数は相関弱そうですし。
特にエビの場合、安定してくると産卵と死を連続的に繰り返すようになるので、魚のように1匹の死体が水質を壊滅させるとかもなくサイクルが回る気がしています。
我が家の場合
うちのチェリーシュリンプ水槽は下記構成で稼働中
ここ半年間は、シュリンプは目立って増えもせず減りもせず、定期的に抱卵個体がいるという感じです。
(産まれてるという事はどこかで死んでる個体もいるはずなのですが、ここ数か月で★を見たのは1匹だけ。。。夜間にひっそりと亡くなり食べられてる気がします)
結論
上記結果を見る分に、少ない餌量と換水で維持できてるので、ミナミヌマエビ(チェリーシュリンプ)はやはり水を汚しにくい生き物なのかなあと感じます。
もっと餌を増やせば、繁殖もバンバンして、水も汚れて維持が大変になってくるのかもしれません。
ウィローモスのトリミング？をした
30cmキューブのウィローモスとウォーターフェザーが伸びすぎてモッサリしてきた。
3か月の変化量↑
いい加減トリミング。。。と思ったけど、モスをうまくカットできず、取り出そうとしたら絡まって全てはがれてしまった。巻きなおすのもダルイのでポイーで。
前面のモスはウォーターフェザーだけになったが、空間もすっきりして綺麗になった。
収穫したモスは空いてる水槽に取り敢えずぶち込む。
トリミングして追加で蒔いたウォーターフェザーに集まるエビたち
ウィーピングモス付き石を買った
近所のホームセンターでウィーピングモス付きの石が売ってたので買ってみた。
取り合えず流木のてっぺんに置いてみたけど意外とデカい。
上手く垂れさがってきたらいい感じになるかな？
新しいオブジェクトにはすぐ寄ってくるシュリンプ達
