Hi Tomek,
In your situation, I will not keep a Documents property with Client class,
it means there is only a single uni-directional relationship from Document
to Client instead of a bi-directional relationship. If your logic need to
know a set of document by a client, you could easily write a query instead,
so you could fetch as many document as you want, also count by some
criteria, it's extremely fast and you could browse your result set by
pages, so there is no limit of number of rows by your query.
In case, you want to keep Documents property, you will need to worry all
related code logic, because the entire Documents of a single Client could
be fetched into RAM at once by mistakes even that current code logic is not
need such data.
My Best,
Hung Tran
On Tuesday, March 8, 2016 at 3:02:06 PM UTC+7, TomaszK wrote:
>
> Thank you for your reply Hung Tran.
>
> This is model of the situation where the customer has the documents. They
> can be very numerous, for example a document is a receipt from the cash
> register at the grocery store, so can be numerous even in a single day.
>
> I need aggregation, for example, in 2015 total sales. So I have a 1-n
> relationship with a very large n.
> Hence I have in OrientDB JSON client: {"name": ... ,"Documents"
> [ref_to_doc_1, ..., ref_to_doc_12234]}
>
> Is there any other way, with no adding in the "document" table field with
> the client id, like in typical relational database?
>
> Best Regards
> Tomek
>
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
