ホーム > フォーラム > 開発 > モジュール開発 > ????

????
投稿者: itv | 投稿日時: 2006/1/17 20:53 | 閲覧: 34539回
itv
????????????????????

Oracle10g????????????????

?????????????????Oracle????????(??????)
????????????????????????????????

XOOPS Cube????????????MySQL4.0.xx??????PostgreSQL?????????
??????????

???XOOPS??DB????????????????????????????
???????????????????????????????
?PHP?DBMS????????
?PEAR?????(??DB???????)?????
?DBMS???SQL?????????????????
????????(????????)?????????????????
?????????????

????????????????????????
???????????????????????????????
?????????
????????????????????????????????

コメント(25)

新しいものから | 古いものから | ネスト表示 | RSS feed
Re: DB換装 
投稿者: puchi | 投稿日時: 2006/1/17 22:37
puchi
XOOPS 2系のモジュールを対応させるのはきついんじゃないですかね。
XoopsObject使ってる人やらSQL直接叩いている人もいるでしょうし。

将来的には、XC3系で PDO とかZend PHP frameworkで吸収とかになるんじゃないでしょうか。(勝手な予想)

#最近のRuby on Railsの勢いはすごいなぁ
Re: DB換装 
投稿者: puchi | 投稿日時: 2006/1/17 22:53
puchi
引用:

Q2.課題解決へのミッシングリングは何でしょう?
テーブルレイアウトからデータアクセスクラスを自動生成するような
ツールでしょうか。
サニタイジングなどもカバーしてくれるようなものはできるのかなぁ。


ここで言っているのは、extoolsとかcubson(まだ全く見てないですけど)のmakeobjectみたいなものですかね?
X2。1のソースをまだちゃんと見てないですけど、ハックすればある程度できそうな気はします。
確か抽象レイヤーあたりの対応は、まだ先のはずですが。

#ちょっと時間なくて適当なこと書いてるかも知れません。
Re: DB換装 
投稿者: minahito | 投稿日時: 2006/1/17 22:54
minahito
XOOPS Cube2.1 は、Cube部分のソースコードがあって、そこからメインの起動を取る基盤モジュールを使って動作する仕組みになっていますが、この仕組みは、

1) 互換性
2) 次期版の並行開発
3) 事実上のコア特権領域の破棄

の3つの意味合いがあります。

この基盤モジュールに legacy(現base)を選択すると、プログラムの初期化プロセスの中で XoopsDB クラスのインスタンスを DB インスタンスとして使用し、そのほか各互換クラスのインスタンスをセットアップしながら動作に入っていく……という感じになってます。
基盤となるモジュールは、ロガーやDBレイヤー、ユーザーに使用するクラスなどを選択する権利を(現時点では)持っていることになります。

# これは設計的には「?」なところだと思う。
# 2年前、XOOPS 2.0.6〜7 あたりでモジュール開発者として苦虫を噛んだ経験
# から、特に 3) を実現したかった。

# 2) は机上論を避けコードを書きながら皆で検討できる仕組みをイメージ
# このスレッドのような話題を実装して、配って使って検証するような感じ
# (当然誰がやっても構わない)

で、この仕組みから行くと、基盤モジュールは設定ファイルでスイッチするので、現在の基盤モジュールである legacy の発展系が次版ということにはならなくなります。legacy は X2 のモジュールを動かすための基盤で、 next (仮名)は X2 のブリッジを持たなくてよいと思います。 next とあわせて legacy の保守・開発を続けてもいいし、それは誰がやっても構いませんし、ちゃんと維持されればユーザーはどちらを使っても良くなるでしょう。
(実際には保険みたいなもので、そんな賑やかなことにはならないだろうと思いますが……万が一そうなったら面白いですね)

前置きが長くなりましたが、データ移行さえできれば legacy → next ではモジュールの互換性は切れてもいいと思ってます。というか切った方がいいと思う。
動く動かないというだけでなく、フォーマット自体ごっそり変えることも考えてもいいかもしれません。(個人的には「考えるべきだ」というノリ)

