Just a thought (and I'm relatively new to ODB, so I invite anyone's input if my thinking is wrong)...
When designing a data model for ODB, if you think about it in the same terms as a relational database, you can end up with a model that's pretty close to what you'd come up with there (as you say, "same as in a relational database"). And it will "work", but probably won't be very efficient. My experience is that having a better understanding of how you'll be using/querying the data is much more important with a graph database (not that you wouldn't take this into account with a relational database, but since relational query results are essentially "built on the fly" when you run them, I think it's natural to think less about the relationships between the data and instead focus on the individual tables, "fixing" performance by adding secondary indexes as needed to speed up the joins). Let's take your example. If you'll be using the data in such a way that you'll need to start with a client and retrieve a list of documents (rather than just being able to query the documents based on the client key), the question I would have is whether a single list of every document would really be all that useful (to my point, I see this as trying to use a LINKSET as a "documents table", thinking in terms of relational database design). But maybe that query (i.e. "return every document that belongs to client X") isn't one that you'd ever really do. Instead, maybe there are different kinds of documents (invoices, receipts, credits, etc.), which might benefit from having a separate LINKSET for each kind of document. Or maybe (more likely since this is a financial application) *time* is your "grouping vector", so that all documents created on a certain day are related by virtue of *when *they were created. And in that case, creating some meaningful "layers" might be the answer (i.e. client->years->days->documents or maybe client->years->months->days->documents). Look in the ODB documentation on Time Series for some additional details here--this approach lets you quickly retrieve a document based on a particular day or accounting year or range of days/etc. and is very efficient, because any given LINKSET will never never be particularly large. Of course, this could be done using edges as well, but from your example, a LINKSET might be simpler. On Tuesday, March 8, 2016 at 5:30:00 AM UTC-6, TomaszK wrote: > > Thank you > > So in class "documents" I should keep foreign key, or a link to a record > of Client class. Probebly with index set on it. > > Id data aggregation is needed i should use: > "SELECT ... FROM Documents WHERE client = ..."? > Exactly the same as in relational databases. > > 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.
