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

みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。

1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)

You are not logged in.

Announcement

新しい掲示板は、こちら:https://fm-aid.com/forum/t/filemaker


#1 2017-02-17 16:27:40

写真
Guest

写真のデータベース

写真整理と活用のためデータベース化を思いつき、カンファレンスで説明されていた「膨大な量の写真・画像を管理」と同じ内容でテストしました。
フィールドは4個作成し、2つの方法で写真を50枚取込ました。
ファイル名(テキスト)
イメージ(オブジェクト)
イメージのサムネール(オブジェクト)
ファイルパス(テキスト)

ファイルの一括インポートオプションで
1.各ピクチャファイルの参照データのみインポートにチェックして、写真を50枚取り込むと300KB増えていました。
   従い10000枚であれば計算では10000÷50×300=60000KB=60MB になります。

2.各ピクチャファイルの参照データのみインポートに未チェックでは、写真を50枚取り込むと1100KB増えていました。
   従い10000枚であれば計算では10000÷50×1100=220000KB=220MB になります。

どちらも全てのフォールドに画像やテキストが取込できているのでチェックは容量の差のみでしょうか?
同じであれば容量の少ない「1」の方法が良いかと思うのですが。
ヘルプを読みましたが理解できず、相談致します。
V12を使用しています。

#2 2017-02-17 17:18:43

シャチ
Member

Re: 写真のデータベース

300MBというくらいのデータ量は問題ない大きさで
わたしは、目下文化財のデータベースを作ってますが、
荒い画像の貼り付けだけでファイルの大きさは500MBになろうかとしてます。
あまりファイルサイズを気にすることはないかと思いますが。。

Offline

#3 2017-02-17 18:55:18

yaya
Member

Re: 写真のデータベース

1の場合、ピクチャファイルは残す必要があります。
2の場合、ピクチャファイルは不要になります。

結局、全体の容量は同じようなものですので、容量以外の要素で決めれば良いと思います。

Offline

#4 2017-02-17 22:51:16

Goo
Guest

Re: 写真のデータベース

300MBが大きくないっていい時代になったよね。

#5 2017-02-20 10:56:14

写真
Guest

Re: 写真のデータベース

yaya wrote:

1の場合、ピクチャファイルは残す必要があります。
2の場合、ピクチャファイルは不要になります。

結局、全体の容量は同じようなものですので、容量以外の要素で決めれば良いと思います。

1と2の違いを実際に試し確認できました。
どちらを選ぶかはもう少し考えます。
有難う御座います。

#6 2017-02-20 11:13:31

写真
Guest

Re: 写真のデータベース

シャチ wrote:

300MBというくらいのデータ量は問題ない大きさで
わたしは、目下文化財のデータベースを作ってますが、
荒い画像の貼り付けだけでファイルの大きさは500MBになろうかとしてます。
あまりファイルサイズを気にすることはないかと思いますが。。

整理と活用を目的に作成中ですが、実際に写真を取り込むと、次にどうすれば良いのかと思案してます。
写真ごとにコメントを付けると非常に手間が掛かります。
せめて回転寿司屋のiPad?のように写真が一画面に縦横に20個づつ見えればよいのですが。
FMで可能でしょうか?
文化財の写真はどの様に利用されるのでしょうか。
宜しければ教えて下さい。

#7 2017-02-20 11:26:10

チポ
Member

Re: 写真のデータベース

> 1.各ピクチャファイルの参照データのみインポートにチェックして、写真を50枚取り込むと300KB増えていました。
   従い10000枚であれば計算では10000÷50×300=60000KB=60MB になります。

ファイル自体が持っている容量が有りますから、このような計算にはならないでしょう。
オブジェクトフィールドに参照で入力した場合、
パスのテキストデータですから、数十B程度の容量だと思いますよ。

計算フィールドで、
  Length ( オブジェクトフィールド )
とすると、オブジェクトフィールドの容量が求められます。


で、
参照か、実データの取り込みかは、使い方で決めればいいのでは。

