Hi Scott,
Yes, extra fields only on contacts is not enough for my customer needs.
For multitenancy i prefer to have some centralized, Centrico has also a
“server” application that schedule some operation on db that are cross tenant.
What do you think on have an object Tenant that can have some fields that are
cross tenant and cross object, for instance tenantId, datetime creation, user
creation, datetime edit, user edit and so on…
then each object extends the Tenant object
Thanks.
Giovanni
> Il giorno 11/giu/2015, alle ore 13:08, scott molinari
> <scottamolin...@googlemail.com> ha scritto:
>
> 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 a topic in the Google
> Groups "OrientDB" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/orient-database/0O_4qnz1AMI/unsubscribe
> <https://groups.google.com/d/topic/orient-database/0O_4qnz1AMI/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> orient-database+unsubscr...@googlegroups.com
> <mailto:orient-database+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
---
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 orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
