On 25 Apr 2014, at 10:58, jtuc...@objektfabrik.de wrote: > 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. > > Joachim > > > > > 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. >> >> Am 25.04.2014 um 09:02 schrieb jtuc...@objektfabrik.de: >> >>> 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: >>>> >>>> >>>> Am 25.04.2014 um 06:51 schrieb Joachim Tuchel <jtuc...@objektfabrik.de>: >>>> >>>>> 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.clem...@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. >>>>> >>>>> >>>>> 2014-04-23 20:34 GMT-07:00 Pablo R. Digonzelli <pdigonze...@gmail.com>: >>>>> Hi all, can someone tell me if glorp is active there ar is using glorp or >>>>> other persistence framework in production projects? >>>>> >>>>> Tia >>>>> >>>>> Ing. Pablo Digonzelli >>>>> Software Solutions >>>>> IP-Solutiones SRL >>>>> Metrotec SRL >>>>> 25 de Mayo 521 >>>>> Email: pdigonze...@softsargentina.com >>>>> pdigonze...@gmail.com >>>>> Cel: 5493815982714 >>>>> >>>>> >>> >>> >>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuc...@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:jtuc...@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 >
