最初は無償データベースにてライセンス差額分の初期導入コストをカットしておいて、その差額を他のサービスに振り向けたり値引きに使い、段階的な非常に大規模になってきたなあと思ったら MySQL や PostgreSQL のチューンや Oracle、MS SQL Server への乗り換えを「ライセンスのコストやサポートに関するリスク、今後のメンテナンスのコスト」を含めて判断する、というご時世らしいですね。「景気が低迷する中でもユーザー企業はIT投資をやめるわけにはいかない。」ってことで、コストに敏感なユーザーが多数派になってきたのでしょう。
Web 版の記事には「フリー・データベース」を使ったパッケージ一覧が省略されていますが、MySQL (表中では1種類)よりは PostgreSQL (表中で 10 種類前後? うろ覚え)を使ったパッケージが多い印象がありました。
フットワーク (スコア:1)
フットワークが軽いというのと、何よりもフリーというのが
大きいのでしょうね。重いくせに高い導入費用がかかり、
しかも不安定なRDBが以下に多いかということでしょう。
何も分からないSEがサポート漬けになって利用するならともかく、
それなりのインターフェイスを実装する技術力があれば、
躓いてもメーリングリストなり何なりで十分フォローできますしね。
私はPostgreSQLしか使ったことありませんが(笑)
初期段階の投資費用を抑えるのに有効? (スコア:2, 参考になる)
最初は無償データベースにてライセンス差額分の初期導入コストをカットしておいて、その差額を他のサービスに振り向けたり値引きに使い、段階的な非常に大規模になってきたなあと思ったら MySQL や PostgreSQL のチューンや Oracle、MS SQL Server への乗り換えを「ライセンスのコストやサポートに関するリスク、今後のメンテナンスのコスト」を含めて判断する、というご時世らしいですね。「景気が低迷する中でもユーザー企業はIT投資をやめるわけにはいかない。」ってことで、コストに敏感なユーザーが多数派になってきたのでしょう。
Web 版の記事には「フリー・データベース」を使ったパッケージ一覧が省略されていますが、MySQL (表中では1種類)よりは PostgreSQL (表中で 10 種類前後? うろ覚え)を使ったパッケージが多い印象がありました。
重さや安定さは...こればかりは問題が発生したとき、どれだけ現場の技術者でカバーできるか、ですかね。これは無償データベースであっても有償のデータベースであっても同じだと思います。
Re:初期段階の投資費用を抑えるのに有効? (スコア:2, 興味深い)
営業が客先に謝りに同行してくれる。システムのことを
さっぱりわからん客に対しては、こういうのは意外と大きい。
--rena
Re:初期段階の投資費用を抑えるのに有効? (スコア:2, 興味深い)
悲しい人間の性ですね。
こういうのを聞くと、なにしに俺たちゃ「技術」をやってんだろ?と空しい気分に襲われたりします。
みなさんは、そうなりませんか?
そんなに菓子折りが好きなら、プログラマじゃなく菓子屋を呼べよ、と。
Hackerが「なるほど(=理解した)」と言ったときには、もう(本人にとっては(笑))謝罪は済んでいるのだそうだ。
では逆に上記の状況では、謝罪を言ったときには、理解はもう済んでいる、ということにされているのかも知れない。
しかし、謝罪は気分の問題である一方で、技術はそうではない。
となると、Hackerの姿勢は意味がある姿勢だが、後者はどうだろう?かなり怪しいものではないか?
Re:初期段階の投資費用を抑えるのに有効? (スコア:2, 参考になる)
相手が問題とその原因、対応について理解できて、むろん
こちら側の体制に問題がなければ、当然「菓子折り」など
不要なんですが。
ただいくらシステム的に矛盾がなくても、プロジェクトが
遅れるのは頭にくるわけで。カットオーバも迫ってるし :^)
ま、全てが論理的に片づけられないというのの典型ですかね。
--rena
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
>/dev/null
Re:初期段階の投資費用を抑えるのに有効? (スコア:1, 参考になる)
ちょっと勘違いっぽい気も。
技術者ってのは顧客にサービスの提供を行って対価を得る「サービス業」なのでは?
つまり、顧客に「安心」を与えるのも仕事の内です。
社内だけで仕事をするペーペーの新米PGならともかく、社外でお客さんの相手
をするPGにはその辺りをきちんと認識して欲しい。
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
たしかにその通りですが、菓子折り(に比喩&象徴される色々な事柄)が、その任に耐えるのでしょうか?そこが疑問です。
ソフトで損ねてしまった安心を、挽回できる菓子って、どんな菓子なのでしょう?
存在し得るとは思えません。なにせそれは「オフトピ」なのですから。
お客がそう思い込んでいる物ならば「なんでも」いいのである、という考え方
(解釈の余地はそれしか有り得ないと思います)には、ちょっと人として同意に躊躇します。
菓子を持ってこいと言われたら菓子を持ってきますかね?
肩をもめと言われたら揉みますかね?
あるいは命じられるまでもなくそれらを「サービス(ここでは意味が違うけど、わざと使いましたm(__)m)」しますかね?
なにか違うと思います。
俺たちゃ本来は、技術でしでかしてしまった失敗は、技術でしか謝れない、と思う…
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
>/dev/null
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
と言ってみたら、どうなるのだろうか?
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
Microsoft のおかげ? (スコア:1)
そして百家争鳴のデータベース市場で、ODBC の旗を振ったのは、、、どこの会社でしたっけ?
コンタミは発見の母
Re:Microsoft のおかげ? (スコア:2, 参考になる)
ソースの互換性が取れていればいい案件ばかりやってたせいもあるけれど、ODBCってあんまり使わないような気も。言語サイドが提供するミドルウェアに比べると、やはり1枚余計なレイヤがかぶるような気がして。
乗り換えの簡便性に貢献しているというと、やはりSQLじゃないでしょうか。
Re:Microsoft のおかげ? (スコア:1)
SQL 書ける人間なら COBOL 書ける人間並みに その辺に転がってますから色々と コキ使い^H^H^H^Hやりやすいです。
# でも弊社の若手は SQL を知らない。
# 未だ ISAM が幅をきかす職場だから... (T_T)
Re:Microsoft のおかげ? (スコア:1)
副問い合わせすらほとんど使ったことないので深奥が伺いしれない。
-- wanna be the biggest dreamer
Re:Microsoft のおかげ? (スコア:1)
かなーり、複雑怪奇なSQLがいっぱいです。
全部マスタする必要はないでしょうけど、
テーブルが二桁数あるクエリとか、
副問い合わせが5個とか、
そういうのは業務でよく出てくるとおもいますが・・・
Re:Microsoft のおかげ? (スコア:2, 参考になる)
で、MS SQL Server 7.0 があっさりギブアップしてくれるので、困ってたりします。
DB 毎の「癖」を把握して、うまく対応しないと、複雑な SQL はきちんと動かないことも実感できますね。
たかだか、WHERE に IN を並べただけで、なんで落ちるんだぁ? > MS SQL Server 7
Re:Microsoft のおかげ? (スコア:1)
ドキュな開発やってるところでは、SQLといっても
(例えば)Oracle依存ばりばりなコードばっかり書いてるかも知れぬ罠。
まあそれはともかく、SQLも痛し痒しですね。言語仕様が汚いし。
あと、ODBCで楽をした記憶が無いのは、俺がWinでDBなクライアントといえば
Delphiでしかやったことがないせいでしょうかね?まあそうでしょうねBDE(ぉ。
Delphiはともかくとしても、JDBC(言語が限定されちまうけど)のシンプルさにビックリした後では
大抵(語弊?)のAPIを見ても心が動かなかったりする。あんな簡単に動いちまっていいの?って感じ。
Re:Microsoft のおかげ? (スコア:1)
例として「日時を表現するSQL文を書け」とかいう問題でも出せば
宜しいかしら?
# 論点がずれているかも(^^;;
Re:Microsoft のおかげ? (スコア:2, 参考になる)
ODBCドライバや関連ライブラリのバージョン違いに起因する動作の違いに泣かされた覚えがあります。
接続先DBMSはSQL*Server...やれNTのサービスパックだIEの新バージョンだと、ことあるごとにドライバのマイナーバージョンが変わって、そのたびに動作の違いを検証してMDACコンポーネント [microsoft.com]で強制的にバージョンを合わせて...苦労しました。
# MDAC2.1 位の頃です。最近は使ってないので分かりません
Re:フットワーク (スコア:1, すばらしい洞察)
> しかも不安定なRDBが以下に多いかということでしょう。
そんな悪いんじゃあみんなフリーを使いそうなもんだが。
でもね (スコア:2, 参考になる)
Oracleでも、Sybaseでも、なんでも使えばいいじゃない。
でも、ワシの仕事ではMySQLは当分使えん。色々と仕様が要件に合わ
ないんだよね。
Re:でもね (スコア:1)
>Oracleでも、Sybaseでも、なんでも使えばいいじゃない。
で、どれが適材か?という問題が厳然として残る、と。
もしかすると、技術的見地から比較して曖昧しか答えられないとき、
人はブランドを基準にして答え(らしきもの)を出そうとする、のかな。
余談:
あれ?最近のMySQLは、Transactionついたんでしたっけか?
Transactionの仕組みがDBについていると、お気楽プログラミングしたいときに、楽なんですよね。
#え?なんか使い方間違ってるって?(笑)
##更新矛盾とかエラーとかからの回復をするためのきちんとしたコードを自前で書くのは至極困難だ、という意味ですぅ。
Re:でもね (スコア:1)
大抵の顧客は技術的にはどうでもよくブランド(知名度)を要求するこ
とが多いという罠は確かに存在する。
Re:でもね (スコア:1)
MySQL-MAXでサポートされました。
Transactionは重いので、身軽が信条なMySQLはそのままです。
Re:でもね (スコア:1)
どの程度パフォーマンスが落ちるのか?という資料ってありますか?
いろいろ探してるんですけど、見つからないんですよね…。
Re:でもね (スコア:1)
アテにならなくてすんません。
Re:でもね (スコア:1)
Re:フットワーク (スコア:1, すばらしい洞察)
ある意味、ソフトウェアは、ブランド・ビジネス化しつつあります。
それが、ただ同然で手に入るLinux/GNUのCD-ROMが売れたり、OpenSSLで出せるにもかかわらずちゃんとしたCAから出た公開鍵証明書が使われたりする理由です。
昔のフリー・ソフトウェアは、ブランドがほぼ零に近かったかもしれないですが、今や、MySQL, Debian, Apacheなど、ブランド価値のあるフリー・ソフトウェアが、挙げればきりがないほど現われています。
iida
ブランドなるものの中身 (スコア:3, すばらしい洞察)
いったい何が達成できていれば買い手が「ブランド」と認識
してくれるのか、という点は掘り下げる価値があると思う。
技術屋さん自身は見逃しがちなことだが、企業にとって、君
と同じスキルを持った技術屋を雇い直すのは簡単なことでは
ない。君がいくらMySQLを使いこなせるといっても、君はいつ
か交通事故で死ぬかも知れないし、社長とけんかして辞める
かも知れない。そのときMySQLとやらに溜め込んだ会社の貴重
なデータを救い出せるという確信がなければ、理性のある企
業ならば決してMySQLを採用なんかしない。
OracleやDB2がエラいのは、そういう非常時に、金さえ払え
ば十分に有能な技術屋が来てくれるだろう、と企業が確信で
きるという点だ。誠に失礼な話だが、MySQLのサポートを提供
する会社があるとしても、いつまで続くか分からないような
会社しかないとしたら、MySQLにブランド力があるとは言えない。
Re:ブランドなるものの中身 (スコア:2, 興味深い)
MySQLの欠点と言われている事は、トランザクション、トリガ、ストアードプロセジャ、ビュー等の便利な機能が無い事ですね。トランザクションはどなたかも書かれておられるように、MAXでは利用可能です。ストアードプロセジャ、ビューもDBMSとすれば魅力的で便利な機能ですが、システム構築/運用的には脆弱点となりかねないのはご存じの通り。トランザクション、トリガについて言えば、それは何のペナルティも無しに利用できる機能では無い事を考えるべきでしょうね。また、トランザクションの目的と言われている一貫性のあるデータ更新も、場合によっては万全では無い事もまた基礎知識ですね。
実際に業務を分析したことがある方なら自明の事ですが、DB処理に占めるトランザクションの必要性には限りがありますね。そしてDBMSの実装に携わった事があれば、トランザクション処理というものがどれだけ重いのかは、これまた自明の事です。トランザクションが無いDBMSで一貫性のあるデータ変更を行う、これはある程度の基礎知識を持っているエンジニアには児戯に等しい事ですし、実装だってそう面倒な事ではありません。ですが、そういう基礎知識を持って居ないエンジニアには、至難となる事もあるでしょうね。
Oracle8.0.3/4/5に関して更に言えば、死ぬ程苦労した経験がありますね。行がなんかの加減で二重に出たり出なかったり、プライマリキーのフィールド名次第では結果がまったく返って来なかったり、阿呆なクライアントライブラリ+ProCのワケワカで簡単に数百MBのメモリを使うクライアントアプリケーションを量産出来たり、VBSとの相性も最悪だし、MySQLのクライアントライブラリなら非常に簡単な行をタグドデータに落とす事がOCIでは異様にステップを食って激烈に面倒だし、等々々々々。
天地の地の方のOracle使い(資格を持っているとしても)の典型としては、Oracle以外に選択肢が無い、があるでしょう。比較するものを全く知らないなら、当然比較することなぞ出来ません。ペーパーだけの比較でも意味が無いでしょう。相当使い込んでみて、始めて比較する事が可能になると思いますよ。単にメリットだけに注目するのでなく、総合的な評価を行うなら、便利だが重くて全体的に遅いDBMSと、軽くて全体的に速いが限られた処理を行う事に労力を使うDBMSとの取捨選択は、かなり悩ましい事になるはずです。
「それとも何か。人的コストは度外視ですか?」、単にコストのみを考えるプロジェクトマネジメントって簡単に破綻しません?
考えなければならないのはC/Pです。その辺の道端に転がってるにーちゃん、ねーちゃんを幾ら安い給料で大量に拾って来ても、何の役にも立たないと思いますよ。単なる馬力勝負の仕事なら給料が2倍の人が2人分の仕事が出来るというのは多分に誤りですが、スキル的となれば給料が半分の人が何千人束になっても1人に敵わない事はあるでしょう。失敗するプロジェクトマネジメントとは、頭数を加算的に勘定している、というのはあると思いますよ。トランザクションやトリガが無いDBMSで、それと同等の事を実現出来る程度の技術や知識を持った人が1人もいない、その様なプロジェクトは極めて打たれ弱いのでは、と思いますが。
Re:フットワーク (スコア:2, 興味深い)
ちゃんとしたCAから出た公開鍵証明書じゃないと、公的な場面ではあまり意味がないと思うけど。自分自身で署名した公開鍵証明書がオンラインショップで使われていたら、規模によっては胡散臭いし。ソフトウェアのブランドと言うより、そのCAに対するブランド意識だと思う。
とは言え、一番大きな理由はIEで初心者には意味不明なダイアログが出るかどうかの有無だと思うが。(w
Re:フットワーク (スコア:1)
あ、済みません。ここでソフトウェアと言いたかったのは、「CA製品」じゃなくて「公開鍵証明書」の方でした。ちゃんとしたCAが内部でOpenSSLを使っていようがいまいが、それはどうでもよかった。ソフトウェアとしての証明書のブランド・イメージです。
iida
Re:フットワーク (スコア:2, 興味深い)
きちんと性能、リスク、コストを勘案して、選択肢を最大限に広げるようになってきたのでしょうね。
あと、フリーソフトウェアであれば、試用コストも最小限で済むというのもあるかもしれません。
Re:フットワーク (スコア:1)
と言うより、普通ソフトウェアの使用許諾書で、「何があっても一切責任をとらない」
という旨が書いてあるはずです。
つまり、結局はiidaさんの言うようにブランドなんですよ。
Re:フットワーク (スコア:1)
あと、フェイズアウトが早すぎるという意見も。
みんなそれなりに、貧乏な時代なのだな。
Re:フットワーク (スコア:1)
> その理由は、「何か問題が発生した時の責任は?」と言うもの。
あのぉ・・・MySQLってサポートが受けられる [mysql.com]と思うのですが、これではクライアントが納得してくれないのでしょうか?
Re:フットワーク (スコア:2, すばらしい洞察)
オープンソースには難しいっすよ。多分。
結局、ブランドというのは「(自分がorみんなが)知っているものは信用できる」
という心に立脚します。しかも、このように考えるのは情報が少ないか、
情報の取捨選択をする能力がない場合です。
このような状況の人に周知するには、雑誌やTVでがんがんと広告を打つ必要が
あります。しかし、これは資金力だけがものを言う分野です。
#まぁ、オープンソース一般に関しては、IBMあたりが頑張ってくれる
#かもしれませんけど。DBは利害が対立してるからなぁ。
#自前ではDBを持たないSunに期待、ということにしときます。
Re:フットワーク (スコア:1)
> 名の知れた会社等のはっきりと目に見える責任対象が欲しいという事でしょうか?
あなたの会社が、全ての損害の責任を取る
と契約書に書けば、いくらでも通るのではないでしょうか?
マイナーな物を普及させるには、そのくらい精通していないと
しんどいんでしょうなぁ。
Re:フットワーク (スコア:1, 参考になる)
まぁ、明らかに個人ユースではありませんね。
Re:フットワーク (スコア:1)
# 個人的には何でもかんでも Oracle に
# 載せて ODBC 経由でつつきに行く的な
# 設計の流行には (X_X) なので、
# どちらかと言えば RDB を使うべきものと
# そうでないものとの適材適所を
# N経ソフトウェアみたいな「影響力のある」
# メディアが警鐘ならしてくれんかな~と
# 思ったり。
# ソースのバージョン管理なんか
# 生ファイルでやれや>某社製品
Re:フットワーク (スコア:1)
たしかオラクルは推奨してなかったと記憶しています。
(古いOracle8のマニュアルに「できればUNIX版を使え」って記述があったような…)
# テストプログラムを走らせる実験台には手頃でいいですね。NT版は。
notice : I ignore an anonymous contribution.
Re:フットワーク (スコア:1)
Work Group ServerにはUNIX版、WindowsNT版ともにあります。
あえて言うならLinux版も。
Windows2000Serverに対するWindows2000Professionalみたいなものですよ。
関係ないレス(レベルの低さについて) (スコア:1, 荒らし)
もうね、アフォかと。ヴァカかと。
お前らな、そんぐらいぐぐって調べろっつーんだよ、ヴォケが。
挙句の果てには#の後に書いちゃってるヤシまでいるし。
もう見てらんない。
某掲示板からスラド民がバカ扱い受けるのは当然だとオモタ。
ここは厨房の馴れ合い場か?こんなレベル低くていいのだろうか?
せめて最低限のことぐらいしてから来い。目障り。
Re:関係ないレス(レベルの低さについて) (スコア:1, おもしろおかしい)
これから土民って呼ばれそうな予感…
Re:関係ないレス(レベルの低さについて) (スコア:1, 参考になる)
> これから土民って呼ばれそうな予感…
ではスライムレベルの土民という事でよろしいでしょうか。
# そんな私も毎日 /. は欠かさない…
Re:フットワーク (スコア:1)
> 私にはMySQLとかPostgreSQLはツライっす。
??? どういう意味?
いや、おいらはOracle知らないので。
Re:フットワーク (スコア:1)
http://www.postgresql.jp/document/pg653doc/ej/user/sql-beginwork.htm
http://www.vce-lab.net/mysql-storage/faq.html#server
Re:フットワーク (スコア:1)
いや、おいらもそう思ったんですけど、OracleとかSQL Serverとかは知らないので、
OracleやMS SQLには、おいらの知らないトランザクションの機能があるのかなぁと思って。
Re:フットワーク (スコア:1)
# 本当はただの偏見だと思うけど。