例えば、
そのファイルを他に渡す場合は参照のリンクを切らさないように注意が必要になりますね。
ファイルのバックアップは必須ですが、実データだと、ファイル容量の2倍となりますから、
yayaさんの言われるような比較は出来ませんよね。



> 写真が一画面に縦横に20個づつ見えれば
方法はいろいろ考えられますが、、

例えば横に4枚の写真を並べて、縦にスクロールする場合、
別テーブルを作って、元のテーブルのレコード4つずつと照合する様にリレーションを作れば、
ポータルを横に4つ並べて、そのリスト表示でスクロール出来ます。

20枚ごとにぱらぱらめくる様に見たいのでしたら、
20レコードと照合するリレーションも考えられます。

Offline

#8 2017-02-20 15:28:03

写真
Guest

Re: 写真のデータベース

チポ wrote:

> 1.各ピクチャファイルの参照データのみインポートにチェックして、写真を50枚取り込むと300KB増えていました。
   従い10000枚であれば計算では10000÷50×300=60000KB=60MB になります。

ファイル自体が持っている容量が有りますから、このような計算にはならないでしょう。
オブジェクトフィールドに参照で入力した場合、
パスのテキストデータですから、数十B程度の容量だと思いますよ。

計算フィールドで、
  Length ( オブジェクトフィールド )
とすると、オブジェクトフィールドの容量が求められます。


で、
参照か、実データの取り込みかは、使い方で決めればいいのでは。

例えば、
そのファイルを他に渡す場合は参照のリンクを切らさないように注意が必要になりますね。
ファイルのバックアップは必須ですが、実データだと、ファイル容量の2倍となりますから、
yayaさんの言われるような比較は出来ませんよね。



> 写真が一画面に縦横に20個づつ見えれば
方法はいろいろ考えられますが、、

例えば横に4枚の写真を並べて、縦にスクロールする場合、
別テーブルを作って、元のテーブルのレコード4つずつと照合する様にリレーションを作れば、
ポータルを横に4つ並べて、そのリスト表示でスクロール出来ます。

20枚ごとにぱらぱらめくる様に見たいのでしたら、
20レコードと照合するリレーションも考えられます。

4テーブルはデータベースの管理でテーブルを選択したオブジェクトを複製で4個作り、元(一番初めの)テーブルとはファイル名でリレーションしました。
ポータルを4個並べましたが、同じ写真が横並びで表示します。
一個ずつずらすには如何すればよいのでしょうか。

#9 2017-02-20 15:43:21

チポ
Member

Re: 写真のデータベース

表示用のテーブルは一つのみです。

元のテーブルでレコード番号のフィールド、
表示用のテーブルで計算フィールドを二つ
  照合初 = レコード番号 * 2 - 3
  照合終 = レコード番号 * 2 
として、リレーションを
  照合初 <= レコード番号
  and
  照合終 >= レコード番号
とします。

これで元のレコード4つずつが関連レコードとなりますね。
1行ポータルにオブジェクトフィールドを置き、
最初の行を1,2,3,4
と変えて四つ横に配置。

これで横4レコードのリストがブラウズ出来ます。

Offline

#10 2017-02-20 16:49:26

写真
Guest

Re: 写真のデータベース

チポ wrote:

表示用のテーブルは一つのみです。

元のテーブルでレコード番号のフィールド、
表示用のテーブルで計算フィールドを二つ
  照合初 = レコード番号 * 2 - 3
  照合終 = レコード番号 * 2 
として、リレーションを
  照合初 <= レコード番号
  and
  照合終 >= レコード番号
とします。

これで元のレコード4つずつが関連レコードとなりますね。
1行ポータルにオブジェクトフィールドを置き、
最初の行を1,2,3,4
と変えて四つ横に配置。

これで横4レコードのリストがブラウズ出来ます。

半分できました。
4個表示するのですが、おかしいです。
伝え難いのですが、一番上の4個は右の2個が空白。
2番目より2個ずつ同じ写真が表示します。
確認です。
リレーションを
  照合初 <= レコード番号
  and
  照合終 >= レコード番号
は左が元で、右が表示ですよね。

1行ポータルにオブジェクトフィールドを置き、
最初の行を1,2,3,4
と変えて四つ横に配置。
は元に作成ですよね。

