what is the best way to put this into models

[Roelof Wobben]

Hello,

I try to make a financial app.

Now I have this problem.

I have customers which are put into a model.

What I want is if I made a customer also a financial account is made with a specific number.

So customer 1 has account number 16001.

If the customer buys anything a invoice is made and must be put into the right 1600x number.

How can I do this with models ?

Roelof

[Colin Law]

Not sure what question you are asking. Is it what should the models
and relationships be? If so then possibly something like
customer has_one account
account belongs_to customer
and account has a field account_number (which will contain 16001 in
the above case).

Colin

>
> Roelof
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-talk/79408f0b-7c2d-458d-8e2c-d68c929f9bbf%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Roelof Wobben]

Almost,

I could do that but then how do I store the transactions.

Another models transactions which points to accounts ?

Roelof

Op zondag 7 september 2014 11:14:40 UTC+2 schreef Colin Law:

[Colin Law]

On 7 September 2014 12:23, Roelof Wobben <rwo...@hotmail.com> wrote:
> Almost,
>
> I could do that but then how do I store the transactions.
> Another models transactions which points to accounts ?

Sorry, I have no idea what you mean. You have not mentioned
transactions before, is a transaction another model. If so exactly
what is the problem.

Colin

> https://groups.google.com/d/msgid/rubyonrails-talk/dc95ff34-6d50-48bf-b976-cde053b71c1a%40googlegroups.com.

[Roelof Wobben]

Transactions could be a model for all the transactions that take place on accounts.

Like  a payment or a new invoice.

Roelof

Op zondag 7 september 2014 14:25:00 UTC+2 schreef Colin Law:

[Colin Law]

On 7 September 2014 17:07, Roelof Wobben <rwo...@hotmail.com> wrote:
> Transactions could be a model for all the transactions that take place on
> accounts.
> Like a payment or a new invoice.

So what is the problem?

> https://groups.google.com/d/msgid/rubyonrails-talk/92ddd696-b55a-4861-b178-fb6bfd7302c7%40googlegroups.com.

[Roelof Wobben]

The problem is if it is the best to put all in seperate models or if there is a better solution ?

Roelof

Op zondag 7 september 2014 18:11:13 UTC+2 schreef Colin Law:

[Colin Law]

On 7 September 2014 17:42, Roelof Wobben <rwo...@hotmail.com> wrote:
> The problem is if it is the best to put all in seperate models or if there
> is a better solution ?

All what in separate models?

> https://groups.google.com/d/msgid/rubyonrails-talk/ed49f94f-f399-40c8-8dba-9b91f0b5464d%40googlegroups.com.

[Jason Fleetwood-Boldt]

FWIW, we're not entirely sure if you're asking specifically about data modeling (like a general CS question) or a question specific to Rails/ActiveRecord. You probably would do yourself well to get advice about your system from someone with computer science experience, specifically building transactional systems.

Generally speaking from my own experience with transactional systems, ActiveRecord has some drawbacks that don't optimize for scale. In particular, if the set of operations requires lots and lots of objects to be loaded during any given transaction, ActiveRecord has a high cost (slow) associated with object instantiation. This doesn't affect most Rails apps if they create 25-50 objects in the lifecycle of any given request, but when a request is going to create hundreds and hundreds of objects you're going to see some bottlenecks at scale. (I'm not sure if this really applies to you -- just some background as you are going down this path.)

This doesn't mean that Rails is the wrong solution -- it just means you have to think about the bigger picture and perhaps know a little more about architecture than you do right now. Other alternatives to ActiveRecord (Datamapper) do not have as high a cost of object instantiation so might be good options for a problem like this. 

There are yet other advanced design patterns for transactions and banking systems too -- for example, just check out all the discussion about things other people have solved before you on the "Transactional processing system" Wikipedia page: http://en.wikipedia.org/wiki/Transaction_processing_system

All of those concerns are out of the scope of Rails & ActiveRecord. 

If I were you I'd learn a little more about your domain problem and back up and research different options, then prototype some in Rails and see if you measure how fast common operations take. 

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/ed49f94f-f399-40c8-8dba-9b91f0b5464d%40googlegroups.com.

[Roelof Wobben]

Thanks.

My question  was specific to Rails/ActiveRecord.

Roelof

Op zondag 7 september 2014 22:35:45 UTC+2 schreef Jason FB: