• 締切済み

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

タイトルが意味不明ですみません 実現したいことはちょっと複雑なのですが 1.表面テーブル(view?)は1つのテーブルであり、そこにSELECTやINSERT、UPDATE、DELETEを発行。 2.裏は更新系テーブルと参照系テーブルに分かれている。 【更新】表系テーブル(view可)に発行した更新系コマンドで更新系テーブルを更新し、トリガー等でリアルタイムに参照系テーブルに反映。 【参照】表系テーブルにたいして発行したSELECT文は参照系テーブルをみる。 条件として入り口を分けることはできません。

みんなの回答

  • Siegrune
  • ベストアンサー率35% (316/895)
回答No.4

表面テーブル:全項目データを持っている inserted/deletedのトリガーで更新系テーブルのみ更新する。 また、inserted/deletedのトリガーで、常に、参照系テーブルの値をセットする。 (間違えて参照系テーブルからセットする項目を変更されても勝手に元に戻る。  ・・・いいとは思いませんが、仕様上そうしたいならできるはずという趣旨です。) 更新系テーブル:自身の更新はなし。 参照系テーブル:inserted/deletedのトリガーで、表面テーブルを追加・更新・削除する。 とすれば表面テーブルのアクセスは簡単に実現できるけど。 実態として、参照系テーブルは見ていないけど。

  • yambejp
  • ベストアンサー率51% (3827/7415)
回答No.3

インタフェースだけの話であれば、tableやviewを意識せず ファンクションやプロシージャで処理すればよいのでは? ダイレクトにクエリーを発行するのであれば 更新用と参照用は明示的にわけて指定するべきだと思いますが 逆にテーブルを分ける=スピードを犠牲にするということですから 必ずしもスピードアップにはならないかもしれません

  • t_ohta
  • ベストアンサー率38% (5253/13739)
回答No.2

テーブルやビューだけで実現するのは難しいでしょう。 表系テーブルと言っている部分を何らかのプログラムにして、そこで参照なら参照系テーブル、更新なら更新系テーブルへアクセスするような仕組みを作るといいと思います。 そもそも更新系と参照系のテーブルを分ける理由は何でしょうか? 理由によってはMySQL Clusterとかレプリケーションの利用といった別の選択肢もありえると思うのですが。

kudakuda1211
質問者

お礼

> そもそも更新系と参照系のテーブルを分ける理由は何でしょうか? 更新系をInnoDBエンジン、参照系をMEMORYエンジンにすることでトランザクションが使用できてかつ高速参照可能なテーブルを実現できないかと思った次第でございます。 謎構成についてはOSSにつきテーブルを切り分けると色々と検証等発生しめんどくさくなるからです; ありがとうございました

回答No.1

投げっぱなしな回答になりますが、 更新可能なview、などでググると参考になるでしょう。 ただ、個人的にはviewへの更新(insert,update,delete)はやりたくないので、設計を見直します。

kudakuda1211
質問者

お礼

個人的にはViewへの更新は行いたくない気持ちは良くわかります。 しかし諸事情により設計見直しはできないのです。

関連するQ&A