それはDBに限らず、すべてを一新(というか独自クラスからPHPの一般的なライブラリに切り替えていくとか……って詳しくないんだけど……)するチャンスだと思います。

一般的なCMSのようにURL(ページ)から動作モジュールを決定するフロントコントローラタイプを検討する余地もありますし、また Nuke スタイルのうえでフロントコントローラにするという余地もあるでしょうし、いろいろです。
それはみんなで色々書いて遊んでみるのがいいと思ってます。

このようにガツンと変わって互換性がまるでなくなっても、legacy のほうを基盤に使えば互換機能で(誰かがメンテする間は)使い続けられますから、過剰に変えてダメになってみたりするのもありなんじゃないかな?という気がしてます。

移植に関しては、 legacy からも Cube の本体の概念を使うことはできるので、そういうところを利用したプログラムは最小の手間で引き継げるのではないかと思います。
Re: DB換装 
投稿者: itv | 投稿日時: 2006/1/18 0:15
itv
puchiさん、minahitoさん、私流の言葉を理解して頂きレスありがとうございました。

私にはやはりインタープリターが必要のようです。
でも何となく分かったのは
1.既存モジュールはモノによってはDB換装のハードルは以外と低いかもよ。
どうしても必要ならトライする価値はある。でもコアとしての互換性維持はやるつもりは無い。
2.XC2.1からは設定ファイルでDB選択もできる方向でモックアップをみんなでいじりながら進めて行きたい。

という理解をしました。合っていますかね。

XC2.1対応のモジュールに関しては開発フレームワーク(というと大げさですが)というか、ガイドラインが要りそうですね。

話は逸れますが、ライセンス料の問題で、開発はMySQLで、本番機はOracleというやり方もよく耳にします。

一貫してOracleで開発できるという状況が来れば、ビジネスユースではかなり需要があると思います。
ビジネス側からも資産のオープンソース化、という流れも来るかもしれません。(個人的にはそこらをやりたい)
トラフィックやデータ量に応じてWebサーバとDBサーバを増やしてロードバランサーで負荷分散などScalabilityの方向性はかなり充実してくるのではないでしょうか。
Re: DB換装 
投稿者: onokazu | 投稿日時: 2006/1/18 9:14
onokazu
PDOはPHP5ですよね。XCにてPHP5必須にするのはまだ少し
早いかなと思います。結果として流れに遅れてしまうのも怖いですが、、
ただ、Propel等もそうですが、多くの優れたオブジェクト・リレーショナル・
マッパー(ORM)がPHP5であるのには悩みどころですね。

Zend Frameworkに関してはどうなんでしょうね。以前に概要は示されましたが、
それ以降全く情報が出ないので既存のフレームワーク開発者たちからは
かなり不満があがっているようです。
Re: DB換装 
投稿者: minahito | 投稿日時: 2006/1/18 11:21
minahito
引用:

という理解をしました。合っていますかね。

ですね〜、ただプリロードという機能を使って $xoopsDB を作っておけば、MySQLに限り、旧モジュールのDB関係もそのまま通るとか、色々な(個別の)解決方法があるかもしれません。

引用:

XC2.1対応のモジュールに関しては開発フレームワーク(というと大げさですが)というか、ガイドラインが要りそうですね。

そうですね、旧関数はラッパーで動くところがありますが、新概念に書き直して貰った方がよくマッチするところがあり、そのあたりは情報をまとめなくてはいけないと思ってます。ぜひ皆さんの御協力をお願いします。

引用:

onokazuさんは書きました:
PDOはPHP5ですよね。XCにてPHP5必須にするのはまだ少し
早いかなと思います。結果として流れに遅れてしまうのも怖いですが、、

このあたり、実際どうなんでしょうか。サーバーと一緒に納品するような業務でPHPを触っている人はPHP5なんだろうと思いますが、我々のようなエンドユーザーの動作環境でいうと、まだ普通にPHP4を使っているという印象です。

引用:

