【FileMakerでWordPress】接続とテーブル構成 — 基本まとめ

WordPress を FileMaker で管理する件について基本のおさらい。接続の準備とwpテーブルの基本をまとめておきます。

FileMakerを使ってWordPressを管理するための基本事項をおさらいします。過去に書いてきたことと同じ内容ですが、多少の知見アップや変節もあるし、以前の投稿から時間も経ってるからいいかなと。詰め込んだのでちょっと長くなりましたがご勘弁を。

FileMaker を WordPress データベースと接続

FileMaker で WordPress を管理するというのは、WordPressの本体データであるMySQLデータベースに接続することを意味します。それには次の準備工程を経ます。

1. SSHでサーバーに接続する — SSH接続します。レンタルの共用サーバーではトンネル接続の設定が必要です。
2. ODBC Managerを設定する — FileMakerで利用するために ODBC接続の設定をします。設定するにはアダプタを購入します。
3. FileMaker使用開始 — ODBC接続してデータベーステーブルを扱い、運用します。

SSH でサーバーに接続する

WordPressのMySQLデータベースにはSSHで接続します。それって何のこと？「インターネットに接続中」みたいな感じで「SSH接続中」状態にします。システム的な奥深い何かがサーバーへの接続を司っているのだと思います。よくわかりませんが、わからなくても何とかなります。

サーバーへの接続を司る奥深い何かに接続せよと命令を下すための接続アプリが各種あります。しかしターミナルを使うのが簡単です。

まずはSSH接続に必要な情報をゲットします。

SSH接続の準備

MySQLサーバーのログインIDとパスワード、公開鍵と秘密鍵、ポート番号などを確認・準備します。レンタルサーバーならサーバー管理のページからSSHをオンにしたり準備のための情報を確認します。

秘密鍵（id_rsa）

SSHの場合、通常のパスワードではなく、秘密鍵公開鍵のペアを作ることになると思います。多分。レンタルサーバーのSSH設定の中に、秘密鍵・公開鍵を作成するページがあるので、それを作って秘密鍵をダウンロードします。

ダウンロードした秘密鍵は一般的にローカルの見えない「.ssh」フォルダ（ ~/.ssh ）に保存します。それがデフォルトのお約束のようです。ファイル名は「id_rsa」にしておくというのが、これまたお約束です。

とりあえずはお約束に従うことをお勧めします。SSH接続のアプリによってはこのお約束に従っていないと動作しないこともあります。後述の、config を使って自分で設定するなら「id_rsa」名は必ずしもお約束に従う必要はありません。複数の秘密鍵を用意することもあり得ますしね。

※ ~/.ssh はMacでお約束のフォルダです。Windowsの場合は同じ目的のそれなりのパスに読み替えてください。それがどこかは知りませんので、すいません。

トンネル接続

SSHをオンにして情報を確認して秘密鍵を手に入れても、レンタルサーバーの場合はMySQLサーバーにはまだ接続できません。迂回して接続（トンネル接続）する必要があります。何ですかそれは？わかりませんが、ポート番号を噛まして迂回するんです。なんのこっちゃ。判らなくてもこの後を読めば誰でも設定できます。

.ssh に configを作成

SSH接続アプリも各種ありますが、アプリの設定をしないと使えません。でもその設定に何を書くかがわからんのだよ。ということで、自分で管理してターミナルで接続したほうが手っ取り早いと思うので、以下その方法です。config というファイルを作成して、お手本に従って設定します。

見えない「.ssh」フォルダ（ ~/.ssh ）に 「config」 を作成ます。拡張子なしの「config」です。テキストエディタで編集します。

config を作っておくとターミナルから簡素なコマンドで簡単に接続できるようになります。例えば「host digitalboo」を設定しておけば、ターミナルで

ssh digitalboo

リターンで接続できます。

書き方は以下の通り。

記入例 — 例えば以下のように書きます。

Host digitalboo
HostName localhost
port 10022
User ****
IdentityFile ~/.ssh/id_rsa_digiboo
LocalForward 2022 localhost:3306
ServerAliveInterval 120
AddKeysToAgent yes
UseKeychain yes

hostName（MySQLサーバー名）ですが、MyAdmin で示されているのがそれです。

Xserverの場合、以前は sv10999.xserver.jp みたいな名前でしたが、今は localhost になってます。そんな名前でええのんか？と思わなくもないが、それで良いんです。

