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. > 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. Cheers -- Niclas Hedhman, Software Developer 河南南路555弄15号1901室。 http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
