質問

RailsでMichael Hartlのチュートリアルを終えた後、私の最初のPETプロジェクトはTwilio APIを使用してコールトラッキングアプリを構築しています。基本的な考え方は次のものです -

4つの計画があるユーザーがサインアップできるため、それらが持っている電話番号の数、およびそれらが使用できる議会数を制限することができます。

各ユーザー、登録されたら、Twilio から独自のサブカウントを取得します。

各ユーザーは自分の計画に限定された電話番号を購入することができます

各ユーザーは、自分の電話番号で何が起こっているのかを追跡できます。

今、基本的な承認システムを構築し、潜在的なデータ構造をブレーンストーミングしました。私は理解して巨大なループホールを持っているので、経験豊富なプログラマーの目は大いに感謝されます。 I.Eはより良いデータ構造がありますか、私が以下の概要を意味しますか?

---は、これがデータ構造です。

テーブル:計画

max_phone_numbers: integer 
max_minutes: integer
has_many: users 
.

テーブル:ユーザー

name:string
email:string
password_digest:string
remember_token:string [For log in system]
Twilio_SubAccountSid: string
Twilio_SubAccountAuthToken: string
Plan id : integer [to connect to plan] 
stripe_token : string [for charging]
belongs_to: plan
has_many: phone_numbers
.

テーブル:電話番号

belongs_to users
phone_number:string
user_id: integer
has_many: data_points
.

テーブル:Twilioデータ

belongs_to phone_numbers
phone_number_id: string
[All of Twilio's call tracking data..i.e duration of call, location etc.]
.

大丈夫、それはそれがどのように機能するかもしれないかについての私の治療です。それを引き裂いてください!

役に立ちましたか?

解決

データ構造の観点からは、これがあるように思われると思います。私が実現しなかったことは、関与するのにもっと多くのコントローラがあるということです。たとえば、Twilioでの検索と購入は、2つのアクションを含むため、別のコントローラを作成しなければなりませんでした。ルーティングコールを担当する他のコントローラがあると思います。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top