次に謎なのは LocalForward 欄ですね。例ではこう書きました。

2022 localhost:3306

最初の2022は任意のポート番号ということで、何でも良いと教わりました。何でも良いと言ってもそうはいかないですよね？1とか60000000000でもええのか。そんなわけないので、人に「何でも良い」と教える前に己の「何でも」が狭い常識に囚われていないか再考してください。それはいいとして、かつて2022と適当に書いたら繋がったのでそれ以来あほみたいに頑なに2022と書いています。この数字は後でODBCの設定を作るときにも使います。同じポート番号であることが重要です。

次の localhost:3306 の localhost は問答無用で「localhost」と書きます。3306 も意味は知りませんが誰かにそう書けと教わったのでそれ以来一途に守っています。多分、MySQLサーバーに外部から繋げるお約束のポート番号ではないかと思いますが真相は知りません。

というようなことでconfigの設定が完了したら接続できるようになります。

ターミナルを起動して、例ならssh digitalboo とタイプしてリターンすれば接続できます。接続中はターミナルウインドウをそのままにしておきます。終わったら exit で終了します。

この接続している状態でODBCを設定したり、FileMaker で作業をするわけです。

ODBC Manager を設定する

SSHで接続した先はMySQLサーバー全体です。接続中のターミナルウインドウにコマンドをタタタっと入力して狙ったデータベースに直接命令を下すことができます。データベースの達人ならそれだけで事足りるのかもしれません。しかしそんな賢いことができない私たちは FileMaker で作業するのです。

FileMakerに接続して作業するためにはODBC接続という技術を使う必要があるので ODBC Manager を設定します。

/Application/Utility に ODBC Manager がなければ、こちらからダウンロードしてインストールします。

ODBC Manager を起動してシステムDNSを設定します。

設定するために専用アダプタが必要です。actual technologies 社に出向き Open Source Databases を購入します。厭だ買いたくないと言っても買わないと何もできません。

購入したらデータベースごとにシステムDNS設定を作ります。

actual technologies社のコンフィグアシスタントが出てくるので設定を埋めます。

ここで作った設定により、FileMakerから個別のデータベースに接続できるようになるという案配です。

設定ファイルの在処

ところで設定したその内容はどこに保存されるでしょうか。ユーザーのpreferenceフォルダでしょうか？ 違います。Macなら /Library/ODBC です。ルートのLibraryフォルダ内でした。

ODBCフォルダには例えばこんな感じでファイルが作られます。実際の設定が書かれているのは odbc.ini ですね。

odbc.ini を開くと、ODBC Manager とアダプタによってどのような設定が成されたのか一望することができます。

odbc.ini はテキストエディタで編集することもできますが、ルートのライブラリフォルダ内ですから上書き保存はできません。他の場所に一旦保存してファイルを入れ替えることはできます。

設定をたくさん作る必要がある場合は、ODBC Manager とアダプタでちまちま作るより odbc.ini を編集したほうが手っ取り早いこともあります。どのように書かれているかをよく見て、フォーマットにそって書き足したり編集したりできます。よくわからないならodbc.iniを触らず、設定アダプタのアシスタントに従いましょう。

FileMaker で接続する

では FileMaker で接続して実際の運用を開始します。SSH接続状態であることを忘れずに。

データベース設定のリレーションシップ画面で、新規「ODBCデータソースに接続…」を選択すれば必要な項目を埋めるためのダイアログが出てきますので埋めます。これだけで、WordPressのテーブルを追加できます。

DSN: の「指定…」をクリックすると ODBC Manager で作った設定名が現れますから選択します。ユーザー名とパスワードは MySQLサーバーのユーザー名とパスワードです。これでリレーション画面に指定したMySQLのデータベーステーブルがテーブルオカレンスとして登場します。

普通のFileMakerのテーブルオカレンスと同じように扱えるのでレイアウトに必要なフィールドを並べて運用します。なんて簡単なのでしょう。

 

以上、SSH、SSHトンネル接続、config、FileMakerでのテーブル追加までのおさらいでした。

ちょっと端折り気味なので、もうちょっと詳しく説明できんのか。と思われたら、このあたりに詳細の過去記事があります。

