最初は無償データベースにてライセンス差額分の初期導入コストをカットしておいて、その差額を他のサービスに振り向けたり値引きに使い、段階的な非常に大規模になってきたなあと思ったら MySQL や PostgreSQL のチューンや Oracle、MS SQL Server への乗り換えを「ライセンスのコストやサポートに関するリスク、今後のメンテナンスのコスト」を含めて判断する、というご時世らしいですね。「景気が低迷する中でもユーザー企業はIT投資をやめるわけにはいかない。」ってことで、コストに敏感なユーザーが多数派になってきたのでしょう。
Web 版の記事には「フリー・データベース」を使ったパッケージ一覧が省略されていますが、MySQL (表中では1種類)よりは PostgreSQL (表中で 10 種類前後? うろ覚え)を使ったパッケージが多い印象がありました。
どうも、IN 句に弱いようです、MS SQL Server7 は。
WHERE a IN (SELECT a FROM table1 WHERE ....)
OR a IN (SELECT a FROM table2 WHERE ....)
OR a IN (SELECT a FROM table3 WHERE ....) OR a IN (SELECT a FROM table4 WHERE ....)
OR a IN (SELECT a FROM table5 WHERE ....)
なんてのがあると、各 table に合致する要素が一つづつでも、あっさりこけてくれるので、頭が痛かったりします。
ちなみに、EXISTS に置き換えても駄目。
他には、 WHERE NOT b IN (SELECT b FROM table6 WHERE ....)
というのも、重いですね。これは、仕方がないかもしれませんが。
フットワーク (スコア:1)
フットワークが軽いというのと、何よりもフリーというのが
大きいのでしょうね。重いくせに高い導入費用がかかり、
しかも不安定なRDBが以下に多いかということでしょう。
何も分からないSEがサポート漬けになって利
初期段階の投資費用を抑えるのに有効? (スコア: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, すばらしい洞察)
>存在し得るとは思えません。なにせそれは「オフトピ」なのですから。
確かに「客を安心させる」って事に「技術的な」意味はありません。
が、営業を考えると重要ですよ。
というよりも、自分が客の立場になって考えると簡単な問題では?
技術が無いから仕事を出しているってのにトラブル時に
『技術無い様を云々し客に技術への理解を求める処』
と、
『素直に謝罪をしてくる処』
技術レベル
が同じならば、顧客は後者を選ぶと思いませんか?
それにお客さんが欲しいのは、その場の対処というミクロな問題ではなく、
今後の運営に対する信頼性の保証と言った「菓子折り」なんですよ。
#そりゃ対処されなきゃダメだけど、多少の早さよりも将来性の保証ですね。
それを理解できない自分の関連する処しか見ない新米プログラマなんかは
そのあたり不満に思う事が多いようです。
でも、そういう時こそ先輩方々が、
「自分のとこだけじゃなく、全体も考えよう」
「今の対処だけでなく、将来的な展望も考えよう」
「自分のイメージだけでなく、客が求めるものを正確につかめ」
とリードしてあげるべきでしょうね。
それにより皆PG>SEとかスキルアップしていくのでは?
Re:初期段階の投資費用を抑えるのに有効? (スコア:0)
なにか違っても、ご自分で「本来は、~、と思う…」と書かれていますよね…。そゆことかと。
#お菓子が食べたいのでAC
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
「客の立場」ってのが、「技術のことなんか考えたくもない人」(乱暴にいえば)という意味だとすると、
判らないでもないです。今の俺から見れば感情移入しにくい「立場」ではありますが。
>技術が無いから仕事を出しているってのにトラブル時に
>『技術無い様を云々し客に技術への理解を求める処』
>と、
>『素直に謝罪をしてくる処』
>技術レベル
>が同じならば、顧客は後者を選ぶと思いませんか?
どっちかってーと、俺が客でも(上記の極端なケースは別として)、
「そんなことする暇(?)が有るなら、とっとと直してよ」
としか思わないんじゃないかなあ?
いや、そりゃまあ社員が一人じゃなければ「暇」は消費しないはずではある
(菓子折り担当者と直し担当者がそれぞれ居る)けど、それはともかく菓子折りについては、
俺ならむしろ「これで誤魔化す気か?」とかいう猜疑心が沸いちゃうかも。
というか、謝罪はあっても「説明」が無いのは、いまどきどうかと思うんですが、
それで通るもんなんでしょうか?
いわゆるインフォームドコンセント(ちょっと話は違うけど)って、
相手がその技術に聡いかどうかは関係なく、やるべき時にはやるものですよね?
あーゆー感じでは?
ただ、説明の「しかた」は、相手に合わせた平明さでないと不味いことになるでしょうけど。
>技術レベル
>が同じならば
その前提がどこでどう成り立つか、が問題ですね。
少なくともそれは菓子折りからは絶対に出てこないものですよね。
>それにお客さんが欲しいのは、その場の対処というミクロな問題ではなく、
>今後の運営に対する信頼性の保証と言った「菓子折り」なんですよ。
>#そりゃ対処されなきゃダメだけど、多少の早さよりも将来性の保証ですね。
菓子折りが保証を意味し得るのは何故ですか?
俺が客なら、「まじめに」修繕に専念する会社のほうに、好感を持つだろなあ…。
謝罪って、なんぼ「素直」であっても、ただそれだけなんですよね。
その後が続く(それこそ)保証が無いから、「謝るだけならタダだしなあ」としか思えないって面があります。
#というか、そういうのをもって「ビジネスライク」というんだと思うけど。
#日本情緒とは相容れないかも知れないけど。
Re:初期段階の投資費用を抑えるのに有効? (スコア:0)
もしかして「菓子折り」って言葉とおりに使ってます?
私は「非技術的労働」全てを指して使っていると思ったんですが。
#元の記述はそれっぽいんで。
ですから、当方としての比較は、
「説明も真っ当にせずに修正を全力で行う」
と
「(多少作業の阻害になっても)技術実作業とは異なる、客への説明や謝罪もきちんと行う」
の二者でやっていたんですけど。
>謝罪って、なんぼ「素直」であっても、ただそれだけなんですよね。
>その後が続く(それこそ)保証が無いから、「謝るだけならタダだしなあ」としか思えないって
Re:初期段階の投資費用を抑えるのに有効? (スコア:0)
>> が、営業を考えると重要ですよ。
僕はそういう業界にいる人間じゃないのであくまでも想像ですが、「安心させる」の他に「怒りの矛先になってさしあげる」というのもあるような気が。;-)
一般論として、/.Jにいるような技術者タイプの人だと「謝る時間があればとっととバグを直せ!」と思うんだろうけど、非技術者な人々は「何をおいてもまず謝罪に来い!」と思うタイプも多そうだし、権力や地位が上昇するにつれて、その割合が高くなりそうな
Re:初期段階の投資費用を抑えるのに有効? (スコア:0)
しない業者とはつき合いにくいですね。
説明と謝罪をしないってことは、つまりは責任の転嫁か放棄としか思えないです。
一般的に、誰かに迷惑をかけたのであれば、かけた側に説明責任があると思います。
ビジネスであれば、多くの場合サービスを提供する側に責任があるはずです。
つまり、お金を受け取る側に説明責任があると思うわけです。
その上で、迷惑かけたんだから謝れと言いたいですね。
不可抗力ならしょうがないですが、それでも客に迷惑かけた点は謝れと。
# 逆に、お金を払う側は
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
>私は「非技術的労働」全てを指して使っていると思ったんですが。
さすがに菓子折りのみってことは無いですが、
一方で非技術的な全てというほど広いものも、望んだわけではないです。
>「説明も真っ当にせずに修正を全力で行う」
>と
>「(多少作業の阻害になっても)技術実作業とは異なる、客への説明や謝罪もきちんと行う」
てゆーか、「説明」と「謝罪」は独立したものかなと。
その上で、菓子折りってのは謝罪(のみ)の側に属するものの象徴として。
非技術的かどうかというよりも、「心情的」とでもいいますか。
>>謝罪って、なんぼ「素直」であっても、ただそれだけなんですよね。
>それは謝る方の立場から言うものではありません。
逆に、それを言ったらお仕舞いです(^^;
こっち側からは永遠に、その状況に対しての改善提案を、出来ないということになってしまうのですから。
いかに提供側であっても、平伏低頭してりゃいいってものでは、ないはずです。
>他人に迷惑を掛けたら謝る。技術がどうのではなく、人として、人と付き合うに置いての基本のお話ですから。
直せるものは直す、自分で駄目ならどっかからネタ(や場合によっては出来る人)を調達する。
もちろん状況説明はする。
人同士も、本来はそうであったはずだと思うんだけどなあ。
謝るなんていうオフトピなもの(笑)を導入してしまったのは、いつからなんだろう?
こっちの「思い」なんて、相手にとっては糞でしかないはずです。
そんなものを押し付ける「謝る」は、控えめに言っても「低い存在」だと、思いますね。
>将来的な問題発生原因の対処まで話をもって行けたりもするんで、
>真っ当なSEたらんとすればきちんと行うべき事だと思われます。
それは、そういうのを「好む」人が居る、ということですね。
で、好みは人間各自が勝手に設定できます。他人にはなんともかんとも。
株の値段が、素人(笑)目には何だか全然判らない理由で上下するのと、似たようなものかと。
風が吹けば桶屋が儲かる。オフトピって奴です。
まあ、オフトピだろうがなんだろうがモデレーションスコア(笑)をあざとく稼げるならば
芸の1つも覚えたほうが「儲けられる」という意味では、まぁそんなもんだろうとは思います。
>#あと、技術力というかテクニックはあるのだけども、マクロにものを見れないヤツとか。
#ミクロにしか見れない奴も、結構多いですし(笑)。
>特に少数意見って訳では無いと思いますので覚えておいて損は無いと思いますよ。
知らないわけではないです。憎んでるだけです。
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
別口でも書きましたが、説明と謝罪とは別のものです。
菓子折りは後者(だけ)を意味するシンボルです。
>「(お互いの)ビジネス」にどう関係するかだけじゃないでしょうか。
>「商品」の品質に自信を持っている(という売り込みをした)なら、
だとすれば尚更、取り扱い商品に菓子折りが無いという選択肢も、有り得そうです。
>「こういうトラブルが発生しました。申し訳ありません。」
>という謝罪と、
>「ついてはこういった対策を行いたいんですがよろしいでしょうか?」
>と断りを入れて欲しいですね。(緊急時は除きます)
事前か事後かの問題はまた別問題でして、それはさておき、
後者は必須ですが前者はアレだなと思います。
少なくとも、説明と謝罪の切り分けが出来ない(「必ず」同時に出してくる)人とは、
俺は一緒に仕事したくないかも…
などと、ちょっと思ってしまいました。
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
どこの業界か?に依存する話題では、ないのではないでしょうか?
さもないと、IT業界(コの業界?)だけが、そういうものが通用する痛い業界だ、
ということも成りかねない。個人的には(俺も属してるからには)それは嫌です(^^;;;;
>「安心させる」の他に「怒りの矛先になってさしあげる」というのもあるような気が。;-)
うわ。御免こうむりたーーーい。
あれだけ少年漫画で(笑)何度も何度も、「敵を討っても死んだ友は帰ってこないのだ」と
教えられて(笑)も、まだ判らない人が居るってことですかね。
>非技術者な人々は「何をおいてもまず謝罪に来い!」と思うタイプ
パソコン教室アビバのCMを思い出しました。
俺の時代は笑顔と体力で乗り切れた、とか言い張るアレ。(ガッツ石松氏主演)
そんな「甘い」時代はもう終わったんだよ、としか思えませんでした。はい。
これだけ日本企業の多くがヤバくなってきてるのに、未だに「旧来の」やり方で
いいんですか?とか、老婆心ながら思ってしまいます。
>権力や地位が上昇するにつれて、その割合が高くなりそうな気がします(偏見かな?)。
どっちかってーと、地位が無いにも関わらずああいうものを好む人ってのは、ちとヤバイと思っています。
ちょうど上記のアビバの人みたいなものです。"彼"の地位は多分せいぜい中堅だったのでしょう。
地位が十分あれば、そういう変化に対処する「余裕」が無いわけでもないでしょうから。
そうでないからこそ彼は慌てている。
>新版をsourceforgeから落としてきたので、もう問題無いです」的な対応をしても、問題は解決したかもしれないが、怒りをぶ
>つけるべき相手がどこにもいないので
まさにそれですね、OpenSourceの邪魔をしている存在は。
敵討ち(笑)の風習が無くなれば、もっとOpenSourceが本来のパフォーマンスを発揮できるようになるはずです。
と考えると、我々(^^;の敵がどっちなのかが、むしろはっきりしてくるように思います。
どうなんでしょうね?OpenSourceって、そういう社会のノリに対しても、何か新しいものを提案する存在
であったりは、しないんでしょうか?
それとも、現状の世の中のノリを甘受するしか、能m(__)mが無いんでしょうか?
Re:初期段階の投資費用を抑えるのに有効? (スコア:0)
>菓子折りは後者(だけ)を意味するシンボルです。
って事ですが、G7氏の周りでは謝罪と菓子折りだけで許してくれる奇特なお客サン
がいたのですか?
私としてはあまり考えられないのですが。
ですから、多分その後で対処はやっているのではないでしょうか?
Re:初期段階の投資費用を抑えるのに有効? (スコア:0)
なるほど。ネームバリューさえあれば、中身はどーでも良い、っと?
「MS製品/ORACLE製品使ってます」と言って、顧客が安心すれば、そのシステムは動かなくても全くOKなのね?(爆)
Re:初期段階の投資費用を抑えるのに有効? (スコア:0)
小規模で内々のPGしか経験が無いと「面倒」と思うかも知れないけども、客先折衝を行う人間にとっては当然の話ですな。
同様の機能を持ったシステムに置いて、
「MS製品/ORACLE製品使ってます」と言って、顧客が安心すれば、売上が断然違うってのもほぼ証明されていると言って良いでしょうし。
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個とか、
そういうのは業務でよく出てくるとおもいますが・・・
SQLテクニックとは (スコア:1)
うーんそれとも、組み込み関数を使ってちょっとトリッキーなことを簡潔に書いたりするようなやつなのかなあ。
熟練というのはむしろ、オプティマイザのクセに通じることを言いませんか。オプティマイザはアホですし、かといってすべて明示的に制御することはできませんので、ダミーでどうこう書き足したりするような。
Re:SQLテクニックとは (スコア:1)
1:手続き型言語にばかり慣れていると、戸惑い易い。
アレして、"それから"コレして、"それから"ソレして、という世界にばかり慣れていると、
答え一発なSQL(というかRelational DB)のような世界で、かえって困惑する。
単純なSelect文だけなら平気でしょうけど、「ちょっと」複雑になると、もう…
2:もうちょっとSQLの文法が綺麗だったら、まだしも楽だったかも。
なんてな難点を感じています。
Re:SQLテクニックとは (スコア:1)
そんなもの、Cとlispとかでも同じでは。
> 2:もうちょっとSQLの文法が綺麗だったら、まだしも楽だったかも。
これはどういう意味なのでしょうか?
SQL92などの仕様にあるものが「汚い」ということなのでしょうか?
何をもって「汚い」と表現しているのでしょうか?
Re:SQLテクニックとは (スコア:1)
ははは(^^;;
ついさっきまで仕事でSQLカリカリ書いてましたけど、SQLが汚いっていうんなら、もっと汚い言語たくさんあると思いますけど。
あと、一般的な制作系の仕事してる分には手続き型言語使う方が圧倒的に多いと思うんですけど、そんなのブツブツ言っても意味無いのでは?
#個人的にはアセンブラが好き(笑)
Re:Microsoft のおかげ? (スコア:2, 参考になる)
で、MS SQL Server 7.0 があっさりギブアップしてくれるので、困ってたりします。
DB 毎の「癖」を把握して、うまく対応しないと、複雑な SQL はきちんと動かないことも実感できますね。
たかだか、WHERE に IN を並べただけで、なんで落ちるんだぁ? > MS SQL Server 7
Re:SQLテクニックとは (スコア:0)
そういうたとえを出すのなら、「C と Prolog とかでも同じでは」と書くべきでしたね。
Re:SQLテクニックとは (スコア:1)
そう、職人技と表現されるので曖昧模糊としています。
もちろん、複雑な SQL や、数学的に効率の良い SQL を 書くのに訓練がいるのは分かってます。
>熟練というのはむしろ、オプティマイザのクセに通じることを言いませんか。
あぁ、そういうことか。
CPUやコンパイラを意識しながら C を書くようなものですかね。メモリ1byte単位の効率やら、CPU命令ひとつ単位の高速化に意味があった時代があったっけ。分野によっては今でもかな。
-- wanna be the biggest dreamer
Re:Microsoft のおかげ? (スコア:1)
よろしければ実例を見せていただけるとありがたいのですが。
Re:Microsoft のおかげ? (スコア:0)
INに該当する項目が大量にあってメモリ不足とかになってるってオチでは?
書き方が悪いんじゃないかと...
MS SQL Server 7 の弱点? (スコア:1)
WHERE a IN (SELECT a FROM table1 WHERE ....)
OR a IN (SELECT a FROM table2 WHERE ....)
OR a IN (SELECT a FROM table3 WHERE ....)
OR a IN (SELECT a FROM table4 WHERE ....)
OR a IN (SELECT a FROM table5 WHERE ....)
なんてのがあると、各 table に合致する要素が一つづつでも、あっさりこけてくれるので、頭が痛かったりします。
ちなみに、EXISTS に置き換えても駄目。
他には、
WHERE NOT b IN (SELECT b FROM table6 WHERE ....)
というのも、重いですね。これは、仕方がないかもしれませんが。
せめて、2000 では、改良されていることを祈ろう。
Re:MS SQL Server 7 の弱点? (スコア:0)
Re:Microsoft のおかげ? (スコア:1)
Re:MS SQL Server 7 の弱点? (スコア:0)
Re:SQLテクニックとは (スコア:1)
下を見たらキリが無いです(^^;
わざわざ自分の仕事(趣味でも同じ原理だが)の質を下げるマイナス要因を、抱えておきたいとは思いません。
ところで、ぱっと見ただけなんですが、
http://leap.sourceforge.net/walkthru.htm
このLeapというDBMSで使われてる検索言語って、少なくともSQLよりは綺麗なような気がしました。
SQLって、英語の語順や前置詞とかに、変に引きずられてる節がありますよね。
自然言語に下手に似せようとする辺り、古臭い言語な匂いを感じます。
文法に、直交性だか対称性だかが乏しいっす。まるでBasicのよう…
>一般的な制作系の仕事してる分には手続き型言語使う方が圧倒的に多いと思うんですけど、そんなのブツブツ言っても意味無いのでは?
ですから、ほかならぬ(よく使う)SQLが、非手続き型なんですってば(^^;;
滅多に出会わないなら、それこそブツブツ言いませんって。
>#個人的にはアセンブラが好き(笑)
俺は嫌いです(笑)
汗はCですら書けないもの(ただし抽象度低い方角についてですが:逆に高い方角でもCではお手上げになるんで)のため「だけ」に有ると思いたいです。
パズルとしては面白いかも知れませんが、そういうのはパズルで時間を潰したい(ぉ)時にだけ触りたいです。
Re:Microsoft のおかげ? (スコア:1)
ドキュな開発やってるところでは、SQLといっても
(例えば)Oracle依存ばりばりなコードばっかり書いてるかも知れぬ罠。
まあそれはともかく、SQLも痛し痒しですね。言語仕様が汚いし。
あと、ODBCで楽をした記憶が無いのは、俺がWinでDBなクライアントといえば
Delphiでしかやったことがないせいでしょうかね?まあそうでしょうねBDE(ぉ。
Delphiはともかくとしても、JDBC(言語が限定されちまうけど)のシンプルさにビックリした後では
大抵(語弊?)のAPIを見ても心が動かなかったりする。あんな簡単に動いちまっていいの?って感じ。
Re:Microsoft のおかげ? (スコア:0)
>(例えば)Oracle依存ばりばりなコードばっかり書いてるかも知れぬ罠。
対象DBのパフォーマンスを引き出すために依存したSQL書くのはよくあること。
パフォ落とさずにDB乗換機能を実装するなら、SQL投げる部分をコン
Re:Microsoft のおかげ? (スコア:1)
J2EEだと、最初からパフォは低めになっちゃう、のでわ(^^;
>それでSQLを語るとはある意味すごいな
いや、Delphiお得意(自称)のお手軽DBアプリ作り機能は、滅多に使っていません。
それで足りることって滅多にないせいです(^^;;;
結局SQLは自分でごりごり書く世界。
#あ。忘れてた(忘れたかった(ぉ))けど、Pro*C…。でもあれはWinじゃなかったし…
#Delphiのご利益受けてるのは、上記以外の面ですね。GUIのRADとか、Component「作り(使うだけじゃなく)」とか。
Re:Microsoft のおかげ? (スコア:1)
例として「日時を表現するSQL文を書け」とかいう問題でも出せば
宜しいかしら?
# 論点がずれているかも(^^;;
Re:Microsoft のおかげ? (スコア:1)
select date,time from foo;
じゃダメ?…なんだろうなきっと^^;
# 問題を理解していない。
-- wanna be the biggest dreamer
Re:Microsoft のおかげ? (スコア:2, 参考になる)
ODBCドライバや関連ライブラリのバージョン違いに起因する動作の違いに泣かされた覚えがあります。
接続先DBMSはSQL*Server...やれNTのサービスパックだIEの新バージョンだと、ことあるごとにドライバのマイナーバージョンが変わって、そのたびに動作の違いを検証してMDACコンポーネント [microsoft.com]で強制的にバージョンを合わせて...苦労しました。
# MDAC2.1 位の頃です。最近は使ってないので分かりません
Re:Microsoft のおかげ? (スコア:0)
データベース市場に風穴を開けるための ODBC であったはずなのに、今ではそれが仇になってるかも。ODBC に特許からませときゃ良かったーって思ってるに違いない。