Ok, now we are getting closer.
So only the contact object will allow custom fields? What about custom
objects relating to the standard contact object? Funny, I am working on a
similar idea.
I'll go with what you've said for now.
>From a database architectural standpoint, you will need some form of
tenancy descriptor or metadata and this will need to be centralized.
Centralizing is always something that fights against scale, but just for
the tenancy metadata, the overhead isn't too bad. So, now that you can
retrieve the "tenant" metadata, you need to decide how to store and
retrieve each tenant's own data. That could be at database level (1
database per tenant), class level (some prefix key in the names of each
class, for instance), or at the record/vertex level with a property field
holding the tenant key. All choices have advantages and disadvantages. I am
not entirely sure about them in an OrientDB system either. However, since
we decided to go with a database per tenant, it doesn't matter.
So, aside from your decision on tenancy control, you must also contend with
the custom fields. I believe the only way to do this effectively in any
document storage is to use key/ value pairs as subdocuments. Here an
example.
customFields : [
{ k : "Customer's Maiden Name", v : "Miller" },
{ k : "Child's Full Name", v : "Christa Smith" },
{ k : "Child's Birth Date", v : 128998232389 },
{ k : "Home Phone", v : "+1-555-123-2345" } ]
There are inherent advantages and some disadvantages to this method of
storing custom field.
Advantages:
1. You only need one index.
2. Querying shouldn't be too hard.
3. The fields and field types can be freely created without a lot of issue
on schema. You also aren't limited to 20. You can allow 100s.
Disadvantages:
1. You must also keep some form of metadata (mapping) of the fields for
each tenant somewhere, so you know what it is they are storing and
retrieving and can display it properly. (this is actually unavoidable
anyway).
2. You have more data in the DB than is actually needed, bloating it up a
bit (all the k and v field names)
3. Creating queries to insert and update gets more complicated.
The multilingual part can mean two things. The application text i.e. field
names, need translation or the actual content (the field values) need
translation. This is a bit more tricky. For the field names, I'd
centralize/ normalize them too. And for the content, you could have
multiple subdocuments with the translated values, when they need
translation. Which values are translated or not would be metadata again.
How this all actually fits best or if it fits best in this form in OrientDB
is something I am still working on myself.
Hope that helps.
Scott
--
---
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.
