Hiroaki Sakuma
hiroa****@sakum*****
2005年 3月 22日 (火) 00:48:06 JST
佐久間です． > > 手軽に設置できる，ということからは遠ざかるかもしれませんが，RDBMSとの連携 > > は > > どうでしょうか． > > 大規模になってくると，MySQLなどで管理できると便利だと思うことがあります． > > 特に，パーミッションの設定などで手間取るくらいなら，MySQLの方が簡単なこと > > も > > 多いです． > > 最近のレンタルサーバではMySQLやPostgreSQLが提供されていることが多いですし > > ， > > コントロールパネルなどでDBの作成などもできるので，ユーザにとっては敷居が > > 下が > > るかもしれません． > > # 自分でサーバを構築されている方には手間が増えるかも > > > > DBとのインターフェイス部分は独自に実装しておいて，プラグインのような形で， > > MySQL/PostgreSQL/BerkleyDBなどを切り替えれると便利ですね． > > > > こういうDBを用意できない人のために，性能を犠牲にしても，最低限の設定で動く > > CSV+ファイルなどを使った独自のストア方法も用意しておくという手もあります． > > 個人的には、FSWikiのPerlのみで動作する、ところに魅力を感じています。 > 強制的に強いられてしまっては魅力が半減してしまいます。 > DBI等を使って、CSV形式でも可（ベースはこれ、設定で切り替え可が理想）、 > とするこの案なら賛成です。 私も昔はPerlのみで動く，とかを凄い気にしてソフトウェアを書いていたのですが， 最近のレンタルサーバでのRDBMSの普及と，設定ツールの提供が増えたおかげで，下 手にPerlだけにこだわって設置であれこれいじるより，用意されているDBを使うよう にツールを設置した方が楽，と思うようになってきました． サーバを移動する際も，RDBMSならDBの内容をダンプして移動できますので，バック アップとかでも楽です． 最近，海外発のソフトウェア(XOOPS，osCommerce，Nucleusなど)が多く使われていま すが，いずれもRDBMSがバックボーンにあることで簡単に導入できるようになってま す．実はソフトウェアを書く側からしても，SQL構文だけでデータの管理が出来るの は，本来のソフトウェアのロジック部分に開発が集中できてメリットがあります． ベースがどれ，というより，インストールスクリプトでDBの選択をすればいい話だと 思います．DBIを使って，異DBでも共通の動作が期待できるメソッドだけを使って実 装すれば，どれがデフォルト，っていうことは考えなくてもいいと思います． ===================== Sakuma,Hiroaki hiroa****@sakum*****
Fork