みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
win10
FileMaker advance 15
「ログイン履歴の取得方法について」の質問させて頂いたのですが、
加えて気になる点がありまして、質問させて頂きます。
https://fm-aid.com/bbs2/viewtopic.php?id=6532
「ログイン履歴の取得方法について」のスクリプトでは、
リレーションを貼っていないパターンなので、ファイルを閉じることができた。という認識でよろしいでしょうか。
同じファイルの別テーブルの話についてなのですが、
話は変わるのですが、少し大きめのシステム構築に挑戦しようとしていまして、
見積や受注や販売などの機能をもったものです。
そこで、１ファイルに全てをつぎこむよりも、保守性や動作の軽快さなどにメリットが
あるということから、マスタや機能ごとにファイルを別に作成しています。
まだ一部のみの作成ですが、予定としては、おおよそ下記のような感じです。
マスタ関係
ログ関係
見積
受注
納品
請求
ログファイルも、今はログイン情報のみを残していますが、編集履歴などの他のデータも残す予定です。
（これから考えます。）
その場合には、別ファイルで管理したほうがいいかな。という思いがあって、別ファイルで作成していたのです。
情報が少なくて、すみません。。。
ちなみに、機能ごとに分割した場合には、
異なるファイルだがリレーションが貼ってある状況になると思うのですが、
その場合には、実質的に、スクリプトで再ログインすることは難しく、
ファイルメーカーのソフトを閉じることでしか再ログインをすることはできないという
認識で正しいのでしょうか？
またファイルを分割する基準やメリットについて、認識が正しいのか教えて頂けますとうれしいです。
お手数おかけ致しますが、よろしくお願い致します。
Last edited by あきひろ009 (2017-06-19 09:42:08)
Offline
> 「ログイン履歴の取得方法について」のスクリプトでは、
> リレーションを貼っていないパターンなので、ファイルを閉じることができた。という認識でよろしいでしょうか。
その通りです。
ソリューションの構築についてですが、それらの流れは一連のもので、さらに、データがほぼ同じデータが流れていきますね。
私ならば1ファイルで作ってしまいます。もちろん、ログテーブルも含めて。ただ。マスターテーブルについては、その更新の運用によっては別ファイルにするかも。
この辺りは、その後の運用の拡大と、その経験に寄って変わると思いますが。
Last edited by Shin (2017-06-19 11:44:13)
Offline
Shin様
回答ありがとうございます。
そうですね。流れていくデータの内容は、非常に近いです。
1ファイルということですが、データの量が多いと、別ファイルを持ったほうがよいと言うのは
特に無いのでしょうか。
受注・納品の明細データがもっともデータ数が多い部分となるので、
検索するときの速度でファイルの中に複数テーブルがあるのと、
ファイルにテーブルが単体であるのとでは、有意な差異はないのかが気になっています。
例えば、下記のようなイメージです。
ファイルの中に複数テーブル：
ファイルに、受注テーブルと納品テーブル
ファイルの中にテーブルは一つ：
受注テーブルのファイルと納品テーブルのファイル
またデータが破損した際に、修復する時間が
複数テーブルをもつファイルだと、データ量が大きいので、
時間がかかってしまうという点も気になっています。
正直言いまして、経験は全然ないのですが、
運用する上で、初めから、ある程度想定した形で作れればよいと考えています。
色々お聞きして、申し訳ないのですが、よろしくお願い致します。
Offline
レコード数の想定はどのくらいですか。
例えば、毎日注文が100件程度あり、それぞれに明細が50件、という想定で、年間180万レコードです。20ー30年程度は十分ですよ。検索速度も、この程度でしたらほとんど影響ありません。さすがに、全数のソートは少々時間がかかると思いますが、現実にはほぼあり得ない作業でしょう。
それと、同じデータがファイル間でインポートされていきますので、元データの修正による影響が大きいことと、アクセス管理が非常に煩雑になること、スクリプトの動きが外部スクリプトを参照していくことになるので見渡せなくなど、デメリットが大きいと思います。
ファイルの損傷の際の修復はもともと行わない前提で、例えば1時間ごとにバックアップを取っておきます。損傷から1時間以内のレコードの復帰を行えばいい、という考え方でいいのでは。
まあ、数ヶ月に1回程度はファイルの最適化を行った方がいいでしょうが、1時間程度もあれば可能だと思います。
Offline
Shin様
回答ありがとうございます。
お答えするのが少し恥ずかしいですが、レコード総定数は、年間3万レコード程度です。
年間180万レコードで、20～30年程度は大丈夫とのことですと、
5,400万レコードでも、検索速度に支障が出る程度ではないということなんですね。
無知ゆえに、検索速度について、恐れすぎていました。
作ったものの、使い物にならないということが怖くてです。
Shin様のおっしゃる通り、デメリットが大きそうですね。
特にアクセス管理は、マスタごとにユーザーが出来る範囲を限定したいところですが、
複数ファイルだと、非常に煩雑で、実質的に難しいです。
ということで、ファイルを分割して作成しておりましたが、
統合していきます。。。
まだ早めに気づけて良かったです！ありがとうございます！
バックアップは、FileMaker Serverの機能によるものでしょうか。
またバックアップはデータサイズが気になりますが、
Shin様の想定されているレコード数で1時間毎でも問題ないのでしたら、
弊社の場合は、全く問題にもならないと思うので、安心致しました。
ちょっとずつ作り直していきます。
Offline
業務仕様でしょうから、FielMekr server での運用を前提にしています。
バックアップは、十分な容量を持たせておけばいいでしょう。画像が入らないものでしたら、運用ファイル容量の1000倍程度あれば十分では。
私のところでのバックアップ戦略は、1時間ごとに2日間保存、毎日早朝のバックアップは、60日間保存、週1のバックアップは、1年間保存、別に、1ヶ月1回くらい、そのバックアップのいずれかを別のディレクトリーに移動させて永久保存してあります。プログレッシブにすれば、容量も気になりませんよ
それらと別に、クローンファイルを週1回保存、これは半年後に上書きしています。
Offline
回答ありがとうございます。
そうです。今はまだ導入していないですが、運用の際には、FileMaker Serverを導入する予定です。
実際に運用されてるShin様の意見があれば、とても心強いです。
バックアップファイル戦略についても、ありがとうございます！
実際の運用の際に参考にさせて頂きます。
疑問も解消されて、方向性が見えてきました！
Offline
[ Generated in 0.008 seconds, 7 queries executed - Memory usage: 541.19 KiB (Peak: 562.09 KiB) ]