ただ、Propel等もそうですが、多くの優れたオブジェクト・リレーショナル・
マッパー(ORM)がPHP5であるのには悩みどころですね。

そうですね、数が多くて選ぶのも悩みそうです。世間的な評価は sitepoint などで集めればいいのかな...

できれば、DB非依存の形も定義できるタイプのORMが嬉しいですね。まあ、それは、XoopsObjectのようなレイヤーを1枚かぶせればいいだけの話か……
XoopsObjectはハンドラが浮いていて、いわゆる「俺ライブラリ」ではあるが、Xoopsにおいてはコモンライブラリなので僕は意外と便利に使ってます。


// タイムゾーンリストにアクセス
$handler =& xoops_gethandler('timezone');
$timezones =& $handler->getObjects();
$timezone =& $handler->get($user->get('timezone_offset'));

ハンドラさえ実装すれば、相手がメモリバッファでもDBでもファイルシステムでもソケットでも関係なくアクセスできる精神が好きです。ハンドラ定義は別に自動で書き出しちゃえばいいし……
そういう意味では XoopsObjectHandler が完全抽象クラスなのは良かった。あれがSQL生成機能を少しでも積んでいたら、SQLべったりになっていたと思うので。
XoopsObject/Handlerはリソースへの依存性がないので、ファイルを読むときとデータベースを読むときにコードをまるきり変える必要がないのがいいと思ってます。リソース依存部を継承クラスで書く必要はあるものの、機械に吐かせりゃいいわけですし……

CriterionクラスがSQLにべったりなのを少し弄れば(判断条件のみを情報として保持するオブジェクトとすれば)、Legacy モジュールが現役のうちは十分延命できると思ってます。
こういう使い方も差し込めるORMがあれば嬉しいですね。
Re: DB換装 
投稿者: onokazu | 投稿日時: 2006/1/18 17:07
onokazu
引用:

minahitoさんは書きました:

CriterionクラスがSQLにべったりなのを少し弄れば(判断条件のみを情報として保持するオブジェクトとすれば)、Legacy モジュールが現役のうちは十分延命できると思ってます。
こういう使い方も差し込めるORMがあれば嬉しいですね。


そうですね、XoopsFormもそうですが、CriteriaやXoopsForm自身がrenderする
のではなく、これらを使用する側がVisitorパターンでCompositeの中の情報を用途に
合う形で収集構築できるようにするのが1つの手かと思います。
Re: DB換装 
投稿者: minahito | 投稿日時: 2006/1/18 17:50
minahito
引用:
そうですね、XoopsFormもそうですが、CriteriaやXoopsForm自身がrenderする
のではなく、これらを使用する側がVisitorパターンでCompositeの中の情報を用途に
合う形で収集構築できるようにするのが1つの手かと思います。


はい、これは別所でも話ありましたけど、まさにこの形がいいですね。XoopsForm はそれでテンプレート化できると思います。
Re: DB換装 
投稿者: puchi | 投稿日時: 2006/1/18 19:48
puchi
引用:

私にはやはりインタープリターが必要のようです。


すみません。僕もあんまり詳しくはわからないのですが、僕の認識だと
既にあるXOOPS系モジュールをOracleなど各種に対応するのは現実的に難しい。各モジュールごとに個別に対応していかなくてはいけないと思います。
XOOPS内部だけとか今までの標準モジュールだけとかなら、なんとかなるかも知れませんが、あまりやりたがる人もいないような気がします。
以前、PostgreSQLに対応したという記事を見た記憶がありますが、それっきり見ないですね。

なのでこれから開発するものはどのDBでも動くものだといいですよねー。
どのDBで動くにはどうするのがいいかな?
という話しだと思います。

#個人的にはMySQLだけで満足だったり。
Re: DB換装 
投稿者: puchi | 投稿日時: 2006/1/18 19:59
puchi
引用:

PDOはPHP5ですよね。XCにてPHP5必須にするのはまだ少し
早いかなと思います。結果として流れに遅れてしまうのも怖いですが、、
ただ、Propel等もそうですが、多くの優れたオブジェクト・リレーショナル・
マッパー(ORM)がPHP5であるのには悩みどころですね。


