ヘッドレスCMSは、裏側で（DBMSレベルで）どのようなデーターベース設計をするのかが問題になる。 ユーザーが使うとき、たいてい、コンテンツ（データ）投入の前にスキーマ設計・編集をすることになる。柔軟なスキーマを組むことができるが、その裏側はどうなるのか。直感的には、柔軟さとパフォーマンスはトレードオフ関係になっているように思える。

ここで、2つの大きな方向性がある。

ひとつは、EAVモデルのテーブル設計を使う方法。

もうひとつは、物理的な（DBMSのレベル）スキーマ設計と、論理的な（ヘッドレスCMS上の）スキーマ設計とを一致させるパターン。

Strapiはこの後者のパターンを採用している。Strapi上で article モデルを作るとDB上にも article テーブルが作られるというわけだ。この方向性では、次のような特徴がある。

• 高いパフォーマンスが得られる
• DBMSネイティブの機能を使える（たとえばインデックスなど）
• 反面、DBMS由来の”制約”がつきまとう。
  • テーブル名や、各種上限値

Strapiを使っていると、後からモデル名（API ID）を編集できないことに気づく。このモデル名は、データベースのテーブル名と直接紐づいているため、変更できないということだろう。また、モデル名やフィールド名として利用できない文字があることも、データベースとの紐付けを考えればうなづける。

ここで、単純なアイデアが浮かぶ。「直接紐付けるのではなく何らかの中間IDで紐づければよいのでは？articleモデルのテーブル名を article とするのではなく 0001 などとしたほうがフロントエンドのUXは向上するのでは？」

こうすると、バックエンド側のUXが落ちることが嫌われる。 データの保守や移行がしにくくなる。 直感的ではないテーブルが出来上がってしまうので、もしDBMSを直接覗くと、わけがわからなくなる。どのテーブルが何のスキーマなのかの変換はStrapiが握る。EAVモデルほどではないが移行もしにくい。

もしこれが SaaS ならば、DBMSで見たときのことなど、中の人がわかれば十分なのだから、フロント側のUXに全振りすれば良いことになる。オープンソースであるがゆえに幅広い関心ごとに対応しないといけない設計の難しさと見ることもできるし、単にターゲットユーザを幅広くとらえているだけとも思えるが、どうなんだろう。