Christopher Wright wrote: > Aarti_pl wrote: >> ...and this high-level design is IMHO mistake. Especially mapping >> relations from db to objects. >> >> Well maybe someone will give me examples where domain objects are more >> useful than relations? From my observations presentation layer (GUI) is >> also relational, so I don't see a sense with making conversions: >> relation -> object -> relation. >> >> I am working on db access framework which makes use of relations rather >> than creating objects. And it makes it in typesafe way... >> >> BR >> Marcin Kuszczak >> (aarti_pl) > > It's fine if you're just doing CRUD operations. At my job, we do staff > scheduling software -- I'd kill myself if I had to write the scheduling > engine or rule violation code in terms of database rows. And that would > be a major performance issue.
Well, really I don't get what the problem is here. Could you please elaborate more? > A good ORM solution will help prevent data inconsistency issues. Let's > say you need this superfast query in one area but it returns some data > that you already have. If you manipulated that data in memory already > and haven't committed it to the database already (because database > access is slow, so you don't want to be committing everything all the > time), your application will be in an inconsistent state. Yes, probably there are ORM solutions which keeps data consistent . But please notice that "keeping data consistent" is not a property of ORM itself. It's just that people implemented something like that in ORM systems. I am sure that it is possible to make data consistency layer also in relational system. I just don't want object Person in my program, but instead just row with person's data. > Also, touching the database is slow. It requires inter-process > communication; it requires translating data from the database's internal > format to whichever format it sends over the wire; it requires > translating from that intermediate format to something the application > can handle. Sure. But mapping this resulting format into objects is even slower. That's in fact one of major arguments against ORM. > If you can do your query in memory, that's often going to be > faster. Again. Queries in memory is not a property of ORM. In fact you make them always when you iterate specific collection e.g. searching for specific value. > There are exceptions, such as when your database schema is > significantly different than your objects (in which case this isn't very > good object-relational mapping), or when the query returns very few rows > and you have a huge amount of objects in memory, or when the database is > indexed on rows and you don't replicate that in your application. > > And doing in-memory queries isn't possible unless you have a collection > of objects that is a guaranteed superset of the desired output. As I said above - please notice that you can make queries in memory also in relational model. In fact I implemented it in my db access framework in quite universal way as 'agents'. > In general I prefer ORM. At the very least to translate rows into > objects, and to write basic CRUD queries for me; that keeps my database > access layer up to date. > > Also, it's a lot faster to write code with ORM than it is to write > custom SQL. I've heard people saying that if you are writing a custom > database layer in SQL, you're stealing from your employer. This > presumes, of course, that you're working in a language with a suitable > ORM library available. Well I think that it is just because that there was a lot of man-power putted into ORM frameworks. And that was probably just because of philosophical reasons - not pragmatical. :-) Please see also my other post about my Db access framework. -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