PDOは、PHP5で利用できて、PHP5.1で標準装備ですね。
XC3でもまだ早いかも知れませんね。
最近でてくるORMやらFrameworkはほとんどPHP5必須なので確かにどっちベースで開発するかは悩みますね。

PHP4でORMというと、PEAR::DB_DataObjectですかね。
遅いという評価が多いですけど。

各DBに対応するという意味では、adodbですかね。
こちらは早いし、対応DBも多いですが、ORM的な使い方はできないようです。

adodbでORM的な使い方している人いませんかね?

Re: DB換装 
投稿者: dolitle | 投稿日時: 2006/1/18 20:05
dolitle
こんにちは。

他のDBにも対応できると良いでしょうね。
WEBではMySQLが多いのでしょうが。

イントラに導入の際にオラクルやポストグレスがすでに入っていることが多くありますよね。

PostgreSQLで一時試してみたことも有りましたが、今はどうでしょうかね。
Re: DB換装 
投稿者: pgsqler | 投稿日時: 2006/1/19 0:59
pgsqler
stone_heartさん宅にて細々とPostgreSQL対応版の公開をさせて
いただいております。

いちおうこちらで公開されている最新バージョンに対応したパッ
ケージ(リンク)を公開させていただいております。最近はバージョ
ンアップがcube公開に向けてアングラに潜った(汗)ため、もっぱ
らモジュールのPostgreSQL対応が一番のネックになりつつありま
す。

モジュール作成者の皆さんがxoopsDBクラス使ってくださると多少
ですが楽になるんですけれどね(汗汗)
Re: DB換装 
投稿者: minahito | 投稿日時: 2006/1/19 12:34
minahito
引用:

PHP4でORMというと、PEAR::DB_DataObjectですかね。
遅いという評価が多いですけど。

各DBに対応するという意味では、adodbですかね。
こちらは早いし、対応DBも多いですが、ORM的な使い方はできないようです。


ADO は ORM としての性質より、 SQL クエリのためのラッパーという印象が強いですから、 ORM 的に使うには一枚噛ますんでしょうね。
ADO はインターフェイスがその名の通り ADO ベースなので、そこは共通項になってよさげですよね。

> pgsqler さん
引用:

いちおうこちらで公開されている最新バージョンに対応したパッ
ケージ(リンク)を公開させていただいております。最近はバージョ
ンアップがcube公開に向けてアングラに潜った(汗)ため、もっぱ
らモジュールのPostgreSQL対応が一番のネックになりつつありま
す。

モジュール作成者の皆さんがxoopsDBクラス使ってくださると多少
ですが楽になるんですけれどね(汗汗)


