- - PR -
Struts&Mysqlにてユーザーごとのテーブル管理方法について
1
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-07 17:32
はじめまして。
現在Tomcat5&Struts1.1&Mysql4.0をしようしてアプリケーションを作成中なのですが DBの設計上、明細レコードを管理するテーブルが複数ユーザに対応していません。 ===[TableA]=============== create table meisai { meisaino integer not null primary key, meisaikin integer not null }; ========================== これを複数ユーザー対応にするにはユーザーカラムを追加した ===[改TableA]=============== create table meisai { meisaino integer not null primary key, userid varchar(20) not null, meisaikin integer not null }; ========================== にすると、このテーブルにはユーザーごとのデータが管理できる様にはなるのですが (SELECT時に抽出条件をuseridで絞り込めるという点で管理できる) @特にTableAに複数のユーザーデータを入れておく必要はない。逆に検索時のレコード総数が多くなりすぎて、後々困ってしまうかもしれない。また、各ユーザごとの明細レコードはそれぞれのユーザーが自分のレコードを参照するのに必要であって、他人の明細レコードを見る必要性もないため。 Aもう既にTableAでの実働するアプリケーションが作成済みなので、できれば現状のアプリケーションの修正をなくして(もしくは極小化)、なんとかStrutsのDatasource設定とMysqlの複数ユーザーによるテーブル管理方法があれば、その方向で実現したい。 という点から何かいい解決策を探しております。 Mysqlでのスキーマ管理についてもいろいろと調べてみましたが、力不足のためなかなか見つけることもできませんでした・・・・ 参考ご意見、アドバイスのほどよろしくお願いいたします。 | ||||||||||||||||
|
投稿日時: 2004-06-07 18:20
永井です。
ちょっとよく話が見えなかったのですが……
「追加仕様に旧テーブル構造が合わない」ということですよね? 基本的にはシステムの寿命と割り切って、マルチユーザー前提で作り直した方が良いと思いますが……。 無理矢理やるのであれば、マルチユーザー対応のマスターを作って、各ユーザーには自分に関係するビューだけを見せるようにすれば、アプリはそんなに手を入れる必要はないかも知れません。 セッションにDataSouceの参照入れておいて、DAOに毎回それを渡すようにするとかするのかな、その場合…… ところで、普通のRDBMSは(ニンゲンの感覚で)少々レコード数が多くなった程度では問題起きないと思います。M(メガ)オーダー程度では全然問題にならないとおもいますよ、よっぽど変なSQLを発行していない限りは。 | ||||||||||||||||
|
投稿日時: 2004-06-07 18:50
早々のご返答ありがとうございます。
そういうことになります。業務システムとして作成しているわけではなく個人用として作成している最中に、ふと思い立って湧き出た問題でした。単純な家計簿をWebで管理するアプリなんですが、これをWebで公開して登録制で使用できるものにするとなると・・・・と考えた次第です。
できれば、その実現方法をもう少し具体的に教えていただけると幸いです。
確かにそうですよね。 ただ、今回は勉強の意味を含めてテーブルのAlterよりも、別の方法での実現方法でやってみたいんですよ〜。 ちなみにStrusのDataSourceを使用しているのですが、これって取得したコネクションは 既に特定データベースの特定ユーザーという形しか取れないと思うのですが、上記のような場合には実際には間にどのようなコネクションファクトリクラス?みたいなものが必要になってくるのでしょうか? 是非ご教授願います。 | ||||||||||||||||
|
投稿日時: 2004-06-08 12:44
まず、上述の「マルチユーザー対応のマスターを作って...云々」のくだりですが、これはミスでした。申し訳ありません。 「複数の人からの使用に耐え得る」ことだけが今回の要件で、マルチユーザーならではの機能(Ex.統計を出したり、ある明細を複数から共有したり)は範囲外ですよね。 そうすると、基本的には現在のテーブル構造と全く同じ構成を持ったDBユーザーを量産して、各ログインユーザー毎に接続(接続プール)を独立に生成して、それを用いて接続してやる……ということで実現可能です。 で、はっきり言って、全くお勧め出来ない手法です。 特にWebで公開して、不特定多数から使用することを考えてらっしゃるようですから……。 #想像してみてください。ユーザーが新規で登録される毎に、create user、create table、create sequence...etcが大量に走るのです。そして、そのために強力な権限を持ったユーザーが待機します。 私が当初想定していたのは「今まで単独で使っていたが、2人とか3人とかの特定少数で使うことになった。改修作業は出来るだけ減らしたい」というものです。 #なので、ユーザーもテーブルも手動で増やして、DataSourceも手動でユーザーの数だけ登録して、最後にTomcat再起動でいいや……とか考えていました
テーブルの構造を変えての実現の方が、ずっと勉強になるのではと思います。 ユーザー増やして対処するというのは、曲芸というか、一発芸というか、苦し紛れというか……上手く表現出来ませんが、そういう部類のものだと思いますので。
すみません。私はここら辺を自分で組んだことがないので、ちょっと分からないです。 #Tomcatとかに頼らずやっているのをチラッと見たことはあるんですが | ||||||||||||||||
|
投稿日時: 2004-06-08 16:45
SDMです。ご親切なアドバイスありがとうございました。 おっしゃるとおりで、モデル領域のスコープ変更とかも含めると、そもそも論としてモデルを変更した際の勉強ということのほうが有意義のような気がしてきました。 再度DBの設計をしなおす方向で、Tryしてみます。 ありがとうございました。 | ||||||||||||||||
1
