![見出し画像](https://assets.st-note.com/production/uploads/images/79881384/rectangle_large_type_2_bf61bd64cfca964833ec48e1d7c82edb.png?width=1200)
【開発哲学5_1】『データベース・リファクタリング データベースの体質改善テクニック』第1章 発展型データベース開発
感想
全体を通した概説をまとめてる章って感じだね。
ここでもやはり、
で書いたインクリメント手法が大事って感じだねえ。
コードもデータベースも
少し変更しては、テストして、結果を確認して
の繰り返しが大事。
後からまとめて一気にやるなって話ね。
詳細
見出しとしては、
データベース・リファクタリング
発展型データモデリング
データベース回帰テスト
データベース成果物の構成管理
開発者サンドボックス
発展型データベース開発手法の障壁
この章で学んだこと
てな感じ。
発展型データベース手法の障壁で
開発コミュニティとデータコミュニティの文化的な障壁について書かれていて、ここもまさにそのとおりって感じ!!!!
データベース(以下、DB)側の担当者って、オブジェクト指向知らないし、「変更は悪」って感じで、なんでも手続き型でやりたがる割に、
1行1データの法則
とかは守ってないから、カラムで値が重複していたり、キーとなる値を入れてなかったり、、、
なのに変更を嫌ってすぐに改善しようとしないんだよねえ。
サンドボックスのところは、
まさにそう!!!!!
前職までで、色々
DBを扱ってきたんだけど、COBOLとかの現場では当たり前に一時処理DB(中間ファイル)にミラーして、テスト系で開発をさせたりしてたんだけど。
できたばかりの会社とか、年齢層が若い会社、オブジェクト指向言語しかやったことがない会社って、この中間ファイルって概念がない人多いんだよねえ。
本番系にいきなりアップデートするとか危険すぎるでしょ。
しかも、以前他の記事で書いたけど、
ロールバックまではコードで書いてるんだけど、なぜか接続を切るコードを書かなかったり、、、。
ACCESSだと、
クエリデザインで全て賄って、結局、制限数がすぐにいっぱいになったり、処理速度が遅くなったりねえ。
ADOとかDAOでやった方が早いんだけど、、、とかね。
昔、マイクロソフト大好きな人で、
エクセルもデータベースだ!!!!
と豪語してるエンジニアさんもいたんだけど、
ACCESSがデータ管理ツールとしてきちんとあるのに、わざわざエクセルしか使わないと、アクセス本来の機能がエクセルになかったりするし、
エクセルをDB代わりに使うなら、
くらいまで使いこなせるのかな?
エクセルをDB代わりに使うなら、バルクインサートまでやらないと、時間がかかって仕方がない気がするけどね。
おそらく、エクセルもVBAでSQLみたいにワイルドカードを使えるから、勘違いしてるのかもしれない。
最近では、
DB=SQL
って思ってる会社も多いみたいだけど、SQLは、
Structure Query Language
の略で、読んで字の如く
DBに問い合わせ手続きを構築する言語
なだけで、SQL自体はDBではないし、RealmみたいにそもそもSQLを使わないデータベースだって山ほどありますぜ。
ま、そういった違いがわからないくらいの人たちが、ビジネスでDBが重要だからって、何でもかんでも一緒くたに考えてんだろうなと。
そんなんで処理も早くて正確なDB管理なんてできるわけないと思うけどね。
まとめ
DBを扱うなら、
DB関連のコードやツール勉強をやるよりまずは、
💃DBに通底する考え方
と
各テーブルのデータの癖を見抜く洞察力🕺
が大事。
それを知らずにDB管理をしても、傷口を広げるだけ💦