#11 2017-02-20 17:20:28

シャチ
Member

Re: 写真のデータベース

写真 wrote:

せめて回転寿司屋のiPad?のように写真が一画面に縦横に20個づつ見えればよいのですが。
FMで可能でしょうか?
文化財の写真はどの様に利用されるのでしょうか。

文化財DBの公開は申し訳ないですが予定はありません。
これは、データが著作権に関わるものが多いためです。
悪しからず

写真の利用のアイデア的なものを公開しているものがあります。
https://fm-aid.com/bbs2/viewtopic.php?id=5754
にそのファイルがあります。
こんなこともできるという感じでご覧いただければと思います。

Last edited by シャチ (2017-02-20 19:34:51)

Offline

#12 2017-02-20 17:22:27

チポ
Member

Re: 写真のデータベース

リレーションは
  表示用テーブル::照合初 <= 元のテーブル::レコード番号
  and
  表示用テーブル::照合終 >= 元のテーブル::レコード番号
ですよ。

これで、
表示用テーブルのレイアウトに、
一行ポータルを四つ並べます。

Offline

#13 2017-02-21 09:10:38

チポ
Member

Re: 写真のデータベース

ああ、ごめんなさい。
計算フィールドの計算式が間違っていました。

横4つは
  照合初 = レコード番号 * 4 - 3
  照合終 = レコード番号 * 4 
です。

横にn個は
  照合初 = レコード番号 * n - n+1 = n(レコード番号 -1) + 1
  照合終 = レコード番号 * n 
ですね。


余計なお時間を取らせましたか、申し訳有りません -_-

Offline

#14 2017-02-21 11:40:50

写真
Guest

Re: 写真のデータベース

チポ wrote:

ああ、ごめんなさい。
計算フィールドの計算式が間違っていました。

横4つは
  照合初 = レコード番号 * 4 - 3
  照合終 = レコード番号 * 4 
です。

横にn個は
  照合初 = レコード番号 * n - n+1 = n(レコード番号 -1) + 1
  照合終 = レコード番号 * n 
ですね。


余計なお時間を取らせましたか、申し訳有りません -_-

チポ様
何度も説明いただき大変有難う御座います。
リレーションは表示と元が逆でした。
変更すると正しく表示できました。

n個の計算は
照合初 = レコード番号 * n - n-1
   照合終 = レコード番号 * n 
ではないでしょうか。
6個でテストすると表示できました。

写真表示の無い、空白の行が沢山できています。
空白の行はレコード数とは関係ないです。
写真取込を何度もテストした影響でしょうか?
消すことはできないでしょうか。

又、選択した表示を拡大して見たいのですが。

#15 2017-02-21 11:48:07

シャチ
Member

Re: 写真のデータベース

写真 wrote:

又、選択した表示を拡大して見たいのですが。

これも、前回紹介したファイルに事例が上がってます
直接は
http://yahoo.jp/box/goXNmR
にアクセスしてダウンロードください。

Offline

#16 2017-02-21 12:05:27

チポ
Member

Re: 写真のデータベース

> 照合初 = レコード番号 * n - n-1
違いますよ。

例えば、
  n = 6
  レコード番号 = 1
で試すと
  1 * 6 - 6 - 1 = -1
となっちゃいます、1が欲しいんですよね。


表示用テーブルでは、
レコード番号が1から2、3、4・・・と連続した値が欲しいのですが、
  Get ( レコード番号 )
を使った式を索引保存にして、
レコード削除やソートを変更をすると期待通りにならない場合が有ります。

索引非保存にするとか、
全置換で振り直すとかすればいいですね。


> 選択した表示を拡大して見たいのですが
ポータルのフィールドをボタンにして、
  関連レコードへ移動
でそのレコードのオブジェクトフィールドを表示すればいいでしょう。

Offline

Registered users online in this topic: 0, guests: 1
[Bot] ClaudeBot

Board footer

Powered by FluxBB
Modified by Visman

[ Generated in 0.013 seconds, 8 queries executed - Memory usage: 562.84 KiB (Peak: 583.75 KiB) ]