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
