Has OO <-> Relational mapping matured?
-
Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?
-
Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?
I have heard good things about Deklarit, have not used it myseslf though. regards, Paul Watson Bluegrass South Africa Anna-Jayne Metcalfe wrote: "Cynicism has it's place in life - but it should be kept well away from your inner self." Crikey! ain't life grand?
-
Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?
When I last spoke with a researcher on the subject (some German guy - a self proclaimed authority on the subject, with books and papers to back it up - whatever that means), back in 2000, there were still major issues that had to be solved. As I wasn't (and still isn't) very interested in databases, I didn't pay much attention to what he said. I just nodded, pretending to be interested, thinking "GOOOOOD! MAKE THIS BORING MAN GO AWAY!". Usually when these people, even if they are not the least practical, says there is a problem, they're often right. It might not be apparent to the average DBA-henchman straight away. But usually the problems shows up when the level of complexity arises. That's when you go "Shit. The bastard was right!". Anyway, that was 3 years ago. Maybe something has happened, making it worthwhile. I wouldn't know though, because I plan to stay away from databases as much as I possibly can. I'm absolutely, positively sure that the reason why my hair is getting thinner every year, is exposure to databases. -- The moment of terror is the beginning of life.
-
Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?
Personally, I don't buy into the OO <-> Relational auto-mapping at all. It completely ties your data structure to your object model structure. Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. The design of the OO model should seek to encapsulate data into entities with the intent of cleanly expressing the operations that can be performed on them. The design of a relational database should be capturing the raw data in as normal a form as possible so that relationships can be inferred. I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. This is an old idea without any technologically fundamental roadblocks, and I think that if it was really useful it would have found its way into the mainstream by now... -- Russell Morris "So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
-
Personally, I don't buy into the OO <-> Relational auto-mapping at all. It completely ties your data structure to your object model structure. Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. The design of the OO model should seek to encapsulate data into entities with the intent of cleanly expressing the operations that can be performed on them. The design of a relational database should be capturing the raw data in as normal a form as possible so that relationships can be inferred. I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. This is an old idea without any technologically fundamental roadblocks, and I think that if it was really useful it would have found its way into the mainstream by now... -- Russell Morris "So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
But I think it has, in Javaland. One of the big debates among jarheads right now is whether to use Java Data Objects (usually called just JDO) or the container-managed persistence (CMP) feature of EJBs, or some other technology. Personally, I always roll my own persistence code, for lots of reasons. I agree with you big-time that modeling a relational database the OO way is a very bad business. It's impossible to have a one-to-one relationship between data classes and tables in anything but the simplest application, but I've seen people make some really ugly 'object-oriented' relational DBs. DBs auto-generated from an object model are guaranteed to be crappy for this reason. One of the things that I find neat about JDO is that you just write your classes the way you normally would, without worrying about persistence at all. The JDO stuff acts as a preprocessor when you compile; it emits a bunch of persistence-related code. I think that you can also use JDO with explicit mappings, as you can with CMP, that let your objects be mapped more correctly onto a relational structure. That sort of scheme might turn out all right, and I like that you don't have to pollute your clean object model OR write a big persistence layer. I'm sure that .NET has similar stuff in it or on the way, but I'm still exploring! My biggest areas of worry with auto-generated persistence code always have to do with transaction handling. When you have to do persistence operations with a composite object, each with its own persistence handler, how do the transactions trickle across boundaries? I've heard horror stories of performance problems due to excessive locking, etc. I guess you can set up anything to work correctly, but you shouldn't need a PhD in some proprietary technology to do it, IMHO. EJB's big failing is that it's tough to use. Regards, Jeff Varszegi
-
When I last spoke with a researcher on the subject (some German guy - a self proclaimed authority on the subject, with books and papers to back it up - whatever that means), back in 2000, there were still major issues that had to be solved. As I wasn't (and still isn't) very interested in databases, I didn't pay much attention to what he said. I just nodded, pretending to be interested, thinking "GOOOOOD! MAKE THIS BORING MAN GO AWAY!". Usually when these people, even if they are not the least practical, says there is a problem, they're often right. It might not be apparent to the average DBA-henchman straight away. But usually the problems shows up when the level of complexity arises. That's when you go "Shit. The bastard was right!". Anyway, that was 3 years ago. Maybe something has happened, making it worthwhile. I wouldn't know though, because I plan to stay away from databases as much as I possibly can. I'm absolutely, positively sure that the reason why my hair is getting thinner every year, is exposure to databases. -- The moment of terror is the beginning of life.
Jörgen Sigvardsson wrote: I plan to stay away from databases as much as I possibly can If you have no data to store, that shouldn't be a problem. Otherwise databases are the way to go. 60% of statistics are made up on the spot
-
Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?
YES. NO. OK, maybe I'm being a little vague. I have developed an Object-Relational technology over the past few years and I try to keep up with the latest/greatest? stuff. OR solutions typically promise more than they deliver, but what technology doesn't? If what you want is to free your code from direct DB access, allow for easy integration of database schema changes and mostly avoid SQL statements and writing simple stored procedures, OR solutions can do that for you. If you want all of this with the flexibility C++ developers usually want (ie. total control over performance, transactions, timing, etc), forget about it. OR solutions (at least to this point) are platforms upon which you build your applications. As such, they force you, the developer, to use them in a certain way that works for them, but may not be comfortable and often restricts you in ways you are not ready to deal with such as restricting you from directly modifying tables, limiting DB access, optimizing the timing of queries, etc. I love using my OR system for about 80% of the stuff I do because it makes me more productive and frees me from writing simple stored procedures, dynamic SQL, etc MOST of the time. I have tried to make it as flexible as possible, but there are times when I want/need to just bypass it and do whatever it is I want to do. I have to write more code, but if I feel it's warranted, then so be it. One of the ways I have made this possible is by making the database integration within my OR system very flexible and lightweight. It is easy for me to start a transaction one place and end it another, or just rely on the OR to take care of the transactions. I can programatically manage the DB connections or just let the OR take care of it. So, having said all of that, here are the pros/cons I can list from my experience. (I have played with other OR solutions and the problems seem to be constant.) PROS: - Getting data to/from a database, XML file, flat file, etc is just plain simple - Spreading a record across databases (and/or files) is easy with full transactional support - Providing for in-memory/multi-server caching is often automatic - Less code (DB access code) when you work with the tool. - Have to write very little SQL or stored procedures (ie. automatic generation of stored procedures/dynamic SQL as needed) - Don't have to remember how to deal with differences in DB platforms (Oracle, SQL Server, MS Access, DB2, etc) - Ability to have features easily accessible to all objects (change his
-
Personally, I don't buy into the OO <-> Relational auto-mapping at all. It completely ties your data structure to your object model structure. Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. The design of the OO model should seek to encapsulate data into entities with the intent of cleanly expressing the operations that can be performed on them. The design of a relational database should be capturing the raw data in as normal a form as possible so that relationships can be inferred. I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. This is an old idea without any technologically fundamental roadblocks, and I think that if it was really useful it would have found its way into the mainstream by now... -- Russell Morris "So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
Oh thank goodness!!!! A beacon of light in the dense fog of application development with databases!!! I am not alone in my way of thinking! Thank you, thank you, thank you! Seriously, I don't think I've ever heard someone else say the same things I've been saying for years now. All I get is blank stares. Argh. Marc Latest AAL Article My blog Join my forum!
-
Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?
Russel said it really well, and I have to ask, why are you mirroring your schema with objects? Your schema is tuned to the relationships of your data in a persistent medium, which is often a very different format than the application requires, both to operate on transient data in the business layer and for displaying data in the presentation layer. So, why are you doing it this way? It's wrong! Marc Latest AAL Article My blog Join my forum!
-
YES. NO. OK, maybe I'm being a little vague. I have developed an Object-Relational technology over the past few years and I try to keep up with the latest/greatest? stuff. OR solutions typically promise more than they deliver, but what technology doesn't? If what you want is to free your code from direct DB access, allow for easy integration of database schema changes and mostly avoid SQL statements and writing simple stored procedures, OR solutions can do that for you. If you want all of this with the flexibility C++ developers usually want (ie. total control over performance, transactions, timing, etc), forget about it. OR solutions (at least to this point) are platforms upon which you build your applications. As such, they force you, the developer, to use them in a certain way that works for them, but may not be comfortable and often restricts you in ways you are not ready to deal with such as restricting you from directly modifying tables, limiting DB access, optimizing the timing of queries, etc. I love using my OR system for about 80% of the stuff I do because it makes me more productive and frees me from writing simple stored procedures, dynamic SQL, etc MOST of the time. I have tried to make it as flexible as possible, but there are times when I want/need to just bypass it and do whatever it is I want to do. I have to write more code, but if I feel it's warranted, then so be it. One of the ways I have made this possible is by making the database integration within my OR system very flexible and lightweight. It is easy for me to start a transaction one place and end it another, or just rely on the OR to take care of the transactions. I can programatically manage the DB connections or just let the OR take care of it. So, having said all of that, here are the pros/cons I can list from my experience. (I have played with other OR solutions and the problems seem to be constant.) PROS: - Getting data to/from a database, XML file, flat file, etc is just plain simple - Spreading a record across databases (and/or files) is easy with full transactional support - Providing for in-memory/multi-server caching is often automatic - Less code (DB access code) when you work with the tool. - Have to write very little SQL or stored procedures (ie. automatic generation of stored procedures/dynamic SQL as needed) - Don't have to remember how to deal with differences in DB platforms (Oracle, SQL Server, MS Access, DB2, etc) - Ability to have features easily accessible to all objects (change his
Hi Matt, I enjoyed reading your pros and cons--very thoughtful. I have a question though, based on some experience on a few projects. Because of the iterative nature of these projects (they weren't fully designed up front because the client wanted to develop them in stages and not commit 100% $$$), I ended up changing the schema radically a couple of times in certain areas. If I'd used an OR solution, it would have broken tons of code. Instead, I was able to rewrite the pertinent SQL without affecting the code. Now, certainly, I could have written wrappers around the OR solutions, but that seems a bit code heavy. On a side note, another project was using an OR solution, but they had a DB group writing insert, select, update and delete methods for each class that represented a table. Very time consuming, and then the DB group manager had the brilliant (sarcasm there) idea of writing a code generator. What a laugh, and thank god my manager agreed early on that anything this guy said and did was to be ignored. I pitied the other teams who had to use his way of thinking (this was the same guy who refused to use referential integrity because he wanted his schemas to be as cross-platform compatible as possible). Anyways, the DB group didn't know any better, so they stuck all the class definitions IN THE SAME HEADER FILE! Change one class, and the project took over an hour to rebuild. Add a class, and the project took over an hour to rebuild. Like I said, thank god I yanked my project away from his lunacy when I came on board. So, OR solutions are a bit like playing with a nuclear bomb. It seems that they can cause a heck of a lot of grief if misdirected. Marc Latest AAL Article My blog Join my forum!
-
Personally, I don't buy into the OO <-> Relational auto-mapping at all. It completely ties your data structure to your object model structure. Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. The design of the OO model should seek to encapsulate data into entities with the intent of cleanly expressing the operations that can be performed on them. The design of a relational database should be capturing the raw data in as normal a form as possible so that relationships can be inferred. I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. This is an old idea without any technologically fundamental roadblocks, and I think that if it was really useful it would have found its way into the mainstream by now... -- Russell Morris "So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
I have to disagree with you here. Ultimately every application that uses a DB must map data from the DB to internal objects. Quite often, this work is tedious and repetitive, exactly what application frameworks are designed to simplify and automate. I will say that auto-mapping is often dangerous, but that represents only a very small part of OR systems. The good OR solutions allow a developer to specify the mapping from the DB to objects in ways that automation cannot. Just my 2 cents.
-
Hi Matt, I enjoyed reading your pros and cons--very thoughtful. I have a question though, based on some experience on a few projects. Because of the iterative nature of these projects (they weren't fully designed up front because the client wanted to develop them in stages and not commit 100% $$$), I ended up changing the schema radically a couple of times in certain areas. If I'd used an OR solution, it would have broken tons of code. Instead, I was able to rewrite the pertinent SQL without affecting the code. Now, certainly, I could have written wrappers around the OR solutions, but that seems a bit code heavy. On a side note, another project was using an OR solution, but they had a DB group writing insert, select, update and delete methods for each class that represented a table. Very time consuming, and then the DB group manager had the brilliant (sarcasm there) idea of writing a code generator. What a laugh, and thank god my manager agreed early on that anything this guy said and did was to be ignored. I pitied the other teams who had to use his way of thinking (this was the same guy who refused to use referential integrity because he wanted his schemas to be as cross-platform compatible as possible). Anyways, the DB group didn't know any better, so they stuck all the class definitions IN THE SAME HEADER FILE! Change one class, and the project took over an hour to rebuild. Add a class, and the project took over an hour to rebuild. Like I said, thank god I yanked my project away from his lunacy when I came on board. So, OR solutions are a bit like playing with a nuclear bomb. It seems that they can cause a heck of a lot of grief if misdirected. Marc Latest AAL Article My blog Join my forum!
Marc Clifton wrote: If I'd used an OR solution, it would have broken tons of code. With many OR solutions, this is true, but not all. Auto-mapping is often dangerous for just this reason. The solution I use makes it very easy for me to alter the DB schema (ie. normalize it/denormalize it, add fields, etc) without breaking code. I have almost total control over the mapping behaviour of the system. Just about every project I have right now (there are quite a few) are on the iterative path and DB schema changes are frequent. In my case, my solution means that I am not constantly changing stored procedures/dynamic SQL to accomodate DB changes. In fact, I have not written a stored procedure for quite some time, though I use 100s of them and produce more all the time. One thing I see from your description is that the OR solutions you worked with relied on the generation of one-to-one mapping classes (ie. table/view wrappers) in addition to you creating the actual application objects. My solution lets me create my objects and there is a standard engine that deals with the mapping of data in table/views to various objects. Typically, there are no generated classes represenging tables. Instead, a standard engine (ie. CEDDEntity and a bunch of other classes) deals with persistence to-from the DB, representing the table/view and related tables/views in memory as needed. For simple tasks I often don't even have a business object, I just go directly to the entity. When I do have a specific business-object, either I generate code (through a configuration) to map the entity to the class or do it by hand in the most optimized way I need. This way I get the best of both wolds with little overhead in the mapping process and almost no entanglement to the data structures. In my C++ code, I can derive from the CEDDEntity (or related classes), or use a compopsite template to derive from or internalize the entity or just provide static-mapping depending on my needs. On my current at-home project (see Life of a Project series), I have added support to the OR engine to automatically generate stored procedures for DB updates so that only the minimal amount of DB traffic is generated. The system automatically determines if it has encountered a particular update situation before (field 1,2,3) and if not, generates a new stored procedure for that specific update. Then it reuses that stored procedure in the future. Another thing I can do easily is use web services to persist data with
-
Marc Clifton wrote: If I'd used an OR solution, it would have broken tons of code. With many OR solutions, this is true, but not all. Auto-mapping is often dangerous for just this reason. The solution I use makes it very easy for me to alter the DB schema (ie. normalize it/denormalize it, add fields, etc) without breaking code. I have almost total control over the mapping behaviour of the system. Just about every project I have right now (there are quite a few) are on the iterative path and DB schema changes are frequent. In my case, my solution means that I am not constantly changing stored procedures/dynamic SQL to accomodate DB changes. In fact, I have not written a stored procedure for quite some time, though I use 100s of them and produce more all the time. One thing I see from your description is that the OR solutions you worked with relied on the generation of one-to-one mapping classes (ie. table/view wrappers) in addition to you creating the actual application objects. My solution lets me create my objects and there is a standard engine that deals with the mapping of data in table/views to various objects. Typically, there are no generated classes represenging tables. Instead, a standard engine (ie. CEDDEntity and a bunch of other classes) deals with persistence to-from the DB, representing the table/view and related tables/views in memory as needed. For simple tasks I often don't even have a business object, I just go directly to the entity. When I do have a specific business-object, either I generate code (through a configuration) to map the entity to the class or do it by hand in the most optimized way I need. This way I get the best of both wolds with little overhead in the mapping process and almost no entanglement to the data structures. In my C++ code, I can derive from the CEDDEntity (or related classes), or use a compopsite template to derive from or internalize the entity or just provide static-mapping depending on my needs. On my current at-home project (see Life of a Project series), I have added support to the OR engine to automatically generate stored procedures for DB updates so that only the minimal amount of DB traffic is generated. The system automatically determines if it has encountered a particular update situation before (field 1,2,3) and if not, generates a new stored procedure for that specific update. Then it reuses that stored procedure in the future. Another thing I can do easily is use web services to persist data with
Wow Matt, this sounds excellent, and that you've put a lot of thought into the design. It's really a shame you can't sell this engine or somehow make it available. I'd sure love to play with it and see how it works. And I really like what you said about web services also--very nice. Matt Gullett wrote: I agree with this statement, though I think it applies to most frameworks you use since entanglement and loss of control is where the real problem lies. he he. Definitely. Marc Latest AAL Article My blog Join my forum!
-
Wow Matt, this sounds excellent, and that you've put a lot of thought into the design. It's really a shame you can't sell this engine or somehow make it available. I'd sure love to play with it and see how it works. And I really like what you said about web services also--very nice. Matt Gullett wrote: I agree with this statement, though I think it applies to most frameworks you use since entanglement and loss of control is where the real problem lies. he he. Definitely. Marc Latest AAL Article My blog Join my forum!
Thanks for the kind words. I feel like I've invested a large piece of my life into this system, but I know that selling it is an impossibility. From my research, I'd say that most developers are not prepared to switch to a solution like this one, and I freely admit that just like your AAL, it requires a change in the way developers think. Probably the biggest thing going against it is that it is more usefull for new projects than for modifying/maintaining existing ones. So many systems are built/rebuilt/expanded/reused that many developers will be adverse to trying it. Also, developers tend to be adverse to new ways of thinking for some reason. I am hoping that myself and my boss/good friend can use it to build some commercial apps to be sold. For the time being, it has helped me make my current employers system work and work well. In the long term I think it will be released into the public domain, but that will be some time from now.
-
Personally, I don't buy into the OO <-> Relational auto-mapping at all. It completely ties your data structure to your object model structure. Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. The design of the OO model should seek to encapsulate data into entities with the intent of cleanly expressing the operations that can be performed on them. The design of a relational database should be capturing the raw data in as normal a form as possible so that relationships can be inferred. I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. This is an old idea without any technologically fundamental roadblocks, and I think that if it was really useful it would have found its way into the mainstream by now... -- Russell Morris "So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
Russell Morris wrote: Personally, I don't buy into the OO <-> Relational auto-mapping at all. It completely ties your data structure to your object model structure Ummm...I can't agree with this, in fact it doesn't make any sense. One of the main reasons a person needs to do OO<->Relational mapping is because the data structure *doesn't* match the Object structure. (or I've been doing something drastically wrong all this time!:-D ) Unless you have an object oriented database it's always going to be the case. Now I *can* see such a tool generating stored procedures and data access layer code to call them, that's boring and repetitive and would be more suited to a visual "designer" type program that generates the code, but you still choose the data.
|----------------------2--0-------------------------0-----------------|
|--------0--2-----3----------3--2--0--------0--0b2-----2--3--2--0-----|
|--3--3--------3----------------------3--3-------------------------3--|
I support two teams: the Canucks and whoever is playing the Leafs! -
Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?
Object-oriented programming. Relational databases. Satan worship. Think about it. :suss:
Software Zen:
delete this; -
Jörgen Sigvardsson wrote: I plan to stay away from databases as much as I possibly can If you have no data to store, that shouldn't be a problem. Otherwise databases are the way to go. 60% of statistics are made up on the spot
-
Personally, I don't buy into the OO <-> Relational auto-mapping at all. It completely ties your data structure to your object model structure. Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. The design of the OO model should seek to encapsulate data into entities with the intent of cleanly expressing the operations that can be performed on them. The design of a relational database should be capturing the raw data in as normal a form as possible so that relationships can be inferred. I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. This is an old idea without any technologically fundamental roadblocks, and I think that if it was really useful it would have found its way into the mainstream by now... -- Russell Morris "So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
Russell Morris wrote: Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. Not so. Well maybe sometimes. The applications I tend to be involved in are purpose built server based systems with web client interfaces. Obviously there are certain data sharing requirements with other systems, but those are almost without fail expressed through the application layer, via web services or what-have-you. Most applications have data persistance requirements (except perhaps minesweeper), and when you are talking about highly scalable, highly transaction, blah blah server apps you need a data storage/access solution that is fast. That is where the relational DB comes into play. Now I know there are OO databases out there, but I really haven't that much exposure to them, but perhaps that is the way to get around the OO <-> relational problem. Russell Morris wrote: I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. I disagree; the problem is that relational databases were not designed to solve the problem of persisting OO data, and hense whenever we try to use a RDB for that purpose, well there just aren't any clear and common guidelines. I think it is fair to say that if there was a way of solving the mapping problem that was more right than all the others than it would be a defacto standard by now. Thanks for your view though, it has got me thinking...
-
YES. NO. OK, maybe I'm being a little vague. I have developed an Object-Relational technology over the past few years and I try to keep up with the latest/greatest? stuff. OR solutions typically promise more than they deliver, but what technology doesn't? If what you want is to free your code from direct DB access, allow for easy integration of database schema changes and mostly avoid SQL statements and writing simple stored procedures, OR solutions can do that for you. If you want all of this with the flexibility C++ developers usually want (ie. total control over performance, transactions, timing, etc), forget about it. OR solutions (at least to this point) are platforms upon which you build your applications. As such, they force you, the developer, to use them in a certain way that works for them, but may not be comfortable and often restricts you in ways you are not ready to deal with such as restricting you from directly modifying tables, limiting DB access, optimizing the timing of queries, etc. I love using my OR system for about 80% of the stuff I do because it makes me more productive and frees me from writing simple stored procedures, dynamic SQL, etc MOST of the time. I have tried to make it as flexible as possible, but there are times when I want/need to just bypass it and do whatever it is I want to do. I have to write more code, but if I feel it's warranted, then so be it. One of the ways I have made this possible is by making the database integration within my OR system very flexible and lightweight. It is easy for me to start a transaction one place and end it another, or just rely on the OR to take care of the transactions. I can programatically manage the DB connections or just let the OR take care of it. So, having said all of that, here are the pros/cons I can list from my experience. (I have played with other OR solutions and the problems seem to be constant.) PROS: - Getting data to/from a database, XML file, flat file, etc is just plain simple - Spreading a record across databases (and/or files) is easy with full transactional support - Providing for in-memory/multi-server caching is often automatic - Less code (DB access code) when you work with the tool. - Have to write very little SQL or stored procedures (ie. automatic generation of stored procedures/dynamic SQL as needed) - Don't have to remember how to deal with differences in DB platforms (Oracle, SQL Server, MS Access, DB2, etc) - Ability to have features easily accessible to all objects (change his
I think you mentioned some of the most important aspects that are often missing from the OR solutions that I have seen in the past, or that become issues if you let your team rely to heavily on them. Matt Gullett wrote: Providing for in-memory/multi-server caching is often automatic Having just finished off a n-wide scalable application - i.e. designed to live on as many application servers as you can afford without concurrency issues etc. - it become aparent early in the project that we would need to cache some of the heavily used objects in memory. Why? Because they were heavy in terms of database lookups; each object in the cache (~100 of them) consisted of 2 arrays of maybe a dozen other objects, and each of those contained an array of maybe another 30-40 objects. As you can imagine, that would require a shit load of database hits to instantiate each of those objects on demand without caching. Caching leads to version compatability problems, i.e. how do you refresh the caches of the the n-application servers in your farm, and now we are talking about a serious amount of overhead (resource and programming), just so that we can write our server app in an OO paradigm. Then there are other problems that enter the fray, like dealing with NULLs, casting types that might be NULL, matching primary keys to refrences, and the worst of it is that someone thoughtlessly uses an object to check one property that cost 10 database hits to retrieve, instead of writing a specialized stored proc to get in one hit. I think yo uare right though, I am just going to have to put aside a few weekends to research as many of them as possible until I find utopia.
-
Russel said it really well, and I have to ask, why are you mirroring your schema with objects? Your schema is tuned to the relationships of your data in a persistent medium, which is often a very different format than the application requires, both to operate on transient data in the business layer and for displaying data in the presentation layer. So, why are you doing it this way? It's wrong! Marc Latest AAL Article My blog Join my forum!
The problem is that the schema doesn't mirror the objects. What I currently have working - without using an OO to Relational mapping tool - is a somewhat hyrbid OO/procedural service approach. That needs an example to explain for sure. What I mean is that I have objects which are instantiated using a static Load method, and any consistuent objects or collections of objects are loaded on demand via their getter property. The object can then be used as an object, rather than having a class with lots of static methods for performing operations on instances of that class directly in the database. Any objects that are expensive to instantiate, or are used fequently, are cached. The hybridness of the approach is that there are still certain methods which better suit the procedural service pattern, where a method such as "List me all the Customer objects with money still owing and living in canada, in an ADO Dataset, sorted by last name, without populating their Addresses collection" can be implemented as a static method of the class. These are handy for those presentation layer requirements - there is certainly no need to go creating "fat" objects to pass back to the presentation layer. My problem with hybrid approaches like these, though, are that they leave a bad taste in the mouth. Even after 3 showers and a full body exploiation I still feel a little dirty - and not in an Aguilera kind of way.