Hello guys, thank you for all the valuable feedback. I can not say that I could follow you in all the details, especially when talking about Qi4J internas. Therefore I will code in the next couple of days a simple prototype that reflects our needs. We will further discuss the pro/contra on that SQL topic.
Cheers, Jiri 2012/10/2 Stanislav Muhametsin <[email protected]>: > Quoting Niclas Hedhman <[email protected]>: > >> On Tue, Oct 2, 2012 at 4:05 PM, Stanislav Muhametsin >> <[email protected]> wrote: >> >>> Why would nr. 2 result in a lot of empty fields (I assume you meant rows >>> here?)? >> >> >> No. Not rows. >> The choice is that a row = a composite. And coumn is the >> full-qualified property/association name (i.e. Mixin + method name). > > > Ah sorry, I noticed I missed a 'single table' in your explanation of nr 2. > My fault! > > >>> Indexing-SQL is done exactly like that, and it never stores empty >>> rows to the Property/Association tables. >> >> >> Ahh... A 4th choice that I didn't realized. A table with Identity, >> Property and Value columns. I think it is another "obfuscation" from >> the "SQL community's" point of view; There is no schema at all, as we >> have in 1. > > > 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. > > >>> IMO the whole noSQL fuss is just hype. SQL is a professional tool, and >>> there >>> is nothing wrong with its scalability or other options. Most problems >>> related with SQL stem from not understanding how to use it properly. Not >>> to >>> mention that pretty much all ORM-frameworks are total crap (including >>> Hibernate & Co, or Microsoft's "solutions" in C# world). Yes - every >>> single >>> ORM framework I tried, was pretty much unusable (for the project I'm >>> working >>> for). >> >> >> As for the "hype", I would somewhat agree, but SQL is both capable but >> likewise complex and hard to work with in a primarily object-oriented, >> graph-related software world. Does NoSQL solves all our problems? No, >> not at all, but it highlights the absurdity that SQL is THE answer to >> all storage needs. It isn't... > > > Yeah, I think there is no 'silver bullet' as such, not even SQL is that ;) > > >> As for ORM; In general, you are right. Hibernate sucks. More so than >> JPA. JPA sucks more than JDO. It makes the initial steps relatively >> easy, only to rear the ugly heads down the line. Or IOW, the ORM >> abstraction LEAKS into the object model quite severely. > > > +1. > > >>> Summa summarum (aka TL;DR): if you have a working SQL-based system, don't >>> bother to change to noSQL solution. >> >> >> Yes, I agree with that... unless you are adding features that are >> extremely hard to solve when built on RDBMS. >> > > 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). > > > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
