一般的なパターンは、plugin_store_rows テーブルの key フィールドを使用して、名前空間と一意の識別子の両方を保存することです。つまり、以下の形式です：
<namespace>_<id>
このパターンは、最近のコア Discourse プラグインではあまり見られなくなっています。PluginStore の使用が全体的に減少しているためです。例えば：
-
OAuth2 Basic プラグインは、user_associated_accounts へ移行するまで、関連するアカウントデータの保存にこれを使用していました 参照。
-
Poll プラグインも、独自のテーブルへ移行する前にこれを使用していました 参照。
ただし、コア Discourse コードベース自体を含むいくつかの場所では、まだ使用されています。例えば Reviewables モデル などです。
私も複数のプラグインでこのパターンを使用しています。
このパターンが使用される主な理由は、plugin_store_rows テーブルが複数のプラグイン（およびいくつかのコアサービス）によって使用されるため、識別列である id や plugin_name を、PluginStore を使用する各システム内部での識別に使用できないからです。そのため、代わりに key 列で文字列ベースのシステムが使用されています。
プラグインからデータベース構造を変更することについては、@gdpelican が良い投稿をしています：
個人的には、これを行うことにはまだ非常に慎重です。なぜなら、サードパーティのプラグインを扱う場合、名前空間の制御、プラグインの削除、コア Discourse への潜在的な競合する変更などについて、コントロールがないからです。
@gdpelican が指摘しているように、プラグインをアンインストールする際にユーザーがデータベースの変更を削除できるようにする仕組みを提供する必要があります。
プラグインが不要になったユーザーがデータベースの変更をクリーンアップできる方法を提供してください。私はこれを rake タスクで行いました。
これは、ほとんどのプラグインユーザーにとっては詳細すぎる内容であり、この点に気づいていない場合、リスクとなります。
さらに、私は PluginStore や CustomFields の範囲外に出る真の必要性を感じていません。
以上を踏まえて、個人的には、このパターンが有用であるため、PluginStore にこのような新しいメソッドが追加されることに賛成です。
@david にも、上記についてのご意見をお聞かせいただければ幸いです。