げげっ
xoopsDB クラスを使わないケースってありますか?(滝汗
mysql_xxxx で直繋ぎする感じですか?;;

マルチDBをするには、テーブル作成などは別途スキーマを使わなくてはならないと思いますが、たとえば自動コード生成ツールなどで、これを気を付けておけば posgre 版が楽だ!みたいなのはありますか? よく言われるのが auto_increment ですが…… auto_increment を DB との接着剤にあたる XoopsHandler(XoopsGenericHandler) あたりが把握しておく必要がありそうでしょうか?

本当にマルチDBになるのはまだ先で、本体にパッチ当てる作業がどうしても今は必要になるので、そのパッチ作業が最低限で済む構造とコード生成が抜本的に現姿勢を変えずに仕込めるようなら、対応考えようと思います。
Re: DB換装 
投稿者: wintermute | 投稿日時: 2006/1/19 22:30
wintermute
adoを使う方法は、XOOPS1の時にやった覚えがあります。
XOOPS2になってからは、よりmysqlに依存した部分が多くなったのでやってませんが・・・
(それに、以前遅いとか言われたんだっけ)

>xoopsDB クラスを使わないケースってありますか?(滝汗
protectorで、スピードが遅くなるって理由で直にmysql_queryを直に発行しているような箇所がありましたよ。

過去に何度かxoopsをpostgresに対応させてみた時の感じからすると、多数のデータベースに対応する際にネックになるのは、
1.insert時のidをどう取得するか?
2.時間の扱い方
の2つじゃないかな?

いっその事、dbという概念が無くなって、全てxoopsObjectを使う、という事になると楽になるんですが・・・
(って、結局xoopsObjectの内部でdb使う事になるのか。。。)
Re: DB換装 
投稿者: pgsqler | 投稿日時: 2006/1/19 23:07
pgsqler
>minahitoさん
引用:

げげっ
xoopsDB クラスを使わないケースってありますか?(滝汗
mysql_xxxx で直繋ぎする感じですか?;;


ときどき極々普通に mysql_xxxx を使って記載されているのに出くわします。こうなるともう大幅な書換えと言うか書き直しが必要になるので、よっぽど「意地でも使うんだ!」とならないかぎり断念してます。

引用:

マルチDBをするには、テーブル作成などは別途スキーマを使わなくてはならないと思いますが、たとえば自動コード生成ツールなどで、これを気を付けておけば posgre 版が楽だ!みたいなのはありますか? よく言われるのが auto_increment ですが…… auto_increment を DB との接着剤にあたる XoopsHandler(XoopsGenericHandler) あたりが把握しておく必要がありそうでしょうか?


auto_increment…見付けたときは泣けてきます(笑)。まぁPostgreSQLもSERIAL/BIGSERIAL使う段階でドッチモドッチと言う噂もあります。そう言う意味で把握してもらえるor単なるINTでカウンタ管理してもらえると非常に助かります。

対処用にgenID()が準備されていますが、mysqlは0を返すだけのクラス関数であるため引数を渡さないコーディングや引数として欲しい値が渡されない(例えば kernel/tplfile.php)場合とか…
# getInsertID() も同様。

新しいバージョンが公開されると genID と getInsertID を grep しまくる習性が身につきました

それ以外のスキーム関係ですと

【型周り】
(1)binary→存在しないので状況に応じて型変更が必要
(2)INT周り
a)UNSIGNED
b)INTの種類そのもの(→PostgreSQLはSMALL INT2/INT4/INT8)

(3)CHARで桁数指定してるのに溢れた値をINSERTで挿入しようとする
(4)date(だったかな?)。他の値を更新すると自動的に現在時を入れるため TRIGGER を組まないと対処できない


【テーブル属性】
「type=ISAM」などのテーブル属性(見なかったことにしてます)

【QUERYそのもの】(かなり痛い。地雷源そのもの)
(1)SELECT
a)SELECT * FROM XXX GROUP BY a;
→PostgreSQLは集約対象あるいは集約関数(COUNTとか)以外を指定(*)すると駄目です。

b)LIMIT/OFFSETの違い
→これはxoopsDBクラスで対処されていますが、ほとんど利用されていません

(2)とあるモジュールで「INSERT xx SET a=v1,..」と出てきたときにはのけぞりました(汗)


…くらいかな(汗)。他にもあったような気もしますが、上記のようなトラップがあるので記憶から消えさってしまってます

PostgreSQLでxoopsと言うのも(隠れ)需要は多いと思うので、なんとかwrapper(クラス)で違いを集約できれば良いんですけれどね。

以上、長文・駄文ですいませんでした m(_ _)m
Re: DB換装 
投稿者: puchi | 投稿日時: 2006/1/20 2:02
puchi
このスレッド、非常に勉強になります。

引用:

wintermuteさんは書きました:
adoを使う方法は、XOOPS1の時にやった覚えがあります。
XOOPS2になってからは、よりmysqlに依存した部分が多くなったのでやってませんが・・・
(それに、以前遅いとか言われたんだっけ)


これは、ADOdbを使ったら遅くなったという意味でしょうか。
ADOdbってキャッシュが使えたりするので、アクセスごとに毎回読むようなDBアクセス(例えばconfig系とか)に対しては、むしろ早くなるののでは?と思ってましたけど、間違った認識ですかね?