→ FileMaker Pro を MySQL サーバーに接続する その1
→ FileMaker Pro を MySQL サーバーに接続する その2 SSHトンネル
→ FileMaker Pro を MySQL サーバーに接続する その3 FileMaker の設定
→ SSH トンネル接続を config で賄う

では実践的に進めましょうか。・・・と思いましたがその前に小ネタを一個挟みます。FileMakerからの接続についてのオマケネタです。

FMファイルを開く際のかんたん接続

SSHで接続した状態でFileMakerの作業をするわけですので、FileMakerでの作業前にSSH接続状態にしておかなければなりません。

SSH接続はターミナルでかんたんなコマンドを走らせるだけですが、この一手間が地味に面倒で、うっかりSSH接続を忘れたまま先にFMファイルを開いてしまいます。

決して終わることのないクエリ待ちのダイアログを前に「しまった」とキャンセルして開き直す羽目になります。

この度重なる失態に嫌気がさし、何か手立てはないものかと思いついたのが、FileMaker で接続アプリのような役割のファイルを作っておくことでした。

この単機能の小さなFMファイルは、開くとSSH接続し、閉じると解除します。接続するとウインドウ名が「停止中」から「接続中」に変化します。

この小さなファイルを開くだけで自動で接続できるようになりました。じゃあ本番ファイルを開く前に忘れずにこいつを開くのね。違います。本番のFileMaker ファイルの起動スクリプトの中で、最初にこいつを自動的に開くんです。これで事前にSSH接続を行う一手間を完全に省略できました。

このファイルの詳細はここでは端折ります。興味があれば過去投稿をご参照ください。

→ FileMaker で SSHトンネル接続をもっと簡素に行う

もちろん、こんな変なものを作る手間よりターミナルを起動してタタタっとタイプしたほうがよほど良いわ。という考えも尊重します。

WordPress データベーステーブル

FileMakerを使ってWordPressを管理していきます。データベース設定のリレーション図からWordPressのテーブルを配置していきましょう。

WordPressのデータベース構造の基本

その前にせっかくなのでデータベーステーブルの基礎をおさらいしておきます。

図はWordPressデータベースのテーブル構造。今はなき WordPress codex にこの図がありましたね。

wp_posts を中心とした構造が見て取れます。wp_posts の ID にぶら下がるのが postmeta（カスタムフィールド）と term_relationships（カテゴリーやタグなどのタクソノミー）です。

図には載っていませんが今は wp_termmeta というテーブルが wp_terms にぶら下がっています。（wp_termmeta は taxonomy のカスタムフィールド）

これらテーブルをFileMakerのリレーション図の画面で追加し繋げます。

wp_posts と wp_postmeta

上の囲みは wp_posts と wp_postmeta です。最低限、この二つがあれば投稿、ページ、カスタムポスト、メディア、そしてカスタムフィールドが扱えます。

wp_term_relationships 関連

下の囲みはタクソノミー関連です。カテゴリーやタグその他タクソノミーを管理するなら配置します。

taxonomy というのは、カテゴリーやタグの総称です。宇宙の全てはキーと値で出来ていますが、taxonomy ではキーが taxonomy名、値が term です。

カテゴリー「記事」ってのがあったとすれば、taxnomomy名が「category」値が「記事」です。
タグ「FM」ってのがあったとすれば、taxonomy名が「tags」値が「FM」です。

taxonomy関連テーブルでは、この「値」が term_id になっていて、term_id とは即ち wp_terms テーブルの id です。wp_terms には name や slug があります。カテゴリー「記事」の値部分は、term_id が xx の name が「記事」ってことです。

taxonomy に親子関係あってそれが必要なら親や子のテーブルオカレンスを作ってこれにぶら下げれば良いでしょう。taxonomy なら parent フィールドに term_id が納められています。

taxonomyが何階層あるか、親の詳細情報が管理上重要か、そういうことを考えて、必要なら parent をテーブルオカレンスとして配置すれば良いでしょう。

親はいらんかな

長年 parent を繋げて親のテーブルオカレンスを作っていましたが、よく考えると重要な役割があるでもなく、名前さえ判れば良いだけの場合がほとんどだと気づき、親をわざわざ配置することを最近は辞めました。

親の存在と名前だけ必要な時、FileMaker ではあっちでウインドウを広げて検索し、こっちへ持ってきてなどとスクリプトが煩雑になるので、テーブルオカレンスを繋げるほうがましでした。

