Quoting Niclas Hedhman <[email protected]>:
Let me first recap one of the things that quickly gets blown out of
the water in regards to relational models in a COP environment...
Since each mixin has its own state, any solution involving SQL would
end up with the following three choices;
1. Putting the entire state of the Composite into a single column
(the implementation that exists do that)
2. Putting each Property and Association of the Composite into its
own column in a single table.
3. Putting each Mixin in its own table.
I don't think I need to explain 1.
That's how SQL Entitystore works, for quick access to composite when
queried by ID.
For 2; This is plain stupid, since all properties of all mixins are
represented in that single table, it would largely be empty fields for
most instances. So why not put each composite type in its own table?
Well, for a given composite instance, it can have an arbitrary number
of types (roles), so Apples, Bananas and Oranges are all both Fruit
and maybe Sellable, but all Sellables are not Fruits. Will they end up
in a Fruit table or a Sellable table? Expand that to 20 roles or more,
and you might see a pattern --> How do you find things again?
For 3; This has been discussed as viable option. The performance will
suck, either from too many individual reads (on-demand as mixins are
accessed) or massively large JOINs to bind 20 tables together. Also
write performance will be poor. BUT, some applications are not that
sensitive and perhaps someone with strong interest in the matter
(hint! nudge!) could set out an make such an implementation. The
effort required is probably "within reason", but outside the volunteer
focus at the moment.
Why would nr. 2 result in a lot of empty fields (I assume you meant
rows here?)? Indexing-SQL is done exactly like that, and it never
stores empty rows to the Property/Association tables. And there is no
'Fruit' table or 'Sellable' table for that matter - since you just
defined nr 2. to be solution where table represents
property/association, not type. If there is 'fruitShape' property of
'Fruit', then a table would be created for 'Fruit.fruitShape'. Of
course writes and queries may become quite complex - but easily
optimizable with indices etc.
The whole persistence aspect of Qi4j (EntityStore + Indexing) has
implementation for SQL. The code is a bit outdated, and probably could
be optimized a lot with some effort, though. I hope I will get time to
at least fix the Indexing-SQL for next release so that it would pass
tests.
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). So we made our own 'ORM'
framework, which has no problems with scalability or querying, and it
is based fully on SQL.
Summa summarum (aka TL;DR): if you have a working SQL-based system,
don't bother to change to noSQL solution.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