ちなみにこんな風
$DB->GetRow($statement4sql); // normal
$DB->CacheGetRow($statement4sql); // cache

あと、C言語で書かれたADOdbのextensionもあるのでもっと早くしたいというエンタープライズ向けの方には効果もあるかなぁと思ってました。

ADOdbを採用しているWebアプリって結構有名どころがいますよね
ACID, PostNuke, Xaraya, phpWiki, Mambo, PHP GACL, TikiWiki, eGroupWare, phpLens App Server

で、zen-cartもADOdbを使っていたのを、最近やめることにしたと思ったのですが、なんでか知ってる方いますか?
Re: DB換装 
投稿者: onokazu | 投稿日時: 2006/1/20 9:05
onokazu
Adodbは良いと思うのですが、Smarty同様、実行時に読み込むファイル容量が
大きくなり、サーバリソースを大きく消費するということでXOOPSへの導入は
敬遠した覚えがあります(Smartyに関しては、確か当時の開発者やユーザ側から
かなりのリクエストがあったので採用することになったと思います)。

最近はどうなんでしょうか。ある程度改善されているのかもしれないですね。
また、開発者は元のAdodbとは違いますがAdodbの軽量版であるAdodb Liteといのも
出ていたと思います。

Re: DB換装 
投稿者: minahito | 投稿日時: 2006/1/20 12:41
minahito
> wintermute さん
引用:

いっその事、dbという概念が無くなって、全てxoopsObjectを使う、という事になると楽になるんですが・・・


XoopsObjectをモジュール開発者に強制することは厳しいのですが、X2におけるコモンライブラリでもあるので、いまソースコード生成はそれでやってます。この生成ツールが多少なりとも新規開発者の間で使われるかもしれないと期待すると、このツールが吐くコードの段階である程度 posgre の $xoopsDB で解決できるような形にしておけばいいのかな、と思いました。

つきつめると ORM までいってしまうので、現段階だとその程度かな……と思います。移行すべて、コア機能ではなく生成ツールを使う開発者に対して生成コードで誘導するという前提の話ですが、

> pgsqler さん
引用:
auto_increment…見付けたときは泣けてきます(笑)。まぁPostgreSQLもSERIAL/BIGSERIAL使う段階でドッチモドッチと言う噂もあります。そう言う意味で把握してもらえるor単なるINTでカウンタ管理してもらえると非常に助かります。


これは auto_increment の有無にかかわらず insert 前にプライマリの ID を別途メソッドから取るコードにします。mysql + auto_increment のときは何も処理しない形にすれば mysql 準拠体質の X2 で余計な処理扱いされることもないと思います。

引用:

(1)binary→存在しないので状況に応じて型変更が必要


こっちも非推奨 (^^;

引用:

(2)INT周り
a)UNSIGNED
b)INTの種類そのもの(→PostgreSQLはSMALL INT2/INT4/INT8)


これは大丈夫かな……

引用:

(3)CHARで桁数指定してるのに溢れた値をINSERTで挿入しようとする


これも生成ツールと XoopsSimpleObject を組み合わせる限りは大丈夫のはず。

引用:

(4)date(だったかな?)。他の値を更新すると自動的に現在時を入れるため TRIGGER を組まないと対処できない

これは生成ツールでは XOBJ_DTYPE_INT の initVar や ActionForm::updateで値を入れることを推奨しているので問題なしか?

引用:

【QUERYそのもの】(かなり痛い。地雷源そのもの)
(1)SELECT
a)SELECT * FROM XXX GROUP BY a;
→PostgreSQLは集約対象あるいは集約関数(COUNTとか)以外を指定(*)すると駄目です。


これなんですが……
僕自身がSQLを知らないので(基本構文しかしらない)、新たに追加された SQL や生成ツールが生成する SQL はすべて標準 SQL だと思います。
ただ、XC21 で、「グループに属してないユーザー」を1発で取得するために、 Marijuana さんにおねだりして作ってもらった超ドギツイのが計二発入ってます。(count かそうでないかの違いですが)
XoopsMembershipHandler::getUsersByNoGroup() ですが、