でもデータベースクエリの関数を使えばテーブルオカレンスもウインドウも介さず直接親の名前をゲットできます。これまで怖くて避けていた ExecuteSQL関数ですが、親のidや名前くらいなら何とかなりました。

スクリプトの中で taxonomy_id やterm_id や parent などをゲットしつつ何段階かの計算を行います。

ExecuteSQL ( "
  SELECT name
  FROM wp_terms
  WHERE term_id =" & $parent & " " ;
 "" ; "" )

これだけ書いても意味不明ですが、こんな程度の計算を繰り返して親の階層を取得してレイアウト内で利用するわけです。

今のところ、親子のテーブルオカレンスをわざわざ作らなくても問題ないです。配置するテーブルはなるべく少ない方が良い。

wp_options

普段使うことはあまりありませんが、管理上避けて通れないテーブルが wp_options です。

wp_options にはWordPressの根幹となる重要な情報が納められていますが、多くのゴミデータにも満ちています。長年WordPressを使っているとゴミが溜まり、wp_optionsが肥大化します。

wp_options のクリーンアップは、手動でちくちく探して消す以外の方法がありません。その作業をFileMakerで補助します。この話はいずれ別の投稿で。

と、思ってる間に先に書いたので ↓

wp_options テーブルを監視する [FileMakerでWordPress]

テーブルの主なフィールド

メインとなるテーブルの主なフィールドについても触れておきましょうか。

• wp_posts
  • ID … ID
  • post_type … postは投稿、pageは固定ページ、attachmentはメディア
  • post_status … publish（公開済み）, draft（下書き）, private（非公開）など
  • post_name … スラッグ
  • post_parent … page なら親ページのID、attachment なら貼り付け元のID
  • post_excerpt … 抜粋
  • post_content … 本文
  • post_mime_type … attachment の種類。例: “image/jpeg”
• wp_postmeta
  • post_id …posts の ID
  • meta_key … キー
  • meta_value … 値
• wp_term_relationships
  • object_id … posts の ID
  • term_taxonomy_id … term_txonomy の id
• wp_term_taxonomy
  • taxonomy … タクソノミー（category, tags など）
  • description … 説明
  • parent … 階層があって親があれば親のterm_id
  • term_id … terms の ID
• wp_terms
  • name … ターム名
  • slug … スラッグ
• wp_termmeta
  • term_id
  • meta_key … キー
  • meta_value … 値

wp_posts の post_type について理解しておきましょう。投稿や固定ページやメディアやメニュー項目などすべて同じものです。post_type が「post」なら投稿、「page」なら固定ページ、「attachment」ならメディアなだけです。

post_status は「draft（下書き）」「publish（公開済み）」などの状態です。attachment なら「inherit（継承）」になってますね。

FileMaker での管理 実践の基本

では FileMaker で WordPress 管理の実践です。ここからは目的や好みによってそれぞれの話なので、参考程度に。

レイアウト

WordPressの主要テーブルを配置するだけでも、結構いろいろなことができます。

左にセルフポータルを置いてレコードのリスト表示、右には postmeta と relationships をそれぞれポータルで配置します。

中央部分は、レイアウトの目的や post_type に応じていろいろ変えます。上の図ではWebビューアをでっかく配置。ボタンをいくつか仕込んで、公開URLとエディタURLを切り替えたりできます。下の図はエディタ画面が表示されているところ。

Webビューアでまともに表示したり編集するには大きなモニタ環境が必要なので、ラップトップ用を兼ねて該当ページをブラウザで開くボタンも設けています。

本文の確認や修正が主な目的なら post_content を配置します。

FileMaker では、post_content の表示にちょっとだけ難があります。改行が増えて間延びするんですね。Webビューアに編集画面を表示するほうが使い勝手が良いと最近は思ってます。content を配置することはめっきりなくなりました。

下図は post_type が attachment、つまりメディアの場合です。Webビューアには公開URLではなくメディアファイルのURLが表示されるようにしています。

メディアファイルのURLを得るには、先に postmeta の _wp_attached_file から値（相対パス）をゲットしておく必要があります。それをサイトURLと合体させてURLを作成します。

以上、ベーシックなレイアウト例をいくつか挙げました。

ローカルのテーブル

