Webサイトのお助け隊

会員名簿、物件情報、申込の履歴。WordPressで業務のデータを扱うことになったとき、投稿の仕組みに載せるか、データベースに自前のテーブルを足すかで、後の運用がまるで変わります。作り始めた時点では両方とも動くので、差が出るのは件数が増えてから、あるいは「特定の条件で絞り込みたい」と言われてからです。そして、動いているシステムのデータの持ち方を後で変えるのが、いちばん高くつきます。物件登録の仕組みと会員限定サイトで、それぞれ別の答えを出した経験から、判断の順番を書きます。

WordPressがデータをどう持っているか

先に構造の話をします。投稿は wp_posts というテーブルに1件1行で入り、カスタムフィールドの値は wp_postmeta に「1項目につき1行」で入ります。項目が20個ある入力フォームなら、1件登録するごとに20行増える計算です。1万件なら20万行になります。行数そのものは今どきのデータベースにとって大きな数字ではありませんが、問題は検索の形です。

「エリアがA、種別がB、価格がC以下」という3条件の絞り込みは、項目ごとに行が分かれている以上、そのテーブルを条件の数だけつなぎ直す処理になります。条件が増えるほど、件数が増えるほど、重くなる方向にしか進みません。逆に、1件が1行で、項目が列として並んでいるテーブルなら、同じ検索は1回の問い合わせで済みます。独自テーブルを足すかどうかの議論は、突き詰めるとこの違いを買うかどうかの話です。実装の具体は独自テーブルを足すときの設計のほうに寄せてあります。

3つの軸で決める

件数と、増え方

数百件で頭打ちになるなら、投稿の仕組みで作って構いません。管理画面も一覧も検索もWordPress側が用意してくれるので、作る手間が桁で違います。数万件に向かって増え続ける、あるいは毎日自動で流し込まれる種類のデータなら、最初から別テーブルを検討します。判断を先送りしにくいのは後者で、増えてから移すには、データの移行、画面の作り直し、URLの維持まで一式が必要になります。

どう検索されるか

不動産会社向けの物件登録システムを作った案件が分かりやすい例でした。物件は種別ごとに入力項目が違います。中古マンション、1棟もの、区分店舗、戸建て、貸事務所、貸店舗、土地。1種別あたりの項目数が多く、種別が増えるほど項目は掛け算で増えていきます。見積りの前に「何種別あるか」を数えるのは、このためです。

実装後に出た不具合も検索側でした。検索用の選択肢に、他の種別でしか使わない項目が混ざって表示されたのです。種別ごとにフィールドを分ける設計にしたなら、検索側が参照する範囲も種別で絞らないと噛み合いません。ついでに書いておくと、都道府県から市町村、路線から駅へと絞り込む連動式の選択欄は、カスタムフィールドの標準機能では作れません。選択肢を静的に持つ作りなので、絞り込みはPHPとJavaScriptの実装になります。見積りの段階でここを工数に入れておかないと、後から追加の相談になります。地名や駅のマスタはCSVで持たせておくと、次の案件でそのまま使い回せます。

消すとき、止めるときに何が起きるか

見落とされやすいのがここです。会員や契約のように「終わり」があるデータは、削除の仕様が設計そのものになります。会員を退会させたとき、レコードごと消すのか、状態だけ変えて残すのか。閲覧権限の紐付けはどうするのか。過去の履歴は残すのか。

投稿として持っている場合、投稿を消せばその投稿のカスタムフィールドは一緒に消えますが、他のデータが持っていた「この投稿を参照する」という値は残ります。参照先が消えた値だけが宙に浮き、一覧に空行が出たり、権限の判定がすり抜けたりします。独自テーブルなら、消したときに何を一緒に消すかを自分で設計できます。逆に言えば、設計しなければ同じ不整合が起きます。

3つの選択肢を並べる

実際にどちらを選んだか

会員限定のコンテンツを配信する仕組みでは、独自テーブルを選びました。WordPressの標準ユーザーとは独立した会員管理が必要だったためです。用意したテーブルは、会員、グループ、会員とグループを結ぶ中間、グループとコンテンツの閲覧権限、そしてメール文面の5つ。会員が複数のグループに属し、グループが複数のコンテンツを閲覧できるという多対多の関係は、中間テーブルで持つのが標準的な形で、この構造にしておくと閲覧制限の判定が単純な結合1回で終わります。

