OO-DBMS
-
jschell wrote:
That suggests design problem where a developer thinks that an Employee and Sales Contact are both People rather than recognizing that there is only Person with different properties.
That's where some of the ambiguity lies for me, and I remember pondering these issues a lot when first learning OO - should Employee and Sales Contact be treated as "is a kind of Person" or should they "have a" role: employee, sales contact, etc., (and of course, possibly multiple roles depending on their relationship to other entities.) There's reason enough to answer "both", as it depends on the circumstances. Ultimately, in my ROP articles by exploring the idea that the relationship itself is a first class denizen of the object world, capable of having its own properties. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
Matthew Faithfull wrote:
And here's one example of why we do need OOP in the real world.
I don't see anything in that description that suggests it has anything to do with OOP. Poor implementation is poor implementation. If anything your description suggests a failure at process control which is a people problem not a technology problem. Or at least on might presume that if stringent code reviews had been in place the quality might have been better.
Matthew Faithfull wrote:
Now just imagine how much fun I'm going to have when I want this code to be thread safe.
That of course has absolutely nothing to do with OOP nor perhaps even process control. If the original app didn't need threads then it would have been unprofessional to write the code to support threads. The fact that requirements change over time is part of business and nothing more than how the real world works.
Remind me not to apply for a job at your place. We'll both be happier that way.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
Matthew Faithfull wrote:
Probably because they don't play nicely with SQL. SQL is very often what management think they understand so it's an unarguable requirement
Wrong. Technologies that offer actual benefits are embraced rapidly across wide spectrums of development. Management seldom makes technology decisions unless that is their job (like a CTO.) Real business managers care about cost, delivery and sales. Technologies that do not provided benefit or which prove detrimental are rejected. And there are many more of those than successes. And it is easy to find examples of failures and successes. "Object Oriented Programming" itself is one of the success cases. CASE Tools as well as OO databases are ones that failed to gain any significance in the development realm because they do not provide benefits. And OO databases have had decades in which to gain acceptance and have not.
Wrong. I used to work with an alternative database product, Multi dimensional OLAP, No SQL and the biggest problem in selling it was that managers install Oracle or SQL Server for the same reason they used to install IBM. The problem was not that it didn't work, it destroyed Oracle by 2 orders of magnitude in many applications but buyers wouldn't look at it because of there exisiting commitment to and investment in SQL technology. Maybe the USA is different but in the UK market having 'actual benefits' means very little at all.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
Wrong. I used to work with an alternative database product, Multi dimensional OLAP, No SQL and the biggest problem in selling it was that managers install Oracle or SQL Server for the same reason they used to install IBM. The problem was not that it didn't work, it destroyed Oracle by 2 orders of magnitude in many applications but buyers wouldn't look at it because of there exisiting commitment to and investment in SQL technology. Maybe the USA is different but in the UK market having 'actual benefits' means very little at all.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
JLengi wrote:
...and very poor, except in terms of abstractions, of modeling dynamic relationships.
I haven't seen that. Dynamic data is exactly what static code manipulates. If there are meta models involved then at least to me, it obvious that the static code then manipulates meta models. The one difference of course is that it is generally harder to derive the required functionality required for the meta model and also to implement that as well. That however is due to complexity and not implementation.
-
JLengi wrote:
OODBMSs are far more flexible and RDBMSs
Nonsense.
JLengi wrote:
One of the strengths of OO is its ability to model and use real-world data and behavior
Good point. Care to explain exactly what business behavior you are putting into your OO database?
JLengi wrote:
OO is generally more applicable to business objects than UI controls.
Which has little to do with persisted data. Just as, for example, it has nothing to do with sending it over IP.
JLengi wrote:
And inheritance, if done properly, is a wonderful abstraction
Yes. It is however a shame that it is often misused.
JLengi wrote:
In many cases where there is conditional logic--and in most cases where there is a type cast--inheritance would have clarified and simplified the code.
Which is something that I almost never see. And I certainly don't remember seeing much of it when I did procedural programming.
I wonder if you are having the same conversation I am having. I didn't say anything about putting behavior in the database. But that's kind of the point of an OODBMS, isn't it? If you can transparently persist your business objects as they are, then you don't need to worry about the interface between your application tier and your data tier. And there are serious advantages to executing your behavior as close to your data as possible, chief among them being performance. Fewer transformations in the case of RDBMSs. And less chattiness between tiers in the case of both RDBMSs and OODBMSs. There will almost inevitably be a proliferation of paths to the data. The "closer to the metal" your business logic is, the fewer places it will need to be implemented, and the less likely your validation/integrity rules will get inadvertently bypassed.
-
Monster Maker wrote:
As we love OO designs in other fields
Pretty sure that my hammer isn't OO. Neither is the keypad on my calculator. Nor for that matter is IP traffic. The idiom applies to a small set of real world solutions and databases are not one of those. For the vast majority of cases, the utility of objects in a database do not match the needs of processing data (not objects) in the database.
Perhaps. The utility of OODBMSs may be an order of magnitude less than that of RDBMSs. But the utility of OODBMSs is at least an order of magnitude greater than their current acceptance. (I.e., there are many applications that could and should use them but don't.) And the utility of OODBMSs would be an order of magnitude greater still if there were a little more investment in them (e.g., a standardized query language). The DBMS landscape has not reached equilibrium and is currently shifting away from relational and ACID.
-
When they say managed languages are slow, they never consider that managed languages are also OO languages. Then they put the blame on Garbage Collectors and on automatic memory management. I am starting to get tired of this shit. OO "architectures" are what is making the application get slow, endless series of patterns just for the new "agile" people be happy. Poor garbage collectors, they are excellent technology that free us from having to deal with memory cycle, just like when you have manual clutch on your car and get an automatic car. But they are getting all the burden of entire OO world alone.
-
And here's one example of why we do need OOP in the real world. I'm currently refactoring a library of a few dozen classes. This job is taking approximately twice as long as it otherwise would because the original author although a undoubtedly a genius did not bother over much with that basic tennet of OOP encapsulation. The library is full of public data members and friend declarations so that whenever I change the internals of class I have to trawl the whole library fixing errors all over the place where code is diving into the internals of other classes and modifying unencapsulated data. Now just imagine how much fun I'm going to have when I want this code to be thread safe. +5 for OOP :)
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
SRP is more important than OO. Single responsibility problem, if OO is pillars, the SRP is the foundation.
-
SRP is more important than OO. Single responsibility problem, if OO is pillars, the SRP is the foundation.
Agreed. Single responsibility is the foundation but then it's a foundation of OO and C++ as well when it's known as the ODR.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
And here's one example of why we do need OOP in the real world. I'm currently refactoring a library of a few dozen classes. This job is taking approximately twice as long as it otherwise would because the original author although a undoubtedly a genius did not bother over much with that basic tennet of OOP encapsulation. The library is full of public data members and friend declarations so that whenever I change the internals of class I have to trawl the whole library fixing errors all over the place where code is diving into the internals of other classes and modifying unencapsulated data. Now just imagine how much fun I'm going to have when I want this code to be thread safe. +5 for OOP :)
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
Funnily enough bad programmers programme badly whichever language they programme in. Thinking OOP used in the way you want will fix bad programmers indicates I have a bridge I could sell ya. One careful owner.
Wolja wrote:
bad programmers programme badly whichever language they programme in.
Sure but the problem we can solve is that good programmers program unreadable, unmaintainable, unportable code because they are clever enough to a) get away with it and b) fix it if they need to, while the rest of us are not. This is what is wrong with half the Linux soure base, almost all GNU software outside the BFD and frankly the majority of potentially useful open soure software out there. People so clever that 7000 lines of unformated linear C code doesn't phase them are indeed clever but they are also almost entirely elephanting useless while they've forgotten that 7000 lines of unformated linear C ( with 2 letter variable names ) is not a useful form of communication between human beings and that is what software is. Otherwise we'd all be writing in assembly language.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
Perhaps. The utility of OODBMSs may be an order of magnitude less than that of RDBMSs. But the utility of OODBMSs is at least an order of magnitude greater than their current acceptance. (I.e., there are many applications that could and should use them but don't.) And the utility of OODBMSs would be an order of magnitude greater still if there were a little more investment in them (e.g., a standardized query language). The DBMS landscape has not reached equilibrium and is currently shifting away from relational and ACID.
JLengi wrote:
there are many applications that could and should use them but don't
Nope. For applications that persist data there are a very large number for which it doesn't matter how they persist it. The business is too small, too fragmented and/or to disorganized for it to matter how they persist it. Of the remainder they have specific functional needs which often center around 'performance'. Differing business categories relegate how performance can be best achieved but regardless what the core business a majority of those domains are still dependent on customers. And there is a vast array of business products with can be used via the relational model and with little or no work and used to drive revenue. Which is what businesses care about.
JLengi wrote:
The DBMS landscape has not reached equilibrium and is currently shifting away from relational and ACID
Presumably you have some actual data to demonstrate that.
-
Wrong. I used to work with an alternative database product, Multi dimensional OLAP, No SQL and the biggest problem in selling it was that managers install Oracle or SQL Server for the same reason they used to install IBM. The problem was not that it didn't work, it destroyed Oracle by 2 orders of magnitude in many applications but buyers wouldn't look at it because of there exisiting commitment to and investment in SQL technology. Maybe the USA is different but in the UK market having 'actual benefits' means very little at all.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
I used to work with an alternative database product, Multi dimensional OLAP, No SQL and the biggest problem in selling it was that managers install Oracle or SQL Server for the same reason they used to install IBM. The problem was not that it didn't work, it destroyed Oracle by 2 orders of magnitude in many applications but buyers wouldn't look at it because of there exisiting commitment to and investment in SQL technology.
Nope. What you are doing is relating some sales to the market as a whole. For example you are specifically comparing only two commercial products while ignoring those that are free. And business managers do in fact like free products.
-
Alas, I had somewhat the same experience. When we were using GemStone/S, many potential customers asked what database we were using for out back end. They had no need nor intention of querying the data directly, but they wanted warm fuzzies.
JLengi wrote:
had no need nor intention of querying the data directly
Were you selling an application (singular app) or a system? Because that data, far as I can tell, represents and application by itself. Which means that there is an operation cost with it. Which the customer, not you, would be providing. If they were an Oracle shop then they would have already had the operational support in place to support Oracle.
-
Remind me not to apply for a job at your place. We'll both be happier that way.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
Remind me not to apply for a job at your place. We'll both be happier that way.
Perhaps. I am certainly not a fan of developers that think that over-engineering based on fantasy business scenarios in the far future is a good thing.
-
I wonder if you are having the same conversation I am having. I didn't say anything about putting behavior in the database. But that's kind of the point of an OODBMS, isn't it? If you can transparently persist your business objects as they are, then you don't need to worry about the interface between your application tier and your data tier. And there are serious advantages to executing your behavior as close to your data as possible, chief among them being performance. Fewer transformations in the case of RDBMSs. And less chattiness between tiers in the case of both RDBMSs and OODBMSs. There will almost inevitably be a proliferation of paths to the data. The "closer to the metal" your business logic is, the fewer places it will need to be implemented, and the less likely your validation/integrity rules will get inadvertently bypassed.
JLengi wrote:
I wonder if you are having the same conversation I am having. I didn't say anything about putting behavior in the database.
I quoted what I responded to. If didn't mean that the you really need to re-state/re-phrase the following because it certainly seems to suggest that a OO database has behavior. "OODBMSs are far more flexible and RDBMSs.... One of the strengths of OO is its ability to model and use real-world data and behavior."
JLengi wrote:
If you can transparently persist your business objects as they are, then you don't need to worry about the interface between your application tier and your data tier.
I would certainly be interested in seeing that. Having used many databases, many types of abstractions and several OODBMs, I have certainly never seen that. I can suppose however that smaller simpler applications might have that feature. But I don't work on applications like that.
JLengi wrote:
And there are serious advantages to executing your behavior as close to your data as possible
I can agree with that. Of course the problem is that in complex systems it is often not possible to centralize even a majority of the business logic in one place. So it means little.
JLengi wrote:
chief among them being performance.
Nope. The only time I see performance problems that are based on the context you are suggesting it is because of design and architecture errors.
JLengi wrote:
and the less likely your validation/integrity rules will get inadvertently bypassed.
Can't say that I have ever seen that happen. Certainly it can't happen with integrity rules in a relational database.
-
JLengi wrote:
had no need nor intention of querying the data directly
Were you selling an application (singular app) or a system? Because that data, far as I can tell, represents and application by itself. Which means that there is an operation cost with it. Which the customer, not you, would be providing. If they were an Oracle shop then they would have already had the operational support in place to support Oracle.
The database was GemStone/S. We were a VAR and licensed and packaged it with the application. We provided tech support for database issues along with application issues. No administration was required after installation. Hot backups were automated, but the customer was responsible for archiving the backup files, if desired.
-
Matthew Faithfull wrote:
I used to work with an alternative database product, Multi dimensional OLAP, No SQL and the biggest problem in selling it was that managers install Oracle or SQL Server for the same reason they used to install IBM. The problem was not that it didn't work, it destroyed Oracle by 2 orders of magnitude in many applications but buyers wouldn't look at it because of there exisiting commitment to and investment in SQL technology.
Nope. What you are doing is relating some sales to the market as a whole. For example you are specifically comparing only two commercial products while ignoring those that are free. And business managers do in fact like free products.