Ruby on Rails

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

On Sep 7, 2014, at 12:42 PM, 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 ?

Roelof

Op zondag 7 september 2014 18:11:13 UTC+2 schreef 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?

Colin

>
> Roelof
>
>
> Op zondag 7 september 2014 14:25:00 UTC+2 schreef 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
>>
>> >
>> > Roelof
>> >
>> >
>> > Op zondag 7 september 2014 11:14:40 UTC+2 schreef Colin Law:
>> >>
>> >> On 7 September 2014 08:14, Roelof Wobben <rwo...@hotmail.com> wrote:
>> >> > 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 ?
>> >>
>> >> 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.
>> >
>> > --
>> > 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/dc95ff34-6d50-48bf-b976-cde053b71c1a%40googlegroups.com.
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/92ddd696-b55a-4861-b178-fb6bfd7302c7%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

--
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/ed49f94f-f399-40c8-8dba-9b91f0b5464d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.