メールの文面までデータベースに持たせて管理画面から編集できるようにしたのも、この案件で効いた部分です。%company_name% のような差し込み用の記号を用意しておけば、文面を変えるたびに開発を発注する必要がなくなります。ただし、この規模になると承認の流れ、文面、ログインの管理と要件が次々に膨らみます。要件を固める工程と実装する工程を分けて見積もるべきでした。会員機能そのものの組み立て方は会員限定サイトの作り方の側で扱っています。

一方、不動産の物件情報はカスタム投稿タイプとカスタムフィールドで作っています。物件は公開する情報なので、一覧、詳細、検索、下書きと公開の切り替えといったWordPressの仕組みがそのまま使えます。ここを独自テーブルにすると、その全部を作り直すことになり、費用に見合いません。件数が数千の単位で、検索条件も種別・エリア・価格に収まる範囲なら、投稿の仕組みで足ります。

介護施設の求人情報を扱うサイトで、一覧ページに入力項目を表示する改修をしたときは、また別の教訓がありました。この種の作業は、実装より先に「どのテンプレートが効いているか」を確定させるのが仕事の8割です。標準の投稿のカテゴリ一覧なら category-{スラッグ}.php、カスタム投稿タイプのタクソノミー一覧なら taxonomy-{タクソノミー}-{term}.php。しかも管理画面のメニュー表示名は自由に変更できるので、「投稿」が別の名前になっていることがあります。表示名ではなくスラッグと投稿タイプ名で構造を確認する。この案件の手戻りは、ほぼここから出ていました。

そもそも持たない、という選択

データの持ち方を決める前に、そのデータを本当に保存する必要があるかを一度考えます。不動産情報を扱うサイトで「情報更新日」と「次回更新予定日」を表示したいという相談を受けたとき、項目を2つ増やして運用側に更新させるのではなく、投稿日から計算して表示する実装にしました。get_post_time() で投稿日を取り、strtotime() で一定間隔ずつ進めます。

実装の肝は、単純に「投稿日＋N日」としないことです。それだと過去の記事では必ず日付がずれます。投稿日から現在までをN日刻みで進め、直近に到来した日付を採る。この形にすると、何か月前の記事でも常に新しい日付が出ます。間隔の値は変数に切り出して名前を伝えておけば、「間隔を変えたい」という後の依頼は運用側で吸収できます。保存する項目を1つ増やすかどうかは、そのまま毎日の運用の手間に跳ね返るので、計算で出せるものは計算で出すほうが軽く済みます。

逆に、繰り返し入力できるフィールドで業務データを持たせる作りは、件数が増えたときに扱いづらくなります。どこまでなら耐えられるかは繰り返しフィールドで業務データを持たせる設計にまとめました。どちらの持ち方を選ぶにせよ、判断の材料は件数・検索・削除の3つに集約されます。ここが決まっていない状態で作り始めると、開発の途中でデータ構造ごと作り直すことになります。

よくある質問

独自テーブルはWordPressの更新で消えませんか

消えません。WordPressの更新が触るのは本体のファイルと、必要に応じて標準のテーブル構造だけで、自分で作ったテーブルはそのまま残ります。注意すべきなのはむしろ移行時で、標準のエクスポート機能や引っ越し系プラグインが、独自テーブルを対象に含めないことがあります。バックアップの範囲と移行手順に、そのテーブルが入っているかを必ず確認してください。

途中で独自テーブルに移すことはできますか

できますが、データの移行だけでは終わりません。一覧や詳細の表示処理、検索、管理画面、URLの維持まで含めた作り直しになります。移行の可能性が頭にあるなら、最初から表示処理とデータ取得処理を分けて書いておくと、差し替える範囲を小さくできます。逆に、テンプレートの中で直接データを取りに行く書き方をしていると、影響範囲が全ページに広がります。

会員機能は既存のプラグインで足りませんか

会員登録とログイン、有料コンテンツの制限までなら、配布されているプラグインで足りることが多いはずです。作る判断になるのは、会員をグループに分けて、グループごとに見せるコンテンツを変えるといった、権限の組み合わせが要件に入ってきたときです。プラグインの設定で無理に組むと、条件が増えるたびに設定が複雑になり、誰も全体を把握できない状態になります。