2

私たちは、Amazon DynamoDB と同様の料金モデル (つまり、必要なものを柔軟にプロビジョニングする) で Rails アプリに取り組んでいます。簡単にするために、次のように構成できるとしましょう。

  1. 利用者数
  2. 作成できるドキュメントの数

要件

簡単に言えば、構成内容に基づいて支払います。具体的な要件は次のとおりです。

  1. その月の上限に基づいて月額料金をお支払いいただきます。3 日に 1,000 ユーザーにアップグレードし、10 日に 500 ユーザーにダウングレードした場合、1,000 ユーザー分の料金を 1 か月分お支払いいただきます。
  2. いつでもアップグレードできます。
  3. 1日1回ダウングレードできます。

(これは一見不公平に聞こえるかもしれませんが、ここではかなりのリソースを割り当てています。)

あまり邪魔にならずに、私たちが望むことを行うデータモデルを設計する方法を探しています。

検討したこと

gem の監査

私が見る限り、simple_auditやpaper_trailなどの gem は使用できません。

モデルの変更をシリアル化してデータベースに保存します。これは取り消しとバージョン管理には適していますが、日付範囲内の変更を取得して MAX 値を見つけることができないため(Ruby でそのほとんどを計算せずに) 、要件 1 には適していません。

自家製のソリューション

次の自家製のソリューションを想像できます: 次のようなレコードを格納するデータベース テーブル

(model, metric, value, time_of_change, user_who_made_the_change)

これにより、次のことが可能になります。

  • すべての変更を 1 か所で行う
  • 日付範囲内の最大値を照会する (要件 #1)
  • 次の変更がいつ許可されるかを問い合わせる (要件 #3)

このテーブルは、トランザクションでラップされた ActiveRecord (推定可能after_save) コールバックで更新されます。save

NIH Syndromeのために自家製のソリューションに懸念を抱いています。

または、おそらく、私はある側面または他のソリューション全体を見落としています. どう思いますか？

4

0 に答える 0