他のシステムとの連携のために
zanjibar
少しの改造なんですが、他のシステムとの連携のために、users に another_id というカラムを
足すのはどうでしょうか？
another_id varchar(40) ほどとっておけば十分でしょう。
他のシステムのＩＤと連動するためです。
uid,uname というuser 情報体系とあわないことがあるので、別個 id のカラムをもっていると便利です。
次のバージョンアップにはいれませんか？
minahito
やるなら参照テーブルのほうがいいと思います。
でもってその参照テーブルの構造は連携するシステムによって変わるよう
な気がするんですが、デフォで持つと何らかの形で構造固定になってしま
うのがちょっと……
連携する以上、連携部はモジュールで入るし、
モジュールがインストールされる際に参照テーブルをちょいちょい
と .sql に書いとけば勝手に作ってくれる。
これで全部うまくいく＆構造的にもベストな気がするんですが、固定領域
をユーザーテーブルに持つ必要あるんでしょうか？
tadashi
連携もいろいろパターンありますので、quick & dirty のために、another_id があるとありがたいなというわけです。
今考えているのは、netcommons との連動です。ログインしたときに、同期とるのに、ログインID（uname) だと代わってしまう場合ある
ので、
ユニークIDでのリンクをとりたいだけです。
単に quick & dirty がいいというだけです。また、ペナルティが少しあってもいいなら、ユーザ情報をチェックして同期をとってしまいま
す。
すると、XOOPS のユーザモジュールは変更かけず、ログインチェックのpreload のみの変更ですみます。
minahito
共有バッファにしちゃうと、データオーナーが分からなくなるからトラブ
ルの元になりますよ。ひとつの領域を複数のプログラムモジュールが書き
にいったり読みにいったり片方がアンインストールされることもあるん
で。その領域をクリアするタイミングも誰がどこでなにを根拠にやるとい
うことになります。
この点テーブル追加なら、専用の保存域を確保するんで、その心配があり
ません。
XCL のレベルで衝突を自分で管理してもらうような領域を追加するわけ
にもいかんので、モジュールによるテーブル作成と削除を使うべきだと思
うんですが（十分 quick です）が、その手間さえ惜しまれるのが
現実ということであれば何ぞスケルトンモジュールでも用意しましょう
か。
（noneでもいけるかもしれない）
gusagi
自分も、minahitoさんと同じで、別テーブルで管理する方が良いと思います。
minahitoさんがあげた理由にプラスして理由をあげると、
複数のシステムと連携する場合、カラムが1つしかないと実現できないですよね^^;
なので、それぞれのシステムとの連携モジュール側のユーザ情報部分で、
usersテーブルのuidと同じ値を持つようにするのが一番良いと思います。
2009年9月12日13:20 minahito <mina...@gmail.com>:
>
> minahito です。
>
> 共有バッファにしちゃうと、データオーナーが分からなくなるからトラブルの元になりますよ。ひとつの領域を複数のプログラムモジュールが書きにいったり読みにいったり片方がアンインストールされることもあるんで。その領域をクリアするタイミングも誰がどこでなにを根拠にやるということになります。
>
> この点テーブル追加なら、専用の保存域を確保するんで、その心配がありません。
>
> XCL のレベルで衝突を自分で管理してもらうような領域を追加するわけにもいかんので、モジュールによるテーブル作成と削除を使うべきだと思うんですが（十分
> quick です）が、その手間さえ惜しまれるのが現実ということであれば何ぞスケルトンモジュールでも用意しましょうか。
> （noneでもいけるかもしれない）
>
>
--
Name : Makoto Hashiguchi
HN : gusagi
URL : http://www.gusagi.com/
Mail : gus...@gmail.com
tadashi
了解です。
none モジュールあるといいです。もともとはいっていると使いやすいですし、
> 現実ということであれば何ぞスケルトンモジュールでも用意しましょう
> か。
> （noneでもいけるかもしれない）