WordPress のデータテーブルを MySQL から CSV でエクスポートして FileMaker Pro にインポートした前回の記事の続きです。今回は FileMaker Pro のリレーションを組んでみましょうというお話ですがどんでん返しもあります。
FileMaker Pro でリレーション
前回の記事「FileMaker にWordpressデータベーステーブルのCSVインポート」で CSV ファイルをインポートした FileMaker Pro の書類を一つのファイルの中にテーブルとしてさらにインポートしました。
これらのテーブルがどのように関係し合っているか、WordPress のデータベース構造を見ても判りますが、見なくてもフィールド名を見れば判ります。
基礎的なリレーション
FileMaker で楽しいリレーションを組み立てていきましょう。「データベースの管理」の「リレーションシップ」タブを開きますと、あらかじめ各テーブルのパーツが入っています。これをドラッグして移動したり、フィールド名同士を繋げたりします。
まず基本となるのが posts ですね。ID というフィールドがあります。試しにこれをカスタムフィールドのテーブルと繋げてみましょう。カスタムフィールドは postmeta です。postmeta の post_id が post の ID とリレーションシップされます。ドラッグして繋げます。
こんなのわざわざムービーにしなくていいんですが、忌々しいQuickTime X プレイヤーにもいいところがあって、画面キャプチャムービーが簡単に撮れるんですね。ただし撮ったキャプチャ動画を切り取るにはQuickTime 7 プレイヤーを使いますけど。そういえば完全にQuickTimeは終焉を迎えたそうですね。終焉したと言われましても、代替もないし、どうしていいやらわかりません。余談でした。
ということで、posts の ID と postmeta の post_ID を繋げました。これにより、posts テーブルでのレイアウトの中に postmeta のデータを挿入したりできます。
同様のやり方で次はタクソノミー行きます。
まず posts の ID と relationships テーブルの object_id を繋げます。
次に relationships テーブルの term_taxonomy_id と term_taxonomy テーブルの term_taxonomy_id を繋げます。同じ名前なので一目瞭然ですね。
さらに term_taxonomy テーブル の term_id と terms テーブルの term_id が繋がりますね。
これが基本的なリレーションです。
これで大体のことは補えるのですが、少し追加もあります。それは「親」に関する事柄です。
parent に関する追加のリレーション
ポストにもタクソノミーにも親子関係というものがあります。もしこれを FileMaker で管理したいなら親子関係のリレーションも作ってやらねばなりません。管理不要なら特に設定しなくても問題ありません。
例えばカテゴリーの親子関係ありますね。term_taxonomy テーブルに「parent 」がありまして、これが何かというと、親のタクソノミーIDなんです。親子関係をリレーションするには、term_taxonomy テーブルの parent フィールドと、term_id をリレーションしてやることになります。
無理矢理作成しようとすると、自己連結リレーションにはテーブルを追加する必要がある旨のダイアログが表示されます。
そんなわけでこうなりますね。
これだけで終わればいいんですが追加したテーブルにも terms テーブルを繋げてやらないと名前などのフィールドが使えません。そこで terms に繋げてやろうとすると今度はこんなダイアログが表示されます。
親の親を管理しようとすれば同じようなセットがもうひとつ必要になってきますね。
このように、複雑なリレーションをどんどん作っていくと目的が違う同じテーブルが複数存在してきます。実際にデータベースのフィールドを配置していくときにどの目的のどのテーブルかが判らなくなってきます。混乱してきますからリレーションごとにきっちり名前を付け、切り分けるのがいいです。この場合は親を照合しているので名前に「親」と書き足しています。
リレーションシップ画面ではテーブルに色を付けることも出来るので、名前と同様、色を付けておくのも判りやすくていいと思います。
タクソノミーの例ではこのようになりました。この調子で posts の親をリレーションし出したらどうなりますか。リレーションがねずみ算式に増えますね。ですのでこれは必要かどうかを使う人が目的に応じて判断して決めます。
私の場合は posts の親子関係もリレーションをひとつ作りました。ただし、親にぶら下がるねずみ算式リレーションは省略して、posts のみを親として追加しました。「IDさえ判れば良い」という使用上の考え方によるものです。
FileMaker Pro でデータを表示する
実際に FileMaker でどのように表示したり操作するかは運用する人次第なので立ち入ることは出来ませんが、リレーションを組むことによってどういう表示が出来るか、基礎的なことだけちょっと書いておきます。
例：ID、タイトル、スラッグにタクソノミーを表示
例えば posts のテーブルありますね。新規レイアウトを作って、ID と post_title、post_name（スラッグ） をとりあえず置いてみまして、その画面にカスタムフィールドとタクソノミーも置いてみます。
タクソノミーのポータル
posts にぶら下がっているタクソノミーテーブルの最初の肝心なものは relationships です。relationshipsの下にタクソノミーやタームがぶら下がってますからね。ですので relationships のポータルをまず置きます。
このポータルには relationship 以下ぶら下がっているテーブルのフィールドが置けます。試しにタクソノミーの名前とタームを並べておいてますと、このようにブラウズされます。
表示してみて気づくこともありますね。肝心なフィールドが抜けていて不親切です。「ポストタイプ」や「ポストステータス」など基本的な情報がないと混乱の元ですね。
もうひとつ、タクソノミーもすべて表示されています。ポータルに条件を付け加えることで、例えばカテゴリーだけ、タグだけといった絞り込み表示を行えますね。
ポータルレコードのフィルタ
サンプルついでにちょっとやってみます。ポータル設定で「ポータルレコードのフィルタ」を指定します。
計算式の指定画面が現れて、ここで計算式として指定します。FileMaker に慣れていないと書き方がさっぱりわかりません。ヘルプを見たり適当にトライアンドエラーしているうちにだんだん判ってきます。
計算式の画面で 「term_taxonomy テーブル」の「taxonomy」が「category」である、てな指定をしてやります。
ブラウズしてみるとカテゴリーだけを表示できました。フィルタを使うとこのように絞り込んで表示することが可能になります。多用することになると思います。
運用上ローカルのテーブルを作る
このあたりまで来るとまた少し気になって思いつくこともあります。大事なテーブルデータを直接いじくり回すのが不安になってきます。そこで、新たにテーブルを作りたくなってきます。それはローカル専用のテーブルです。
WordPressのデータベース構造から自分の都合の良いローカルのデータベーステーブルを作ってはどうだろうと、誰しも思い立ちます。思い立ちませんか。思い立ちます。
そこで私は「local_posts」というテーブルを作って、基本 posts に準じたフィールドを作成、posts とさまざまなリレーションを組みます。
ついでにtaxonomyやpostmeta何かも必要な部分だけローカル版を作り、それを下書きがわりに使用して運用しはじめました。
さらに、全然別のローカルテーブルを作って独自のリレーションを作ってみたり、それなりに手の込んだ自分にとってだけ便利な FileMaker のファイルとなってきたわけです。
例えば Brigde なんてテーブルを思いついてですね、これ何をするのかというと、タクソノミーとカスタムフィールドを合体させ単純化させたテーブルで、ローカルファイルの容量は爆裂的に増えますがリレーションの複雑さを軽減させさらにカスタムフィールドとタクソノミーの一覧性や相互変換性能などを持つ優れもの。最終的には postmeta や taxonomy に出力することができる自慢の一品です（追記：何を言ってるんだか。数年後、ややこしさに辟易してこの自慢の一品とやらは削除してしまいました）
あとは入力補助用の、いわばタームとメタバリューの合体単純化版とか、いったい何の目的があってこんな凝ったものを作ってるのかと呆れるような複雑怪奇なFileMaker書類となっていったわけです。
最終的な出力の目的
そうなんです。ここ Digital Boo というブログの著者の特徴を一言で表すと本末転倒です。毎度毎度この調子で、本来の目的を忘れ、何か別のことに打ち込んでしまいますね。つまりあほなんですね。
知恵熱にうなされ頭から湯気を出しながらふと「で、こうやってFileMaker で調整や変更をして、それでそのあとどうするんだ」と、最初の目的を思い出します。
テーブルを CSV で書き出して MySQL データベースにインポートする
でした。でした。これするためにやってるんでした。つまり、ちまちま修正するんじゃなくて、大きな変更をローカルで行ってから書き出し、丸ごとデータベースにインポートして楽をしようとしていたわけでした。すっかり忘れていました。
FileMaker で遊んでいる場合ではなくて、変更したものをCSVで書き出したあと、それをMySQLにインポートするという難易度の高いその方法をちゃんと学んでおくのが先ではないかとやっとのことで気づきました。
CSVをMySQLにインポートするためのコマンドを検索して調べているうちに「なんでこんなややこしいことをしなければならんのだ」という気持ちがふつふつと沸いてきます。というか難易度高すぎて早々に「無理」と判断してしまいました。
興味のある方は「CSV mySQL インポート」で検索し、さまざまな賢い人たちの解説を読みましょう
で、CSV でのインポートが難易度高すぎて諦め入ってきて、今までの苦労は全部無駄であったか、とぼんやりコーヒー飲んで煙草吸ってると、ふと仙人になりました。
エクスポートしてインポートして加工してエクスポートしてインポートする。
この無意味な連鎖の言葉はどういうことだろう。まるで、休まず働いて金貯め、貯まると仕事をせずに休む。みたいな、まるで不思議な話です。言葉を数字とするならば、打ち消しあってこうなるのではないか。
エクスポート – インポート – 加工 – エクスポート – インポート
加工だけすれば何の手間もいらないではないか。そう言えば昔風の噂にこんな言葉を聞いたことがあったぞと薄らぼんやり思い出します。
FileMaker Pro バージョンXX で 〜〜 に接続することが可能になりました。
当時この言葉は何も響きませんでした。もしかしたら 〜〜 には SQL とかって言葉が入ってなかったか。
FILEMAKER と MYSQL の接続
早速検索してみると、いきなりFileMaker社のページがヒットします。
外部 SQL データソースの概要
FileMaker Pro は、SQL データソースにライブ接続することができます。
外部SQLデータソースとの接続 | FileMaker
これまで散々な目に遭いながらエクスポートしてインポートして変換してあれこれあれこれやってきましたが、最初からこういうことが可能という衝撃の事実でした。知恵熱でうなされ頭から湯気を出しながらFileMakerのレイアウトやスクリプトを作りまくった日々は全くの無駄になってしまったということでしょうか。
いや、世の中に無駄なものなんてのはない。仮に無駄があるとして、無駄というのは宇宙で最大に重要かつ必要なものだ。無駄と非合理こそ究極のエコロジー、文明が至る神の領域に最も近いものである。
などと戯言を言いながら「これが出来るんならこれでええやん」と、るんるん気分でそのやり方を辿ります。ちょっとややこしくてもSQLのコマンドよりは楽に違いない。るんるん。
FILEMAKER と MYSQL の接続 は次のポストにつづきます。
