みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
Win10 FMP18
5名のユーザーがおります。この5名の対してそれぞれアカウントを作るの
はもちろんですが、ファイルもしくはテーブルもそれぞれ分けた方が良い
のでしょうか？
各々のレコードには固有のシリアルNo.をふって管理するのですが、1つの
ファイルで管理する事もちろん可能だと思いますが、この場合はアクセス
権の管理が大変かなぁと思っています。
逆にそれぞれファイルもしくはテーブルを分けた場合はアクセス権の管理
は楽かと思いますが、串刺し検索をする場合に少々面倒かと勝手に思って
おります。
一般的にはどうなんでしょうか？今はまだ1つのレイアウトしか作ってお
らずどうにでも肉付け出来るのですが、ここらへんは最初から気にした方
が良いかと思い質問させて頂きました。
では、宜しくお願いします。
Offline
アカウントを作成するのは「誰が入力するか」を分ける目的もあります。
デフォルトフィールドに「作成者」「更新者」といったフィールドがありますが、
誰が処理を行ったのかという情報もレコードに含めれば良いでしょう。
テーブルを作る際に考えることは「何を管理するか」「何の情報を入力するか」です。
Aさんの入力した顧客
Bさんの入力した顧客
「誰が入力したのか」は顧客の付随情報に過ぎません。
アカウント毎にファイルやテーブルを分ける必要はありません。
※ファイルを共有せず個別に渡して入力させる場合は自ずとファイルは個別になりますが、
それはファイルを分けるとはいえないでしょう。
Claris の 独習用教材 FileMaker Master Book 初級編の第7章を一読されることをおすすめします。
FileMaker 公式トレーニング教材
Last edited by Moz (2020-04-27 10:15:21)
Offline
データの共有についての基礎的な勉強が必要ですね。
その5人が、同じ業務を行い、共通のデータを扱い、お互いにデータの編集を許可するのでしたら、1個のレイアウトで十分ですし、データの閲覧や編集の制限も不要ですね。
その5人が、営業と現場、経理でしたら、同じ画面で仕事するのは無理ですし、また、お互いにデータの編集（改変）をされてしまうと困るでしょう。この時に、アクセス権を使って、編集を許可したり、閲覧を許可したりします。
Last edited by Shin (2020-04-27 17:20:26)
Offline
Mozさん
お世話になります。
なるほど、ファイルを分ける程でも無い事が理解出来ました。
が、元々とある指図書を元に作っておりましたので、テーブルは何個か必要になりそうです。
FileMaker Master Book 初級編は早速ダウンロードして拝見しました。
この内容が無料というのはかなりスゴいですね。
素朴な疑問ですが、FMP18から自動的に主キーが作られるようになりましたが、この主キーはそのまま使ったりしますか？
というのは、例えばとあるマスタを作ろうとした時、コードNo.が存在するのでそれをそのまま主キーとして使用します。
イマイチ、この自動で作られた主キーの使い道が分からないのですが・・・。
では、宜しくお願いします。
Offline
Shinさん
いつもありがとうございます。
実は過去に習ったことがあったのですが、今は全くFileMakerを使ってなかったので根本的な事を忘れていました。
おっしゃる通り、私がやりたいのは同じ業務を行うのでレイアウトは1個で十分ですが、自分自身が作ったレコードは他の者に編集されるのは困るのでアクセス制限が必要になりますね。
で、一番分からなかったのは、ログイン後どのように同じレイアウトをアクセス権毎に処理をさせようかと思っていましたが、良く考えたらそのような処理をする為にスクリプトが存在しますもんね。
とにかく、一から勉強しなおしてみます。
ありがとうございます。
Last edited by げっさん (2020-04-28 09:24:47)
Offline
お役に立てて光栄です。
テーブルは必要に応じて複数あっても問題ありません。
自動的に作られるフィールドはデフォルトフィールドと呼ばれるものです。
FileMaker Pro 17 Advanced からの新機能です。
FileMaker Pro 17 Advanced 以降で新しいテーブルを作成すると自動的に作られます。
少しハードルが高いですがデフォルトフィールドは好みに変更できます。
https://www.mirai-switch.com/post/fm18-defaultfieldxml
「主キー」という名前ではありませんが私は使っています。
デフォルトフィールドを変更して「主キー」にあたるものを利用しています。
中身は Get ( UUID ) です。
主キーは意味のないユニーク（重複しない）な文字列であることが望ましいとされていますので
デフォルトフィールドのように Get ( UUID ) / Get ( UUID番号 ) を使うことは理に適っています。
意味のないユニークな文字列が望ましいといわれていますが、
コードNo.など既存の値がユニークであれば意味を持っていてもいいと思いますよ。
気を付けるのはあとから絶対に変更されないということです。
顧客番号などにしてごねる奴が出て変更されるようならば別に用意したほうが良いでしょう。
Last edited by Moz (2020-04-28 09:46:26)
Offline
デフォルトフィールドの主キーは、場合によって使えばいいです。単なるシリアル番号でもいいのですが、UUIDは別に作ったファイルも重複する可能性はまずありませんので、データのマージする可能性があるならば有用です。
> ログイン後どのように同じレイアウトをアクセス権毎に処理をさせようか
アクセス権で閲覧を制限すれば、許可されているレコードのみを見ることができます。それで十分なのでは。
Offline
Mozさん
返信ありがとうございます。
少しハードルが高いですがデフォルトフィールドは好みに変更できます。
https://www.mirai-switch.com/post/fm18-defaultfieldxml
こちらはさすがにハードル高すぎるので止めておきます。(笑)
主キーは意味のないユニーク（重複しない）な文字列であることが望ましいとされていますので
デフォルトフィールドのように Get ( UUID ) / Get ( UUID番号 ) を使うことは理に適っています。
なるほど、確かにユニークという部分が重要なので、Get ( UUID ) / Get ( UUID番号 )は絶対にかぶりませんもんね。
私自身、この主キー自体がレイアウト上に表示させるのが目的かと思っていましたが、そうではないんですね？！
あくまでも、キーであって裏方の役目という認識で間違いないでしょうか？
意味のないユニークな文字列が望ましいといわれていますが、
コードNo.など既存の値がユニークであれば意味を持っていてもいいと思いますよ。
コードNo.などはまさしく表に出てくるNo.なので正直Get ( UUID番号 )では代用出来ないと思っていましたが、要はユニークであれば使いやすい値を使えば良いという事ですよね？！
気を付けるのはあとから絶対に変更されないということです。
顧客番号などにしてごねる奴が出て変更されるようならば別に用意したほうが良いでしょう。
なるほど、見た目の顧客番号はレコード毎に変えられるようにして、あくまでも識別番号である主キーはGet ( UUID ) / Get ( UUID番号 )を使うという事ですよね？！
そうなると、顧客番号は変更しても問題ないという事ですから。
ただ、顧客番号を主キーにしないにしても、ユニークにしとく必要がありますね。
それなら、変更は可能ですが、重複はしませんものんね？！
こんな理解で宜しいでしょうか？
Offline
Pages: 1
[ Generated in 0.004 seconds, 7 queries executed - Memory usage: 543.68 KiB (Peak: 564.59 KiB) ]