Hi,
I have a requirement for a 'transaction' node. Ordinarily, this would be a node that shows payment from one referenced node to another referenced node (both using entity reference). This is then used in views to create a 'statement' of transactions listed against those referenced nodes.
There are plans floated to allow users to make simultaneous transfers, with potentially thousands of payments being made in one go. Originally the idea was to have each transaction as a separate node, but I don't think this would be wise if we now scale to this amount of transactions.
My idea is to use an unlimited field_reference and have a single transaction node still.
A couple of notes:
1. I am moving to MongoDB also which will probably be a factor in any decisions, given that the fields will be stored in there.
2. User creates a transaction node (programatically). An API call is made to an external server which then reads the transaction node supplied to it (via the Services API). It processes the transaction required and then marks it as paid. The original plan allowed for the transaction to fail and that to be reflected in the node. If we go with the unlimited field option, we'll probably need a field_collection of entity reference, payment amount and status to still allow that to happen on a per transaction basis.
In short, if a field can be set to Unlimited, what affect does that have to performance in both the views and/or the creation/reading of that node? Are there better options for what I want to do?
Looking forward to any ideas,
Thanks,
Paul.