MySQLの謎テーブル構成の実現方法

タイトルが意味不明ですみません

実現したいことはちょっと複雑なのですが

1．表面テーブル(view?）は1つのテーブルであり、そこにSELECTやINSERT、UPDATE、DELETEを発行。
2．裏は更新系テーブルと参照系テーブルに分かれている。

【更新】表系テーブル（view可）に発行した更新系コマンドで更新系テーブルを更新し、トリガー等でリアルタイムに参照系テーブルに反映。
【参照】表系テーブルにたいして発行したSELECT文は参照系テーブルをみる。


条件として入り口を分けることはできません。

No.4 回答者： Siegrune 回答日時： 2013/02/24 16:15

表面テーブル:全項目データを持っている

inserted/deletedのトリガーで更新系テーブルのみ更新する。
また、inserted/deletedのトリガーで、常に、参照系テーブルの値をセットする。
（間違えて参照系テーブルからセットする項目を変更されても勝手に元に戻る。
　・・・いいとは思いませんが、仕様上そうしたいならできるはずという趣旨です。）

更新系テーブル：自身の更新はなし。

参照系テーブル：inserted/deletedのトリガーで、表面テーブルを追加・更新・削除する。

とすれば表面テーブルのアクセスは簡単に実現できるけど。

実態として、参照系テーブルは見ていないけど。

No.3 回答者： yambejp 回答日時： 2013/02/20 15:30

インタフェースだけの話であれば、tableやviewを意識せず

ファンクションやプロシージャで処理すればよいのでは？

ダイレクトにクエリーを発行するのであれば
更新用と参照用は明示的にわけて指定するべきだと思いますが
逆にテーブルを分ける＝スピードを犠牲にするということですから
必ずしもスピードアップにはならないかもしれません

No.2 回答者： t_ohta 回答日時： 2013/02/20 12:44

テーブルやビューだけで実現するのは難しいでしょう。

表系テーブルと言っている部分を何らかのプログラムにして、そこで参照なら参照系テーブル、更新なら更新系テーブルへアクセスするような仕組みを作るといいと思います。

そもそも更新系と参照系のテーブルを分ける理由は何でしょうか？
理由によってはMySQL Clusterとかレプリケーションの利用といった別の選択肢もありえると思うのですが。

この回答へのお礼

> そもそも更新系と参照系のテーブルを分ける理由は何でしょうか？

更新系をInnoDBエンジン、参照系をMEMORYエンジンにすることでトランザクションが使用できてかつ高速参照可能なテーブルを実現できないかと思った次第でございます。

謎構成についてはOSSにつきテーブルを切り分けると色々と検証等発生しめんどくさくなるからです；

ありがとうございました

お礼日時：2013/02/20 12:54

No.1 回答者： Gaffgarion 回答日時： 2013/02/20 12:44

投げっぱなしな回答になりますが、

更新可能なview、などでググると参考になるでしょう。

ただ、個人的にはviewへの更新(insert,update,delete)はやりたくないので、設計を見直します。

この回答へのお礼

個人的にはViewへの更新は行いたくない気持ちは良くわかります。

しかし諸事情により設計見直しはできないのです。

お礼日時：2013/02/20 12:56