Quoting Niclas Hedhman <[email protected]>:
On Tue, Oct 2, 2012 at 5:15 PM, Stanislav Muhametsin
<[email protected]> wrote:
Yes, except it takes it further - one *table* for each full-qualified
property/asso name. The collection value types complexify it a bit but not
extremely much. Thus we can store each property/asso of the entity without
the need to fill rows with empty values. Of course, the complexity then
grows. And there is a schema - it contains tables and their constraints for
all properties/assos of all entity types used in whole Qi4j application.
There is never a need to have one table per prop/assoc, other than a
convenient implementation detail for the entitystore author. The
proper granularity should be my suggestion 3, one table per mixin type
with one column per prop/assoc.
I was talking about indexing, not entitystore. The problem with one
table per mixin type are ManyAssociations and Properties with
collection types. Those would need to be unwound, losing the data
integrity and making queries far more complex, by needing to use
regexes etc.
For entitystore, there the suggesion 3 might work. I guess it is
better from storing full composite state into one column - then you
can add/remove entity mixin types more easily, and also having
possibility of having different mixins for same entity in different
applications.
Ah, the ever-lasting dilemma of complexity growth. What happens when you are
adding features that are extremely hard to solve when built on noSQL
solution? :) If noSQL doesn't solve *all* problems, surely there must exists
such scenarios (none come to my mind right now tho).
Right... The answer; combine. And with that comes things like
embracing "No distributed transactions", which requires a different
kind of design approach.
Mmhh. True, although it's hard to combine things properly, without
getting bad side-effects from both.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
