SSHトンネル接続でMySQLサーバーに接続したFileMakerでWordPressを管理するシリーズを書いてから何年も経ちますが今回はいきなりその続き、タクソノミーについてです。
タクソノミーのリレーションシップ
タクソノミーはpostmetaの単純明快さに比べて少々ややこしくなります。基本、次の三つのテーブルが絡み合い、タクソノミーを成立させています。
term_relationships
term_relationshipsテーブルはポストに繋がるIDとterm_taxonomy_id だけがセットになったテーブルです。まずこれがあります。ポストとタクソノミーを結びつけます。postmetaに例えてもいいと思います。postmetaはidと自身のデータ（keyとvalue）をテーブル内に持っていますが、relationshipsはidだけです。データ部分はtaxonomy_idのみであって、実際の値はterm_taxonomyテーブルから引っ張ってきます。
term_taxonomy
term_taxonomyテーブルは taxonomy_id、taxonomy、term_id、そしてparent（親termsのid）のフィールドがあるタクソノミーのセットで、これが言わばタクソノミー本体部分。分類データベースです。ちょっと変わってるのは、値そのものがこのテーブルにないってところです。term_idだけがあります。実際の値は次のtermsが受け持っています。
terms
termsテーブルにはterm_idとname、slugのフィールドがあります。termsの具体名はここにだけ格納されています。
FileMakerのリレーションテーブルで再現するとこんな感じです。
parent（親）は、カテゴリーやタクソノミーに親子関係がある場合にterm_idと繋げていくと、レイアウト画面の中で親の表示も一緒に可能になります。親の親まであるときは図のように親の親もリレーションしておいたりします。親の親の親がある場合にはもう一個リレーションを追加するとレイアウトの中で表示できます。
なぜタクソノミーがこのようなそれぞれのテーブルに分散されているのかと思うかもしれませんが、これがなかなか合理的で、階層を作るときや、分類が異なるnameの重複がある場合などに無駄なく対応できます。それに、postmetaは常にpostに紐付いたオマケ情報ですけど、タクソノミーはポストなしでも成立する独立したデータベースの固まりですんでね。
FileMakerでの運用
さてこのタクソノミー、実際の運用では例えばカテゴリー、例えばポストタグ、またあるいはカスタムタクソノミーなど、作っているサイトによってシンプルさ複雑さはさまざまでありましょう。私個人が作っているもので言えば、このDigitalbooではすごくシンプルな運用ですし、Moviebooでは複雑怪奇な運用になっています。その複雑さによって、運用の仕方はまるっきり変わってきます。
ローカルにtaxonomyおまとめデータベーステーブルを作成する
いろいろ試行錯誤した結果、relationships、term_taxonomy、termsの三つのテーブルを一纏めにした、いわば「taxonomyおまとめデータ」をローカルに作成するのが良いと結論づけました。
（もちろん、タクソノミー絡みの編集がほとんど必要ないならローカルにわざわざ作る必要ありません）
ローカルにtaxonomyテーブルを作りましょう。このとき、ローカルテーブルに二種類の考え方があります。考え方は二種類ですが、作成するのは一つでも二つでも。どっちでもいいです。必要に応じてすが、それが何かというとこれです。
カタログのように
ひとつはタクソノミーカタログです。テーブルでいうと、term_taxonomyとtermsを合体させたものです。端的に、term_taxonomyのterm_idから termsのnameをくっけただけのものです。
これによって、タクソノミーカタログが完成します。
単にtaxonomyテーブルにtermsテーブルから name を合体させただけなのですが、一つのテーブル内に収まること自体が重要なのでございます。これにより、nameからterm_idを引っ張ってこれたり、taxonomy idからnameを引っ張ってきたりできます。
タクソノミーカタログは値一覧でフィールドを使用したり、単にカタログ的に参照したり、小粋な使い回しで利便性があります。
私はこれを「local_tax」と名付けて運用しています。
taxonomyにtermsのnameとslugを追加、ついでに階層用にparent_name、そしてシステマチックな「更新スタンプ」という変更があればチェックされる同期の際に使うフィールドを作っています。
postmetaのように
もう一つはterm_relationshipsテーブルを基調にした「リレーション済みの網羅データ」です。これはつまり、postmetaテーブルと同じような使い勝手を得ることが目的です。
post_idとtaxonomy_idが基本にあり、これがポストとタクソノミーを結びつけます。そしてこのtaxonomy_idのタクソノミーの「タクソノミー」とさらに「termのname」を合体させるわけです。
すべて合体させたリレーション網羅データは、ローカルで肥大化します。肥大化しますがこれも使い勝手がよくて、複雑な利用をしている場合にはなくてはならないデータとなります。
こちらは若干複雑な運用をしているので、更新スタンプの他、同期の際のチェック用フィールドを複数作っています。これについていつか説明するときがあるかもしれませんがないかもしれません。
ということで、taxonomyに関するローカルデータを用意して、これらを使用しながらFileMakerの運用を行います。
ポータルを使ってレイアウト上に表示して運用する
FileMakerのリレーションでローカルtaxオカレンスを正統に繋げてあげることによって、タクソノミーをシンプルに表示できます。
ポータル内に漠然とタクソノミー全部を表示するもよし、フィルターを使って特定のタクソノミーだけを表示させるポータルを作っても良しです。
特定タクソノミーだけを表示する専用ポータル
シンプルにタクソノミーっぽい使い方をしている例です。「製作国」というtaxonomyに「アメリカ」というnameが入力されています。ポータルのフィルタに「taxonomy = “production_country”」みたいな指定をするだけで、そのポータルはtax「製作国」だけを表示するポータルとなりますね。
入力を簡単に行うには、例えば次のような方法があります。
値一覧を利用する
タクソノミーですから、値はある程度決まっています。「アメリカ」「スペイン」「イタリア」みたいにですね。すでにタクソノミーおまとめローカルデータがあることが前提ですが、値一覧でフィールドを利用するんです。
リレーション上必要なのでtaxonomy_idを値一覧にセットします。でも数字見たって何かわかりませんから、表示するのはnameに指定します。ほらね。値一覧でidをセットしつつ表示はnameなんて、テーブル内に両方あるからこそ出来ることです。
上の図では項目名（name）の右側にポップアップメニューの矢印が見えますね。それがtaxonomy_idフィールドでポップアップ表示している部分なのです。ポップアップを表示すると国名がずらずらと表示され、必要な国名を選ぶと実際にはtaxonomy_idが入力されます。で、数字を見ても楽しくありませんから、nameフィールドを上に重ねて、目にするのはnameフィールドであると、そういう配置です。
必要タクソノミーがカタログ的なものであり、すでに登録済みのものを入力することがほとんどであるという場合なんかに重宝します。
専用ポータルの工夫
特定タクソノミーだけをフィルタした専用ポータルを作るとき、オブジェクト名にフィルタしたtaxonomy名を付けておくと、スクリプト作成上いろいろ便利なことになりますのでおすすめです。
ポータル内にリスト表示
これはフィルターを細かく指定せず、タクソノミーをリスト的に表示したポータルです。こっちのほうが使い勝手が良い類いのデータもありますし、確認用としても必要な表示です。
taxonomyによっては新規でガンガン作っていくタイプのものもあります。そういうときにも使えます。ローカルで作成するときはタクソノミーとnameを入力しますがidは付きませんよね。idがないデータが即ちローカルで新規に作成したデータであるということも一目瞭然です。あとでリモートと同期して新規作成するときにも「idがないデータ」の存在はとても判りやすいんです。
リモートのtaxonomyあるいはrelationshipsと同期・新規登録
話の流れ的にやっぱりリモート同期にちょっと触れておかねばなりませんか。
ローカルのtaxおまとめは便利ですがリモートと同期させるのが面倒です。ここにかなり手間が掛かります。これについて丁寧にやり出すと長くなるのであっさり済ませますね。
リモートデータはid中心主義、かつリレーションから順に末端のnameに辿り着きます。
relationshipsのtaxonomy_idがまずあって、そのtax_idがterm_taxonomyに繋がります。次にterm_taxonomyのterm_idがtermsのidに繋がりnameを呼び出します。こういう順序です。
最初のこの図を思い出しましょう。IDを中心に、左から右に向かっていくと捉えられます。
これに対して人間が行う思考はまったく逆です。まずtermsのnameがあります。言葉を中心に、右から左に向かうのです。
ここで役立つローカルおまとめtaxonomyです。すべてのフィールドを一つのテーブルに合体させていますから順序など関係なくなります。まずこれが存在していることを前提に、次にやることはFileMakerのテーブルオカレンスで言葉中心のリモートリレーションを組むことです。
こういうことです。idではなくnameをローカルtaxデータと照合して繋げていくわけです。
これによってどうなるかというと、nameつまり言葉だけが入力されたローカルtaxのデータからid中心主義のリモートデータを同期させることができるということです。
リモートのtaxonomyセットはtermsから作っていく
リモートのタクソノミーセットを新規で作成するときって、実際のidによる運用とは逆にtermsから作成していくんですよ。
えーと、つまりですね、idがまだない状態でいきなりterm_taxonomyにデータは作れないんです。term_taxonomyを作るためには、その中のterm_idがなくてはなりません。term_idがないのにterm_taxonomyは作成できません。
で、termsから作っていきます。
postmetaではkeyとvalueを入力すれば勝手にmeta_idが作られました。同じように、termsにnameを新規入力すると勝手にterm_idが作られます。
注）もし既存のtermであるならidを転記させる仕組みが必要だし、もしtaxonomy違いの同じterm nameが存在するなら、そのnameがどのtaxonomy のものであるべきか決定する仕組みが必要です。細かくいろいろありますが言い出したら切りがないので続けます。
さて生成されたterm_idがあればこっちのもの。term_taxonomyを新規に作成できます。まず大抵はtaxonomyはすでにありますよね？だから、すでにあるtaxonomyと、新規に作られたterm_idを入力すればterm_taxonomyが作成できて、そうです、新規のterm_taxonomy_idが自動で作成されます。
そのterm_taxonomy_idをterm_relationshisにpost_id（object_id）とセットで入力してあげれば、relationshipsも完成します。
こういう順序になるわけです。ですのでFileMakerで逆順リレーションを組んでおくことが重要になります。
この一連の流れを、専用レイアウトや専用スクリプトを作って自動化させますと、ローカルで新規に作成したタクソノミーセットをリモートで新規作成したり同期させたりできます。ポータル内で通常運用している行の中に仕込むこともできます。いろいろなやり方があります。私もまだ何がベストか言い切れるほど精進しておりません。いろんなやり方で運用していますし、データの特性によってもどういう方法がいいか変わってきます。
ということで、FileMakerでWordPress、本日はタクソノミーについてでした。随所に説明不足もあるかと思いますが概要こんなところです。
時は流れ・・・
散々書き散らかして今更ここに書くのも憚られますが、このポストで示したローカルに作るrelationデータ、これ、今はほとんど使わなくなりました。もっと小気味の良いやり方を思いついたんで、無闇矢鱈にローカルにもデータを作ることを最小限にしています。やっぱローカルに作りすぎると同期させるのがたいへんなので。
それがどういう運営か、またいつか記事にするかもしれないししないかもしれない判りませんが。
創意工夫はいつまでも。