$sql = "SELECT u.uid FROM ${usersTable} u LEFT JOIN ${linkTable} g ON u.uid=g.uid," .
       "${usersTable} u2 LEFT JOIN ${linkTable} g2 ON u2.uid=g2.uid AND g2.groupid=${groupid} " .
       "WHERE (g.groupid != ${groupid} OR g.groupid IS NULL) " .
       "AND (g2.groupid = ${groupid} OR g2.groupid IS NULL) " .
       "AND u.uid = u2.uid AND g2.uid IS NULL GROUP BY u.uid";


こんな感じ。
getUsersByNoGroup($groupid, $limit=0, $start=0)
なので、
要は $groupid = 1 だったら 1 に属してないユーザーの XoopsUser オブジェクト配列が帰ってくればよいから、分解すれば何とかなると思うのですが、このサイトとかユーザー2万とかいるから、DBに計算させないときついかな……というのがありました。
特にこれの count 版とか。

引用:

b)LIMIT/OFFSETの違い
→これはxoopsDBクラスで対処されていますが、ほとんど利用されていません


これはクエリーの第二、第三パラメータに渡せばOKですよね?


> onokazu さん
引用:

Adodbは良いと思うのですが、Smarty同様、実行時に読み込むファイル容量が
大きくなり、サーバリソースを大きく消費するということでXOOPSへの導入は
敬遠した覚えがあります


このあたり、ado本体が改善してくれてるかもしれないという他に、時代が変わってサーバーリソースにみるシビアさも変わっているところもあるので(条件がよくなってきているはず)、そのことも考慮に入れられるかもしれませんね。
Re: DB換装 
投稿者: wintermute | 投稿日時: 2006/1/20 16:47
wintermute
>これは、ADOdbを使ったら遅くなったという意味でしょうか。
すいません。実は、旧xoopsのフォーラムで書いた時に、onokazuさんに言われた事だったのですが、
上でonokazuさんが書かれているように、遅いでは無くて重いの間違いだったみたいですね(^^ヾ

>ADOdbってキャッシュが使えたりするので、アクセスごとに毎回読むようなDBアクセス(例えばconfig系とか)に対しては、むしろ早くなるののでは?
うちだと、社内で使っていて結構更新が多いので、むしろ毎回ファイルに書き込む動作が加わるcache系は遅くなるかな?と思って使っていません。
(実際に測定した訳ではありませんが^^;)
(ってか、更新多い場合、cacheが下手に残るとデータの不整合が起こりえますから、キャッシュを持つのは、データの更新などの情報を持っているデータベース側でやるのがベストなのでは?と私は割り切っています。)

>pgsqlerさん
>(2)とあるモジュールで「INSERT xx SET a=v1,..」と出てきたときにはのけぞりました(汗)
ム?記憶が曖昧だけど、どこかで見た覚えがあるような・・・
確か、mysqlではこの書き方でも通ってしまうから、間違いに気づきにくいんですよね^^;
Re: DB換装 
投稿者: pgsqler | 投稿日時: 2006/1/21 1:25
pgsqler
長文・乱文で場を乱してすいません m(_ _)m

>minahitoさん
引用:

これは auto_increment の有無にかかわらず insert 前にプライマリの ID を
別途メソッドから取るコードにします。mysql + auto_increment のときは何も
処理しない形にすれば mysql 準拠体質の X2 で余計な処理扱いされることもな
いと思います。


期待したいのは山々なのですが、「何もしない」と言うのはある種の危険を
ともないます。前述の通り、mysql は何もしないで済むために引数が正しく
なくてもスルーしちゃうことがあります。実際現コア部にもその問題が含ま
れてしまってますから。こればっかりはしかたがないとは思います…

引用:

>(4)date(だったかな?)。◆以下略◆
これは生成ツールでは XOBJ_DTYPE_INT の initVar や ActionForm::updateで
値を入れることを推奨しているので問題なしか?


不勉強で申しわけありません。名前から想像するに「日付フィールドの更新」
に見えますが、その理解で正しいでしょうか?仮に正しいなら\(^^)/
です。もし勘違いとかだとすれば orz...

その場合はかなり乱暴な方法になりますが、DATE(?)は決められたカラム名
しか利用禁止!にしてカーネルインストール時に共通TRIGGERを埋め込む…
# 自分で書いておいてなんですが、無茶苦茶すぎる ^^;

引用:

>(1)SELECT
>a)SELECT * FROM XXX GROUP BY a;
>→PostgreSQLは集約対象あるいは集約関数(COUNTとか)以外を指定(*)すると駄目です。

