mhattaによる
2007年02月18日 8時55分の掲載
まだ噂だけどね部門より。
まだ噂だけどね部門より。
shunta 曰く、
Mac系噂サイトThinkSecretの記事によると、FileMakerは次期バージョンでSQL(ODBC)データソースへの対応を果たすようです。
もしこれが事実なら、MySQL(5.0)のフロントエンドとして、使いやすさに定評のあるFileMakerが利用できることになります。 これでXOOPSなどのCMSによって蓄積されたデータをFileMakerで手軽に活用できるのではないかと、アレゲにワクワクしませんか?
関連ストーリー
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
現在のバージョンでもODBC対応できていますが... (スコア:5, 参考になる)
FileMaker社より公式のプラグインをダウンロードして 利用する
ことができます。
ただ、あまり安定しておらず、速度もでない、というのが印象で、
たとえば MSAccess や Oracle の フロントエンドとして 使う、
という案件で技術評価しましたが、業務には耐えない、という
結論となりました。
今回のバージョンで このあたりが解決してくれていれば いいですね。
上記案件では、一度 CSVファイルにしてから読み込ませる、という
フローで FileMakerを使うことにしました。巨大なファイルを扱わ
ない限り、それなりに 使えるというのが印象です。
Re:現在のバージョンでもODBC対応できていますが... (スコア:2, 興味深い)
これに顧客先ですでにお使いになられていたMac向けの FileMakerのUIを
統合してほしい、という依頼がありましたので、
最初からFileMakerはマストだったわけです。
統合するどちらのシステムも 完成度が高かったため、両者の変更は
最小にする必要がありました。結果、CSV経由での通信を使った
フロントエンド利用、ということになったわけです。
＃その際 かなりアクロバティックな動作をすること、については
＃顧客から同意をいただきました。
結果できあがったものは、パッケージ化された業務システムに、
顧客の必要なUIを載せる、というカスタマイズ性を最大限に
活かせたシステムになり、ご好評をいただいております。
FileMakerでは、外部DB連携に XML/SOAPを用いたソリューションも可能ですが、
やはり処理効率から行って、CSVが一番速く、手っ取り早いという結論です。
親コメント
FileMakerの強みは感覚的に使えること (スコア:2, すばらしい洞察)
FileMakerが優れたインターフェースを持ったデータベースアプリケーションであることに異存はないんだけど、それは主として「使いながら発展させる」ということがやりやすいからだと思うのね。最初に覚えないといけないことが少ないので、データベースは初めてという人にすすめやすい。そして使っているうちにデータベースってどういうものか、わかってくるというね。
でも、RDBMSってのは、スキーマを頻繁に変更するような使い方をするものじゃない。スキーマを変更しても問題ないのは、利用者が限られている場合であって、複数のアプリケーションが参照するようなデータベースのスキーマはそうそう簡単には変更できないよね？スキーマを変更できないデータベースのフロントエンドとしては、別にFileMakerにアドバンテージはないと思う。AccessでもVBで書いたアプリでも、別に何でも同じ。もしあなたがXOOPSのバックエンドをFileMakerで覗いて嬉しかったら、別にAccessでも満足できたと思うけど。
Re:FileMakerの強みは感覚的に使えること (スコア:2, すばらしい洞察)
当時としては、（某少佐のセリフを借りればｗ）エンドユーザに「素直にパーソナルDBのありようを示した」画期的なソフトの出現だった。
時代は移り変わって、FileMakerも自分自身のフォロワー(Access等)に負けないように機能追加をして生き延びてきてはいるけれども、
それもFileMakerが作り出したパラダイムの中でのマイナーな変化にすぎず、今回のODBC対応もゆるやかな延命措置にすぎない感じは拭えません。
ご指摘のようにRDBMSのフロントエンドとして生き残れるかというと、ちょっと難しい。せいぜい既存ユーザのフロントエンドの選択肢が増える程度かも。
振り返ってみると、FileMakerその他が開拓したパーソナル向けDBの市場というものも、昔と比べてさほど大きくなっている感じもしないし、
逆に個人向けに限ってしまえば、情報管理の仕方も、定型的・固定的な枠組みでデータを蓄積・検索するのではなく、
Mac OS XのSpotlightやGoogleデスクトップ検索のような全文検索やメタデータによる管理方法の方が大きく取り扱われているような気がします。
ですので、いっそのことFileMakerもOS Xのファイルシステムのメタデータを扱えるようになったりすると、非常に面白いかもと思ったりするんですよね。
そうなればiTunesやiPhotoのメタデータにもアクセスできるでしょうし、Spotlight検索にも対応できる独自メタデータを扱えたりと、
OS Xのメタデータ管理機能を活かすフロントエンドになるような気もするんですが。。。
親コメント
Re:FileMakerの強みは感覚的に使えること (スコア:2, 興味深い)
(ユーザ以外には良さが理解されていない)孤高の存在であることには
違いないでしょう。パラダイムシフトはFileMaker 7で起きています。
その土台があるからこそ、SQL対応も果たせるようになるのでしょう。
親コメント
Re:FileMakerの強みは感覚的に使えること (スコア:2, おもしろおかしい)
＃はっ、動作環境がないぞ！
親コメント
FileMaker Serverは？ (スコア:2, すばらしい洞察)
結局、カスタムWeb公開機能のXMLを取得してくるようにして（FX.php等で）解決したんだが、XMLくらいしかまともに使えそうなものがないというのは何とかして欲しい。30万も払ったのに…。
そもそも、カスタムWebのXML + XSLTでまともにページ作ってる奴なんて存在するのだろうか。
XSLTを生で書こうとするなんてマゾだと思うんですけどね。
FileMaker ServerもPHPやPerl等からまともに使えるようにして欲しいと思ったり、思わなかったり。
強要されて・・・ (スコア:2, 興味深い)
Excelで吸い出して加工したいといわれて
ODBC経由で吸い出すものを作ったものの…
案件担当者がなぜか刑事告訴されて案件自体なくなった…
報酬もろくに出なかったけど
まぁ、実害がなかっただけもうけもの
実際は動作が重くて自分では使いたくないものでした
真っ白なキャンバスをカルマで染めて・・・
SQLサーバ?? (スコア:1, すばらしい洞察)
その言い回しを聞くと、どうも
MS SQL Serverという特定商品を思い出してしまうのですが(^^;。
今回のって、ODBCっていう話なのですよね?だとすれば別の話ですよね。
(ODBC自体にもMSの息はかかってるがそれはともかく)
ところで、そんなMS「SQL」Serverが、
SQL(言語としての)離れを始めようとしてるってのは、
興味深いです。
.NETで書いたコードをServerの中で使えるとか、LINQだとか、
少しづつ脱SQLをやってますね。
SQLは言語仕様として古すぎて使いにくい面が結構あるんで、
こういう動きは歓迎したいです。
ただ、例によってMSだってのがちょっとね。
ポスグレやMySQLもそういうことをやってくれよ(^^;
#SQLはUNIXみたいな意味でのフィルタが書けないのが致命的だと思うのでAC
#Viewも「その入力が何なのか」はView内にハードコーディングしないとならない(T_T)