初心者のFileMaker pro Q&A (旧掲示板)

すみやまる

Member

データとプログラム（フォーム）の分離？

いつもお世話になります。
「ＦＭ１３スーパーリファレンス」を購入しました。関数等は１３対応版が出てからと思っています。
読解不足のなかでの質問で申し訳無いのですが・・・

例えば納品されているプログラムのバージョンアップ等はどういう形でなされるのでしょうか？
データとプログラムが分離しているのでしたら何ら問題ないと思うのですが
今理解している範囲ではデータとプログラムは１つのモノのように思えます。

アクセスもデータは分離できたように思います。
ＦＭも分離できるのでしょうか？？

宜しくお願い致します。

Shin

Member

Re: データとプログラム（フォーム）の分離？

結果から言うと、不完全ながら、分離は可能です。
不完全なのは、データ構造の中で、計算式や自動入力の設定、ルックアップの構造は、データ構造の中に置かざるを得ません。他にも、マイナス面はいろいろあります。
http://web.sevensdoor.com/events_browse.xsl?report=38
が参考になるでしょう。
逆に、FileMakerに、分離モデルが必要かどうか、ですが、分離モデルは、メガデータ級の大規模のシステムでのメンテナンスを考えると、大きなメリットが有るでしょう。これは、データの移行に数時間、場合によっては数週間と言う時間が必要になるからです。ですが、FMでその様な大きなデータを扱う場面はそんなに多くはないでしょうね。
また、バージョンアップに伴い、テーブルの構造が変更されている場合には、分離モデルでもデータそのもの以外は全て置き換えになるため、同じ事ですよね。どちらにしてもこのデータ移行の仕組みは作っておく必要が有りますので、全自動化してしまえば、分離モデルの必要性は下がるかもしれません。
私の作っているシステムで、一部分離モデルを使っています。これは、インターフェースが非常に多岐に渡るため、１個の構造で治まりきらないと思われた部分です。ですが、結局、手を加える時にはテーブル構造に手を入れる事も多く、大きなメリットは感じませんね。（自分の手の届く所で運用しているためも有るでしょうが）
http://filemaker-kou.seesaa.net/article/233411262.html
にも面白い意見が載っています。

すみやまる

Member

Re: データとプログラム（フォーム）の分離？

いつも有難うございます。

いろいろ既出なんですね、調査不足でした・・・。
基本的に分離するものではないと言うことで納得です。
データ移行も自動化してしまえば、業務中断も最小限で済みますね。

Shin

Member

Re: データとプログラム（フォーム）の分離？

弊社では、FM6からのコンバート作業の時に、大いに使っています。
データは１ファイルにまとめてしまい、レイアウトやそれに伴う動きは、従来型のままのファイルで残し、そちらにはデータは保存しない構造になっています。

データの移行も、相当気をつけないと、シリアル値の設定移行を忘れるんですよね。

Moz

Guest

Re: データとプログラム（フォーム）の分離？

いつも有難うございます。

いろいろ既出なんですね、調査不足でした・・・。
基本的に分離するものではないと言うことで納得です。
データ移行も自動化してしまえば、業務中断も最小限で済みますね。

既に解決しているのに僭越ながら、
「基本的に分離するものではない」という断じてしまうのは如何なものかと思います。

レイアウトとスクリプトで構成されたインタフェース、
データと計算式やルックアップなどに必要な最低限のリレーション構造を持つデータ。
このようにファイルを分けて開発することは良くあることです。

受託開発などで開発を行い、納品後に改良の要望があった場合など、
データに影響がなければインタフェースのみの交換で済ませることが可能です。

もちろん運用しながら本番環境に修正を加えられるような運用であれば
分離させない方が良いこともあるでしょう。

運用以外にも予算や納期に応じて分離・非分離は変わってきます。

初めての開発で分離というのは難しいかも知れませんが、
分離というのはFileMakerでの開発においてネガティブでもマイノリティでもありません。

コンバイン

Guest

Re: データとプログラム（フォーム）の分離？

分離やってみたFileMaker新参だけど疑問がある。
分離って不完全なとことかあってFileMakerに無理させる部分あるよね？
社内ならしょうがないけど受託でやってるなら
もっと合った技術がいくらでもあると思うんだけどなんで無理してFileMakerでやるの？
FileMaker以外使えませんとかいうのは受託として論外だから別として
FileMakerのいいとこ殺しちゃう中途半端な分離式ってさ、
使い所が分かんないんだよね。