wpテーブル以外に、ローカルにいくつかテーブルを作ることで応用範囲が拡大します。便利な機能や仕掛けもローカルテーブルなしでは作れません。

wp_posts にぶら下がる Local Data テーブル

posts の ID で照合してぶら下がるローカルデータのテーブルです。

WordPressのwp_postsに勝手にフィールドを追加することはできませんので、ローカルテーブルにフィールドを追加します。

ローカルデータのテーブルにぶら下がるmetaテーブルなんかも、必要なら作ります。

こればっかりはサイト運用の目的次第ですので、フィールドについてああだこうだと決めてかかることはできません。

気をつけたいのは、WPテーブルのフィールドと同じフィールドを置こうとするときです。同期の問題が発生しないようにしたいものです。同期についてはこのページの終わりのほうに。

term_taxonomy_id で繋がる taxonomyのセット

taxonomyは扱いが面倒なので、taxonomy_id で繋がるローカルのtaxonomyを作っておくのも良いかもしれません。

taxonomy がたくさんあって管理が複雑なら作っておくと便利です。複雑でないのなら無理して作ることはないでしょう。後ほど「よく使う仕掛け」で少し詳しく。

グローバルフィールドを集めたテーブル

他によく使う手口は、グローバルフィールドだけを集めたテーブルです。検索用のダミーフィールド、「サイトURL」のような初期設定的なフィールド、一時データ置き場など、便利系グローバルフィールドの寄せ集めテーブルです。あれば便利と思います。思わない方がいても尊重します。このあたりは好き好きのレベルですね。

よく使う仕掛け

FileMakerでの管理上、またはレイアウト上でよく使う仕掛けがあります。いくつかをご紹介。

ソートボタン

左側のリスト表示に欠かせないソートボタンです。以前は作るのに手間かかりましたが、今は良い方法を知ったのでサクッと作れます。

これはローカルにテーブルがなくても実現できます。

詳細 → FileMaker ソートボタン

type と status のフィルタ

リスト表示にソートと並んで欠かせないのが post_type と post_status のフィルタです。ポップアップで絞り込みます。

これはグローバルなフィールドがないと成り立ちません。検索するための入れ物として使用します。

グローバルフィールドにtype と status それぞれ値一覧を仕込んで二つのフィールドから検索させます。スクリプトは type と status に特化させています。たとえば post_status に inherit を選んだらそれは問答無用にpost_type: attachment ですよね。そういう実態に即した条件を含めることで、選択の面倒さをそぎ落とし、実践的にフィルタできるようにしています。

本文に貼り付けたメディアのIDをリスト – attach_ids

local_data テーブルのフィールドに値を格納するタイプの仕掛けです。

attach_ids は、投稿（post_type = post）やページ、それに準じるポストタイプで使用します。

アイキャッチに設定した画像と、本文に貼り付けたメディアのIDをリストします。配置したメディアの把握に便利です。

詳細 → 投稿に使用したメディアをリストする

投稿に使用したメディアをリストする [FileMaker で WordPress]

postmeta からフィールドに昇格

postmetaには利用しがいのあるシステマチックなデータも格納されています。そのままでももちろん利用できますが、あえてフィールドとして昇格させるということをよくやります。

postmeta をポータルで表示しているので、ゲットするスクリプトではポータル行をループして狙ったmeta_keyの値を直接または別の処理を施してからフィールドに書き込みます。

たとえば以下のようなmeta_key の値をフィールドに昇格させています。

_wp_thumbnail_id

投稿や固定ページのアイキャッチ画像のIDです。localDataテーブル内のフィールド名を「_wp_thumbnail_id」と、meta_keyに合わせています。

_wp_attached_file

メディア（post_type = “attachment”）に作られる _wp_attached_file は、メディアファイルの相対パスです。/wp-content/uploads 以下の日付から始まるパスです。

サイトのURLと合体させてファイルのURLを作成し、メディアパスとしてフィールドに昇格させています。

_wp_attachment_metadata

メディアに関するデータがまとめて格納されています。イメージの各サイズやメタデータなどです。これを分析してJSON書式でフィールドに格納しています。

_wp_attachment_metadata の解析については以下に詳細があります。

詳細 → _wp_attachment_metadataをJSONに変換して利用

FileMakerでWordPressの_wp_attachment_metadataをJSONに変換して利用

taxonomyセットのテーブル

