- 締切済み
MySQLの謎テーブル構成の実現方法
- みんなの回答 (4)
- 専門家の回答
みんなの回答
- Siegrune
- ベストアンサー率35% (316/895)
表面テーブル:全項目データを持っている inserted/deletedのトリガーで更新系テーブルのみ更新する。 また、inserted/deletedのトリガーで、常に、参照系テーブルの値をセットする。 (間違えて参照系テーブルからセットする項目を変更されても勝手に元に戻る。 ・・・いいとは思いませんが、仕様上そうしたいならできるはずという趣旨です。) 更新系テーブル:自身の更新はなし。 参照系テーブル:inserted/deletedのトリガーで、表面テーブルを追加・更新・削除する。 とすれば表面テーブルのアクセスは簡単に実現できるけど。 実態として、参照系テーブルは見ていないけど。
- yambejp
- ベストアンサー率51% (3827/7415)
インタフェースだけの話であれば、tableやviewを意識せず ファンクションやプロシージャで処理すればよいのでは? ダイレクトにクエリーを発行するのであれば 更新用と参照用は明示的にわけて指定するべきだと思いますが 逆にテーブルを分ける=スピードを犠牲にするということですから 必ずしもスピードアップにはならないかもしれません
- t_ohta
- ベストアンサー率38% (5253/13739)
テーブルやビューだけで実現するのは難しいでしょう。 表系テーブルと言っている部分を何らかのプログラムにして、そこで参照なら参照系テーブル、更新なら更新系テーブルへアクセスするような仕組みを作るといいと思います。 そもそも更新系と参照系のテーブルを分ける理由は何でしょうか? 理由によってはMySQL Clusterとかレプリケーションの利用といった別の選択肢もありえると思うのですが。
- Gaffgarion
- ベストアンサー率45% (45/99)
投げっぱなしな回答になりますが、 更新可能なview、などでググると参考になるでしょう。 ただ、個人的にはviewへの更新(insert,update,delete)はやりたくないので、設計を見直します。
お礼
個人的にはViewへの更新は行いたくない気持ちは良くわかります。 しかし諸事情により設計見直しはできないのです。
お礼
> そもそも更新系と参照系のテーブルを分ける理由は何でしょうか? 更新系をInnoDBエンジン、参照系をMEMORYエンジンにすることでトランザクションが使用できてかつ高速参照可能なテーブルを実現できないかと思った次第でございます。 謎構成についてはOSSにつきテーブルを切り分けると色々と検証等発生しめんどくさくなるからです; ありがとうございました