アカウント名:
パスワード:
だいたい、なんだかんだいってWindowsも10年以上あーだこーだやってきてやっぱり運用はまだまだ大変なのに、これがオープンソースになったら安くなる、とはとても考えにくい。導入費用の安さだけで見てないかな？
サーバがオープンソースだと安く済む、というのは感覚的に納得するんですけどね。Microsoftの"CAL"の概念は頭では理解できても感覚的に納得いかない物があるし。 それにサーバだけだったらクライアントほど台数はないから、少々技術的に扱いが難しい物入れても泣くのは少数の担当者だけで済む（＾＾；し。
特にAccessの代わりがないのでデータベースを自作して業務を行っているような場合、致命的。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
ホントかなぁ？ (スコア:1, 興味深い)
オープンソース製品を管理運用するのは、一部のアプリケーション製品などの例外を除いて技術力がいる様に思うから、逆に面倒になるのではないですかね。
だいたい、なんだかんだいってWindowsも10年以上あーだこーだやってきてやっぱり運用はまだまだ大変なのに、これがオープンソースになったら安くなる、とはとても考えにくい。導入費用の安さだけで見てないかな？
サーバがオープンソースだと安く済む、というのは感覚的に納得するんですけどね。Microsoftの"CAL"の概念は頭では理解できても感覚的に納得いかない物があるし。
それにサーバだけだったらクライアントほど台数はないから、少々技術的に扱いが難しい物入れても泣くのは少数の担当者だけで済む（＾＾；し。
保守を考えたら (スコア:3, 興味深い)
止められない業務に必要なRASISの水準を考えたら、WindowsやUNIX、Linuxより結果的にメインフレームやミニコンの方が安いような気がしますね。まぁ、将来性とか拡張性を考えたらIBM製品限定ですが・・・。
そこまで求められない（数時間止まっても良いような部門システム）なら、OSSを利用するのはライセンスのことを考えるだけでも十分価値があると思います。なかなか必要な数のライセンスを揃えるのが難しいし
Re:保守を考えたら (スコア:0)
業務で使うのは絶対にやめてほしい。
PostgreSQL や MySQL を使おうよ。
pgAdminIII [pgadmin.org]とかphpMyAdmin [sourceforge.net]とかGUIで操作するソフトも揃ってるから大丈夫でしょ。
Re:保守を考えたら (スコア:1)
まるで駄目。
ACCESSは単に"ＤＢ"として利用されるわけではなく
簡易APを構築するためのフロントエンドとして利用されてるのです。
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
Re:保守を考えたら (スコア:0)
業務用なら Rails で簡単に専用アプリを組んでしまうのがオススメだろう。
MS Access に固執する意味がわからない。
見識が狭いんじゃないか？
MS Access は他と比べると大して使いやすいもんじゃないぞ。
Re:保守を考えたら (スコア:0)
＞業務用なら Rails で簡単に専用アプリを組んでしまうのがオススメだろう。
あ、ありえねぇ～！
どういう見識だよ。ネタで言ってるんだろ？そうだと言ってくれｗ
しかもRails関係ねぇ～ｗ
Re:保守を考えたら (スコア:0)
ぐぐる [google.co.jp] といくらでも情報でてくるぞ。
確かに最近よく話題にあがる。
なかなか評判も良いらしい。
簡単にDBアプリが組めるそうだ。
# 業務で Access はありえないだろと思うのでAC
"業務"がわかってない。 (スコア:3, すばらしい洞察)
Accessはある程度PCリテラシーの高い人が、手元の定型業務を効率化するために
忙しい最中ぽちぽちと組んだツールを使ってるケースが非常に多い。
システムリプレイス案件では往々にして、
そうやって作ってきたツールの機能を新システムに組み込む要望がかなりでてくる。
そういう人々にとって、データテーブルが何に乗っかっているかは二の次で
オフィスに最初から存在し、普通にインストールすればほぼ確実に動作し、
マウスでぽちぽちとUIもクエリも組めて、結構強力なマクロと一通り日本語化された
開発環境もついていて、何よりそのユーザー数ゆえから膨大な量の参考情報が
日本語で入手できるAccessに勝るものは現状ないのです。
Ruby On Rails？
あなたがつかえるから、他人も仕事に使えるわけではないのです。
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
Re:"業務"がわかってない。 (スコア:-1, フレームのもと)
ユーザーが多ければ情報が多い、とは限らない。
Access VBA [google.co.jp] の検索結果 約 8,400,000 件中 1 - 10 件目 (0.04 秒)
Ruby On Rails [google.co.jp] の検索結果 約 25,800,000 件中 1 - 10 件目 (0.26 秒)
Re:"業務"がわかってない。 (スコア:1)
どっちが喰いつきやすいか判断つかない？
検索結果の先頭はそれぞれ
「Hotwiredからのお知らせ : Hotwired」
と
「Access_VBA講座」
でしょう。利用者が望む情報に、どちらがアクセスしやすいと思うのかな？
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
Re:"業務"がわかってない。 (スコア:0)
HotWired Japan は残念ながら閉鎖されたようだが、
その下の「IBM dW : linux :Ruby on RailsによるWebアプリケーションの高速開発 ...」は非常に良質な記事だ。
「Access_VBA講座」は、ざっと読んでみたが、内容がどうも古くさい。
MSの急な方針転換(.NET化)についていけてないんじゃなかろうか。
Re:"業務"がわかってない。 (スコア:1)
先に述べたように手元でごちょごちょを定型化している人が多いので
Access使いには.NETなど関係ないのです。
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
現場に密着した開発を指向するという共通点 (スコア:1)
Access の背景にある「エンドユーザ開発」という考え方と、
Ruby on Rails と親和性の高い「アジャイル開発」という発想とは、
違いよりも共通点の方が多いのです。
前者は、いちばん業務を分かっている立場であるエンドユーザが
便利な開発ツールの助けを借りて自力でシステム開発しようということ。
後者は、プロの開発者が現場に密着して、エンドユーザの意見が
いつも得られる環境でシステム開発しようということです。
いずれも、エンドユーザが要らないと思うような無駄な機能を開発しない、
ということが大きなアドバンテージの源泉です。ただし、上質なプロの開発者は、
機能が少なくて済む分だけ構造上もシンプルなソフトウェアに仕上げることが
期待でき、保守や拡張のコストが抑え易くなります。
それに対しエンドユーザ開発の場合は、不要な機能こそないものの
システムとしての「エントロピー」が増大してしまい、拡張要望に対して
お手上げになったり、作った人でなければ保守できない状態に陥ることが
ままあります。(責任の一端は、とっつき易いけれども後々の保守拡張を
あまり考えていないエンドユーザ開発ツールが負うべきです。)
いずれの方法を取るにしても、ヨソの会社(あるいはヨソの国)にいる
プロの開発者に頼んだあげく、アサッテな機能満載のソフトウェアを受け取って
途方に暮れがちな従来型の開発委託に比べて、将来性のある手法だと思います。
Re:現場に密着した開発を指向するという共通点 (スコア:1)
きれいにまとめていただいてますが、開発手法の問題ではないのです。
OSSにおいて、古くはdbase、現在はAccessがその地位を占める
｢エンドユーザ開発ツール」が不在であるのが問題なのです。
これがこのスレッドの最初に述べられている意見です。
Baseがあるというご意見もありますが、
エンドユーザが必要とするHOWTOの蓄積において決定的に劣ります。
個人的にはAPとしての完成度もまだ不足していると感じています。
またDBとしての素性の差でPostgreSQL、MYSQL、
開発ツールとしての素性の差でRuby on Railsなどを持ち出されても、
それらは「エンドユーザ開発ツール」にはなりえません。
DB+Webサーバ+ミドルウェアの構築を行うだけで
エンドユーザは息切れしてしまいます。
ましてその運用保守に時間を割いていられないのが実情です。
過去においてDbase対抗の製品はいくつもありましたが、
皆主流とはなり得ませんでした。
Accessが主流になりえたのはDbaseが過去の資産にとらわれてWindows移行に失敗したため。
まがりなりにもMSが無印から2003までサポートを続けているためです。
これに置き換わろうとするのは一朝一夕では到底無理な話です。
ツールとしての素性の良さだけでは、勝ち目がありません。
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