これなんですが……
僕自身がSQLを知らないので(基本構文しかしらない)、


【良い例】
SELECT a FROM tbl GROUP BY a;
SELECT count(*),a FROM tbl GROUP BY a; ← count(*)以外にmax(b)とかもOK

【駄目な例】
SELECT * FROM tbl GROUP BY a;
SELECT a,b FROM tbl GROUP BY a;
→この記法は数多くのモジュールにて使われています。 orz...


引用:

新たに追加された SQL や生成ツールが生成する SQL はすべて標準 SQL だと思います。
ただ、XC21 で、「グループに属してないユーザー」を1発で取得するために、 Marijuana さん
におねだりして作ってもらった超ドギツイのが計二発入ってます。(count かそうでないかの違
いですが)XoopsMembershipHandler::getUsersByNoGroup() ですが、

$sql = "SELECT u.uid FROM ${usersTable} u LEFT JOIN ${linkTable} g ON u.uid=g.uid," .
"${usersTable} u2 LEFT JOIN ${linkTable} g2 ON u2.uid=g2.uid AND g2.groupid=${groupid} " .
"WHERE (g.groupid != ${groupid} OR g.groupid IS NULL) " .
"AND (g2.groupid = ${groupid} OR g2.groupid IS NULL) " .
"AND u.uid = u2.uid AND g2.uid IS NULL GROUP BY u.uid";


こんな感じ。


うっキツ(汗)。ちょっと試してみます…大丈夫でした。

引用:

要は $groupid = 1 だったら 1 に属してないユーザーの XoopsUser オブジェクト配列が帰って
くればよいから、分解すれば何とかなると思うのですが、このサイトとかユーザー2万とかいる
から、DBに計算させないときついかな……というのがありました。
特にこれの count 版とか。


前述の通り、GROUP BY利用時の抽出カラムにGROUP BYで集約対象としたカラムか
集約関数を指定している分には問題となりませんので大丈夫だと思います。


引用:

>b)LIMIT/OFFSETの違い
>→これはxoopsDBクラスで対処されていますが、ほとんど利用されていません
これはクエリーの第二、第三パラメータに渡せばOKですよね?


大丈夫です。そう言う意味ではxoopsDBクラスも正しく使えば問題は少ないので
すが、気がつかずに生で実行していると宝の持ち腐れとなります。

実際いくつかのモジュールでLIMIT/OFFSETが生クエリに埋めこまれていました。
# そして画面が真っ白を何度となく体験してました

>wintermuteさん
引用:

>(2)とあるモジュールで「INSERT xx SET a=v1,..」と出てきたときにはのけぞりました(汗)
ム?記憶が曖昧だけど、どこかで見た覚えがあるような・・・
確か、mysqlではこの書き方でも通ってしまうから、間違いに気づきにくいんですよね^^;


「mysqlではこの書き方でも通ってしまう」。この言葉に尽きるんですよね。
mysqlでは正しい構文でも他のDBMSでは正しくない構文と言うのは(mysql環境で
開発する以上)見付けられませんから。もちろんその逆パターンもありますけれ
どね。

と言うことで人柱確定かな>自分

投票(0)

新しいものから | 古いものから | RSS feed
 
To Top