Hi Norbert,
I am way too old for holy wars ;-)
So in essence, we are both saying that hammering objects into
either an SQL or NoSQL database can be hard and both approaches
have negative drawbacks as well as plusses.
I didn't come up with Transactions because they also can make
things hard. See the atomic counter question from a few days
ago.IN ORMs you usually end up with both image-side and
database-side implementations of Transactions, and this can be
helpful and complicated at the same time. Sometimes you'd just
like to save one object without saving lots of associated ones
from the same unit of work.
Does this all lead us to the object database grounds? Or is it all
just a debate of taste and faith? I am still wondering if my life
would be easier if I used an object database (Gemstone comes to
mind, but also Magma). And still I cannot find the final answer.
Maybe that is because I have some knowledge with ORM, but very
little with OODBMS.
No matter what, my initial point should have been that I think it
is naive to think that NoSQL DBs solve a lot of the problems you
have with RDBMS. They just don't address them, and if you don't
see som eof these problems in your domain, I guess you're best off
using NoSQL.
ObjectID and stuff in mongo still means you have to make design
decisions and implement something to assign/retrieve those ids and
store them in places where you want to reference your objects. So
you do a subset of the bookkeeping that an RDBMS can do for you by
hand. Is that a fair way to put it?
it is called Voyage and it does all the painful referencing for you. You just need to declare a class as root and voyage takes care of all the work (not for deleting objects)
in general (not saying that you do it, but since you call it a �holy war��), I think (and I�m also old enough to have battle *a lot* in all areas), I think most people uses relational databases for a lot of wrong reasons� then they use wrong tool for their problem and in consequence they end taking wrong design decisions just to make their model fit into a wrong solution pattern.
Then, they repeat same problem once and again until what become hammered is their own head: they end thinking that the only possible solution is what they decided a priori, without any thinking on the real problem to solve.
As a conclusion� how many people do you know that believes that relational is the �de facto� way to go instead actually think in their problem?
In my case, while I admit there are contexts that are better for a relational database, I think that in object oriented programming it should be the last resource: in general, the amount of concessions you have to do in your model to properly fit in a tabular design is just too much. So the gain should be too much also to make it valuable (and that of course talking in general: concrete problems can have other concrete solutions) :)
Esteban
You made a good point and I tend to agree to most of what you say.
Am 25.04.14 10:35, schrieb Norbert Hartl:
Joachim,
thanks for your explanation. I appreciate that. I was
thinking if it is a good idea to write my mail. Usually this
ends in a holy war which I don�t want. Comments inline.
Norbert,
you are right, I should have given an example of what I
mean.
So here is one:
If you serialize an object graph to, say, json and store
it in a NoSQL DB, you need to decide how "deep" you
serialize your graph into one djson document and how to
build up segments of your graph that need to be
serialized separately, like for an equivalent of an 1:n
relationship. Exanple: an Order contains OrderItems,
each of which reference a Product. But the Product can
be referenced from many OrderItems. So you need to "cut
off" parts of your model to serialize them separately.
And you need a way to save the "reference�.
You can do that in e.g. mongo as well. You just use on
ObjectId as a field value or you use a DBRef. Btw. what you
describe is not 1:n but m:n. An OrderItems can have n
products and a Product can be in m OrderItems.
One of the next questions then is "what if I delete a
Product?". What happens to the OrderItems or
InvoiceItems and so on?
If you just delete it the collections will have a stale
reference. I think there is no universal answer to that even
if it seems the removal in the collection is that universal
answer. If it is about integrity you need one way to make it
happen. Reestablishing of integrity can happen on write time
or on read time.
What will happen in a SQL context? You can�t delete an
object that is pointed to by a foreign key. What does it help
then? Not taking your business model into account you couldn�t
do anything more to find out where that reference is. That is
probably the only point I wanted to make questioning your last
mail. If we take that scenario you can only solve it if you
take the problem one level higher (well, if you have cascading
deletes you may ignore it). So these problems tend to end in
the application logic. And that is what my experience tells
me. Database ensured integrity isn�t much of a help in many
cases. So you solve the problems in the application logic
(knowing which things reference what). Being there I see no
big differences to using a NoSQL database. In NoSQL those
features are just not there per se. You have to model it
regarding your use case.
None of these problems are
unsolvable, but these problems need to be addressed
either in your persistence framework on top of a NoSQl
DB or in your application code. In Relational DBs,
they've built solutions for these problems before you
and I were born ;-) I am talking of foreign keys,
referential integrities and normalization. To my
knowledge, these have not yet found their standardized
counterparts in NoSQL DBs. So NoSQL can be a good
solution for many problems, but they can also be bad for
many others.
I�m questioning the use of each of those. As I said above
I doubt there are many use cases where foreign keys are the
best way to go. Btw. if you ever administrate a database and
you have to recover after a crash then you might have a
different view on foreign keys because they are able to make
it close to impossible to load the data back. Referential
integrity is either done by the database by foreign keys or
in the application logic as I said above. The need for
normalization is heavily use case depend. It is nothing good
per se. So these are not good examples IMHO. I�m wondering
you didn�t bring up the only good reason for SQL databases
(for most). For me this is having atomic operations using
transactions. This is the one case that can drive you nuts
if try to model something with a NoSQL database to achieve
it.
I am not saying anything new here. This debate has been
going on for decades already, and much more clever
people than me have made good points for both sides over
the years now.
Sure. But from time to time it is good to refresh the memory.
And for me you are clever enough ;)
You also asked for examples for problems you get from
using Glorp.
One of my biggest concerns is that it can be hard to
model an m:n relationship where one or both sides of the
relationship are abstract superclasses (or even concrete
ones with multiple subclasses). It gets even harder when
you want to be able to associate an object (like a
Category or Tag) to "anything". This really is hard or
involves some additional coding on top of the
persistence framework.
Glorp does miss one feature painfully: The ability to
map classes with subclasses that spread over three or
more "subtables" for the subclasses. This one is hard to
explain: if you have a superclass "Vehicle" with two
subclasses "FlyingVehicle" and "DrivingVehicle", both of
which have subclasses, there is no support for a model
which has tables on the "FlyingVehicle" or
"DrivingVehicle" level. You must model your DB in a way
that there are all attributes in a "Vehicle" table or in
the "Car", "Train", "Spaceship" and "Kite" tables. This
really is a pity and I don't think anybody is working on
changing this any time soon.
Yep. Dealing with these cases I learned that Objects and
SQL databases don�t fit together and why ORM cannot work. I
mean Glorp is really good at that by providing your use case
with subclasses via virtual lookups. I don� remember how it
works. It was like a descriptor with candidate classes which
lead to multiple lookups. I figured that out while talking
to Alan 8 years ago. I think I managed it by using a three
column m:n mapping table where you have the two ids and an
identifier that gives a hint which subclass/table it is to
look into. Anyway even if Glorp supported sublasses lookups
it was a can of worms to open. I once changed a single thing
in my glorp descriptions and then the login the web site
took 1,5 minutes just because all the magic in Glorp
produced 432 database lookups initiate by a single button
click. You just try to force a schema (OO) onto a technology
(SQL) that does not support this case at all. It is an
entity relationship model where the entities are flat.
Inheritance is not part of the solution.
So the summary would be: A lot of people making big
efforts to forcing an object model into a technology that
doesn�t support it just because they want to have features
like integrity you can establish in other ways. This is why
I don�t use SQL databases anymore until I have a use case
that does benefit from it.
Does this explain what I
mean?
Yes and I hope I made point also very clear :)
Norbert
Joachim
Am 25.04.14 08:41, schrieb Norbert Hartl:
Hi,
We're using Glorp on VA ST for
kontolino.de.
It is an active project in the sense of somebody is
taking care of bugs. The lead developer(s) work(s)
for Cincom - and Cincom uses Glorp as supported
component of CST. Instantiations also provides Glorp
with VA ST and supports it. Glorp is very stable and
is not moving fast, which is not a disadvantage for
a production system. Features are being added and
bugs are fixed.
Re: Pharoers do NoSQL: judging from the discussions
on this list and others, you have to be careful what
you need. To me it seems many developers want
features from relational DBs and hammer them into
their applications with brute force. The first wow!
soon gives room to a lot of problems that have been
solved in relational DBs three decades ago.
I think such a statement should be based on an example.
But it is true that o/r mapping is not always
fun. It can force you to make decisions about your
model that look strange from the object
perspective.
Agreed. And especially in the context of O/R I'm
curious what will be your example to prove your point
above.
Couldn't resist,
Norbert
I'd either go full objects (gemstone, magma) or
relational for my typical projects (business
apps).
Hth
Joachim
Cl�ment Bera <
bera.clement@gmail.com>
schrieb:
Hello,
I think Glorp is used with DBXTalk for
relational databases by multiple people.
Usually, with Pharo, people use as a
persistance layer either MongoDB with the
frameworks MongoTalk/Voyage.
Gemstone is also used quite often for large
scale application but Gemstone is not free.
Regards.
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1