リレーションシップに使える比較演算子のテストをするため以下のテーブルを作成した。
2010年10月28日木曜日
2010年10月26日火曜日
インタフェースとデータベース (4) まとめ
インターフェースとデータベースを切り離し、プログラム (FileMaker ではスクリプト) で手続きを記述する方法は FileMaker でも有効な方法。
しかし FileMaker にはもっと短期間で構築できる方法がある。
短期間ということは低工数であり、同時に少ないコード量で案件を実現できることに他ならない。
このあたりの柔軟性こそが FileMaker の特徴と言える。
ラベル:
Design Data
インタフェースとデータベース (2)
レイアウトを切り替え(ターゲットテーブルを変更し)た後、新規レコードの挿入を行う方法は野暮ったく感じることもあるが、個人的には視認性とメンテナンス製に優れた方法と感じている。
以下はレイアウトの切り替え(ターゲットテーブルの変更)も新規レコードの挿入スクリプトステップも利用しない方法だが、作成者(実際のコーダー)しか理解できない(理解しづらい)構造になっている。
ラベル:
Design Data,
Portal,
Relationship
インタフェースからデータベースに値を書き込む
フロントエンドとなるインターフェースを作成し、データベースに値を書き込むため、以下のテーブル (tbl_Frontend と tbl_Data) を作成した。
なお今回はスクリプトのみで実装してみる。
フロントエンドより値の読み込み
↓
スクリプトによる値の取得
↓
データベースへ値の書き込み
ラベル:
Design Data,
Script
2010年10月19日火曜日
入力値の自動化と主キー Primary Key (自然キー Natural key)
レコードの特定や関連付けに 人工キー Artificial key を用いた場合、インポートなどの作業で混乱が予想される。
また、検索条件として、人間がレコードIDを利用するという状況は考えづらいため、人間が理解できる自然キー Natural key を入力値の自動化によって生成してみる。
以下のテーブルを作成した。
ここでは一意 Unique な値を持たせるため、タイムスタンプを利用してみる。
もちろん、複数クライアントの環境ではタイムスタンプが一意 Unique であるとは言えないため、エントリー後半では入力値の自動化を利用した複合キーの生成も行う。
2010年10月15日金曜日
2010年10月14日木曜日
2010年10月13日水曜日
フィールドのバリデーション
オペレータの数だけ入力値に揺らぎが発生する。
例えば「ファイルメーカー」という文字列に対して、「ファイル メーカー」と書く人もいれば、かな入力のオペレータの場合は「ファイルメ-カ-」と書くなど。
これを防ぐために入力値のバリデーション Validation を行う必要がある。
まずは以下のテーブルを作成した。
ラベル:
Field,
Field Option
2010年10月12日火曜日
登録:
投稿 (Atom)