postmeta は扱いが簡単ですが、taxonomy はテーブルが分かれているので少々厄介です。term_taxonomy_id からターム（名前・値）を特定するのは簡単ですが、名前・値からterm_taxonomy_idを特定するのが面倒なんです。

解決の一つの手段ですが、taxonomyの関連テーブルをまとめたファイルを作ります。作るというか、ダウンロード（エクスポート）するんです。

term_taxonomy_id、taxonomy名、term_idとtermsのname、階層があればparent と親termsのidとname、これらを一つのテーブルに詰め込みます。

wpテーブルでレイアウトを作り、そのレイアウト上のフィールドを、用意しておいたテーブルにまとめてエクスポートするんです。複数テーブルに分かれていた個別のデータが一個に収まります。

これをtaxCatalogと名付けて参照用に利用しています。参照したり、値一覧を作ったりします。name から term_taxonomy_id を直接得られるので、フィールドのテキストを元にした term_relationships への登録が簡単かつ直感的に行えます。

taxonomyを多く使用しているサイトでは特に有利。taxonomy がさほど多くなければ余計な手間をかける必要はないと思います。

FileMakerでWordPressを管理編集する秘訣

最後に、FileMaker で WordPress を管理するファイルを作っては捨て作っては捨てを繰り返してきた者が学んだ秘訣みたいなことを書いておきたいと思います。

同期を避ける

ずっと以前、ODBC接続が遅くて使い物にならなかったころ、リモートのWPテーブルと同じものをローカルにも作り、編集をローカルでやって後で同期するという仕組みを作ろうとしていました。しかしこれには大きな問題がありました。

同期には手間と労力がかかります。事細かにログを記録したり、フィールドごとに変更日付の記録を取ったり、wpテーブルのフィールドとの内容比較を常に行ったりします。その仕組みだけでフィールドやスクリプトが膨れ上がります。

さらに、WebサイトとFileMakerでどちらからもフィールドが変更されていた場合、どっちに合わせれば良いのか判断できなくなります。日付が新しいほうが常に優先とも限らないし、編集した当の人間にさえどっちを採用すれば良いのか分からなくなることがあります。

この問題を発生させないように工夫するのが得策です。今は以前と違い、速度もかなり改善されていますし。少なくとも、リモートのテーブルと同じものをローカルに複製して編集するなんてことは避けます。

• WPテーブルのフィールドと同じローカルフィールドを作らない
  必要もないのにローカルにリモートと同じフィールドを作らないのがまず原則です。作っても参照用、読み込み専用と心得ます。
• WPテーブルを複製したローカルテーブルを編集しない
  リモートテーブルと同じローカルテーブルを作る場合、それはバックアップ目的、あるいは参照目的と割り切ります。
• WPテーブルのフィールドかローカルフィールドか、優先するほうを決める
  リモートを優先するならローカルの同名フィールドは編集しません。リモートとローカルで差異が見つかればリモートのデータで上書きします。
  ローカルを優先と決めるのなら、Web上で編集されていても無視してローカルのデータで常に上書きします。フィールドごとでもいいので、これを徹底させます。
• 優先を決められないフィールドには細心の注意を払う
  優先が決められないならそれはシステマチックな仕組みではなく人間がよーく見て判断するという決着方法しかありません。そういうフィールドがあってもいいですが、最小限に留めましょう

全部賄おうとせず、ファイルを分ける

一つのFMファイルで全部を賄おうとしないことです。テーブル同士の絡み合いも可能な限り最小限にするべきで、それが後々のメンテしやすさにも繋がります。

複数サイトを管理している場合だとファイルの使い回しも考慮に入ります。一個のファイルに特定サイトの複雑な仕組みを詰め込んでしまうと使い回しができません。闇雲にファイルを分けすぎても不便になるけど、目的に応じて分けるというのは良い考えです。

そもそも一極集中の「選択と集中」みたいな全体主義的思想はいずれ行き詰まり崩壊します。肥大化し修正不能化し小さな失敗が全体の命取りになります。役割に応じて分散することがリスクへの心構えであり文明人の考え方です。

日本や北朝鮮のような都市機能を極端に集中させる全体主義国より、各地域がそれぞれの特性ごとに独立して成り立っている国のほうが豊かであることは明白で、FileMakerのファイルも社会も根本的には同じということですね。最後になって何言ってんだこいつ。