エクセルで伝票作ってるみたいな無理してる会社に
FileMakerだったらそんな無理矢理いらないですよって営業よくしてるっぽいけどさ、
FileMakerで分離させてる会社見つけたら
一般的なプログラミングすればそんな無理矢理いらないですよって言いたくなる感じ。

このソフトって現場が作って変えて育ててできるのがいいとこなんじゃないの？
現場がいじるのに不便たくさんある分離使ってFileMakerでやる意味ある？
FileMakerしか使えない人はしょうがないけど。

Shin

Member

Re: データとプログラム（フォーム）の分離？

分離させても、FMの本当のいいところはそのままですよ。
最も考えないといけないのは、その索引のもたせ方とアクセス権の工夫だけ。
ほぼ完全な分離モデルを使った商用のシステムも、たくさん配布されるようになりましたよ。

コンバイン

Guest

Re: データとプログラム（フォーム）の分離？

Shinさんが言うなら間違いないんでしょうね。
自分が見た情報とかの頃より良くなってるのかな。
でも"いいとこ"の視点が違う気がする。

わざわざFileMaker使いたい仕事って
現場が自分たちに合うシステムを自分たちで触りたいときで
受託やってる会社に開発はお任せするならわざわざ選ぶメリット無いし。
現場がどんどん改造してけるシステムを考えるなら
無理が混ざる分離は邪魔じゃないかな

うちの会社は前にいた人が残したFileMakerのシステム多いけど
分離使ってるやつは営業さん複雑で触れなくなってる
仕方ないので自分がFileMaker学んでメンテナンスしてるけど
その中途半端さがかなり気持ち悪いので
営業さんが自分たちで触れるように通常の1ファイルに戻した

イベントで受託やってる会社の技術者の人とも話したけど
FileMaker以外を知らなすぎて
必要なシステム作るんじゃなくてFileMakerでどうやって作るかしか言わない
分離ってそういうひとたちから出てきたものじゃない？
FileMakerそのものはそういう作りに中途半端にしか対応してないんだし

ShinさんとかMozさんがいうように分離は良くなってるとしても
分離でいくか通常でいくかの前に
そのシステムを作るのにFileMakerも含めた色んな中から選ぶのが先じゃない？

どうみても分離どうこうの前にFileMakerでやる意味あるのかよ
と言いたくなる提案持ってくる会社が「分離ですから」とか言ってて困る

Shin

Member

Re: データとプログラム（フォーム）の分離？

わざわざFileMaker使いたい仕事って
現場が自分たちに合うシステムを自分たちで触りたいときで
受託やってる会社に開発はお任せするならわざわざ選ぶメリット無いし

ShinさんとかMozさんがいうように分離は良くなってるとしても
分離でいくか通常でいくかの前に
そのシステムを作るのにFileMakerも含めた色んな中から選ぶのが先じゃない？

どうみても分離どうこうの前にFileMakerでやる意味あるのかよ
と言いたくなる提案持ってくる会社が「分離ですから」とか言ってて困る

そんな事は無いでしょう。開発する速度が、雲泥の差がある。
数年かけて開発するような大規模勘定系はFMの案件にはならないでしょうが、中規模以下のシステムには、選択の一つになると思いますよ。
その規模でも、ゼロから開発すると、SQL系のDBでは開発に1年とか言われますが、FMですと4ヶ月で完了したりします。この時間は、コストになって返ってきます。
また、DBのライセンス料でも、Oracleと比べると相当安くつきます。まあ、DBにフリーのものを使っても、プロジェクトファイルのライセンス料が発生すれば、同じかも。
弊社のお付き合いしている会社が、FMの開発レベルの非常に高いところばかりですので、そう見えるのかもしれませんが。

分離モデルの非常にいいモデルとして、あるフリーの電子カルテがあります。医療者向けしかダウンロードできないようですが、利点をうまく使い、欠点を上手にカバーして有ります。その業界は、大規模な改訂が2年ごとにあるので、その作り方が必須なようですね。
ベースを作ったのは医療者のグループだそうですが、その後のメンテナンスは、FMも扱っている業者です。配布はフリーですが、有料でメンテナンスも行なってくれるようです。良い業務スタイルモデルだと思いますよ。