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 :)