Are Oo And Relational Orthogonal Discussion
Are Oo And Relational Orthogonal Discussion(moved from MindOverhaulEconomics)
OO and relational are orthogonal. One provides a way to structure code. The other provides a way to structure data. There is no need to overhaul one's mind to adopt either of them.
I disagree. They often fight over the same territory, and code and data are often interchangeable (DataAndCodeAreTheSameThing). Much of OO is about managing or wrapping state, and this is where most of the overlap is.
OO and relational don't fight; people do. Once you decide what should be code and what should be data there's nothing to fight about.
Well, how about "their philosophies overlap". See ReinventingTheDatabaseInApplication and TablesAndObjectsAreTooDifferent. OO has a fundamental NavigationalDatabase-like structure, which is a round peg to the square hole of relational tables. Relational requires data be in a certain "shape", which OO does not. You cannot easily inter-mix the two, so you are generally forced to pick one or the other as the primary underlying organizational philosophy or accept nasty compromises.
OO doesn't have a fundamental NavigationalDatabase-like structure.
What definition of OO are you using?
OO is most definitely not orthogonal, relational and OO have much overlap. Saying they are orthogonal is a GrossOverSimplification of the matter. OO stores and deals with data just as SQL inserts and updates do. I've seen people create classes that manage an IniFile. Instead of creating an object that maps to an IniFile, why couldn't you map the IniFile to tables or relational? Of course you could if we had tables as first class citizens in our popular programming languages. And why is it that we could use either OO or use tables to map to a IniFile? The answer is because similar to TuringComplete, object and relational are NOT orthogonal, they are similar (just like TuringComplete mind game). An object can save data, just like a language like SQL can using "INSERT" and "UPDATE". If they were so orthogonal, then there wouldn't be object relational mappers out there! The third manifesto oversimplifies the matter too, claiming that "classes = types". Classes do not equal types, the same way Structs in Cee do not equal types. A struct or a class is a kind of type, it is not equal to type. Class variables (objects) and struct variables are similar enough to rows in a table that they have much overlap. Struct typedefs and class typedefs are similar to database schemas (table definitions). There is huge huge overlap and denying this overlap is just GrossOverSimplification. See also IsIniFileRelational.
OO allows any structure you want. There is no need to pick one primary underlying organizational philosophy. Use relational tables where you need them. Use other structures where you need them.
{Is this a TuringEquivalency claim? I can't tell. If so, then your statement is useless because there are a lot of lousy languages and perhaps lousy paradigms that "allows any structure you want". TuringTarpits can also emulate a relational system.}
Also, relational generally assumes that data is shared by many apps and languages, but OO often assumes that a given application "owns" the state. Otherwise, pure encapsulation is violated. (I suppose there could be a "master class" that is shared by multiple applications, but that is essentially OODBMS, which is a NavigationalDatabase, and thus we are back to square one in the debate.)
Neither assumes sharing. RDBMSs assume data is shared, but RDBMSs are one application of relational. OO is neutral, since it can be used to build apps that share data or keep it private.
I believe these issues are covered under SharingDataIsImportant.
SharingDataIsImportant sometimes. OO doesn't force you to share data when it isn't important. It is neutral on the subject because it is just one of many ways to organize computer instructions.
Databases don't force you to share either, BTW. OO tends to organize computer instructions around the "state" or data. That is where the conflict often occurs. Non-OO techniques tend to view such code wrapping as unnecessary coupling to "data-ness".
I've seen very few databases (none of the RDBMSs) that didn't force you to share data. If they run in a separate process they require data sharing to access the data.
NimbleDatabases engines don't require a separate process. I agree they are not in fashion right now, but they exist.
OO doesn't couple code to data any more than procedural does. It just provides abstractions to make it easier to manipulate that coupling.
I would enjoy an example of it manipulating coupling easier besides OverUsedOopExamples.
See most of the refactorings in MartinFowler's book. The subject matter used for the examples doesn't matter. The refactorings apply to patterns of code and are domain agnostic.
Have you seen the RefactoringIsNotRelational topic, BTW?
Yes. It contains some of my words.
Re: MartinFowler's book....The refactorings apply to patterns of code and are domain agnostic.
I don't own the book, by I have thumbed through it multiple times at book stores, and it seems to have an OO-tilt toward it, as I remember it. The "problems" it sees in code tend to be through OO-colored glasses, often assuming an OO view of ChangePatterns.
OO programming and relational tables are orthogonal. The app I'm working on today is a good example. It's purpose is to compare parts of two different web sites. There's no way I could write this in SQL and no reason to use relational tables. It doesn't need fast ad hoc queries. OO programming provides a convenient way to structure the code so that it is easy for me to modify and maintain it.
Depending on the type of comparing you are doing, being able to query the "structures" in a relational query language could be useful in some cases I would imagine. I used to use dBASE (a pseudo-relational tool) for this kind of stuff all the time.
Here are some of the requirements of this app:
Who ever said the relational language has to do the *whole* thing? Nobody writes an entire application using regular expressions, but that does not meant that regular expressions are not useful. One approach to comparing in relational is to do a join of some sort. For example, left-outer join unit A with Unit B to show what is in A but not in B, and a right-join for the reverse (or is it the other way around?). Use could perhaps use an AttributeTable to store the HTML table values.
Who ever said an OO language had to do the whole thing? Not me. You're the one that sees them as competing technologies. I'm the one arguing that OO programming languages are for structuring code and relational tables and query languages are for structuring data. You seem to come from a domain with little emphasis on code and great emphasis on data,
No, I try do de-emphasize code by factoring patterns to data. See CodeAvoidance.
and you seem to imagine that other domains are like yours.
I did not say that. However, I find that a lot of systems utilities could probably be implemented using NimbleDatabases of some sort. The only limitations seem to be if there are very precise timing constraints or it needs to fit in like 20K (I used to use NimbleDatabase engines that fit in 64K.) Timing constraints are an issue because garbage collection might kick in at inopportune times. But LISP and Java also have this problem.
The user doesn't want to see a left or right outer join of the web sites. He wants to see which pages have tables that differ.
We can do that too. I just thought they would also like to see where they differ.
To show him that I need to spawn and join threads, present a GUI, read HTML over a network, parse it and keep my code easy to maintain and modify. I can't do any of that with a relational query language because they are specialized tools for issuing ad hoc queries and not general purpose software development tools. They are orthogonal.
I don't think there really is such thing as a "general purpose" tool/language, except by perhaps catering to the lowest common denominator. An SUV is a more "general purpose" tool than a road car, but SUV's are not optimized for roads. If one was going to use one language for 3 different domains, then something more low-level might be in order. However, I am not sure it is smart to use one language (or paradigm) for all 3 for an extended period of time.
Some languages are more general purpose than others. I can write the application above in Java or C++. I can't write it in SQL because SQL is not a programming language.
Perhaps "general purpose" is not the right word I am looking for. "Suitability to all tasks" is perhaps better.
General purpose is the word I was looking for and the word I used. I'm not saying C++ is suitable to all tasks. I'm saying C++ is more general than SQL.
That I will agree with for now. However, it is moot to the issue. See below.
It isn't moot. OO programming languages are used to write software. Relational query languages are used to search data. They are orthogonal.
It is hard to write software without ANY data. If you let the RDBMS do what it does best, then OO code will not look much different from procedural code (that uses the RDBMS). The biggest difference between procedural and OO are factored into the database if you use the full power of the database. OO is mostly OO when it wraps state/data. If the DB does that instead, then OO is standing around with nothing to do except look rather procedural. I don't think it is practical to let both OO and the database "wrap" the data. It may even be a contradiction to try. Like I said in OoLacksMathArgument, the amount of an algorithm that can be shifted/factored toward a data-centric or algorithm-centric design is generally a continuous scale.
Consider the case of an operation in an HR application for "adding a new employee". If there is a new application or feature request later on that has to "add a new employee", is that new piece going to add through the database or through an Employee.AddNew?() method? (Or whatever constructor convention the OOP language uses.) You can't have it both ways, and thus they are NOT orthogonal. Either you talk to the database, or you talk to the "addNew" method. Sure, addNew could call the database, but that is not a decision concern here. Only one can be the "official" way to add.
Perhaps you are arguing that OO can handle both the data and behavior, but relational only deals with data. (Ignoring DataAndCodeAreTheSameThing for now.) If true, this does not make them orthogonal. It just means that OO covers a wider area.
Perhaps being wider makes OO better, but that is another discussion, perhaps under BenefitsOfOo. IMO, the benefits of specialization apply then. Let relational do best what it does, and the code (usually procedural or functional) do what it does best.
I've not seen this notion mentioned, though I confess that I haven't cruised this entire topic.
It is quite possible to implement a relational database language using an OO language. It is for all practical purposes impossible to implement an OO language using a relational database language.
I'm not quite sure what that implies ...
{Me either. But it was brought up before in OoLacksMathArgument}
It implies that one is more general than the other. Which has been established elsewhere, yes. The benefit of that generality would seem to move quite a bit depending on what page you're on and what point you're trying to defend. Sigh. -- francis
Well, like many things in life, "it depends". Generality is not always good. I will agree that OO is more general than relational; but that open-endedness makes it so that relational math and tabular viewing don't work smoothly. Roll-your-own stamps is more "general" then gov-printed stamps, but it makes mail delivery a real bear. To do systematic management and/or reasoning on things, sometimes we have to place limits on them. Standards are like that too. Standards are limits. These limits make it easier to know what to expect so that communication and info transfer is smoother. If not for the "limits" of building codes (houses, offices, etc.), we'd have shanty towns. (To me, some OO code looks kind of like shanty towns.)
[There is no reason using an OO programming language would prevent anyone from using relational query languages as needed. There are thousands of real world examples of people using both.] Is there any one that you would like to put forth as an example?
That is because databases provide several services (see below). Let's say databases can provide service A,B,C,D,E, and F. You could optionally implement A, B, and C in application code, and use the database for D, E, F. Many OO applications will use varying amounts of these features. However, since the database already provides such services, it is often anti-reuse to reinvent them yourself IMO.
[Do you even read what I write?]
You keep saying the same thing over and over.
I suppose this is one of those topics that cannot be satisfied until we first agree on a definition of OO and/or what the OO methodology is/are. My informal survey of published OO techniques shows me that OO and relational compete in many areas, and are thus not orthogonal.
Since relational query languages are limited to issuing queries in RDBMSs, the only way OO programming languages could compete is if an RDBMS used one as a query language. Which RDBMSs use OO programming languages as query languages?
It is more than just queries. See the list of typical DB services at DatabaseDefinition and OO practices at ReinventingTheDatabaseInApplication. I am not going to have a class called say timeSheets having arrays of lineItems and implement methods like set, get, delete, find, save, sort, lock, etc. I will use the database for most of those, not code. I suppose one could still have those methods and echo it back to the database, but that is a violation of OnceAndOnlyOnce.
You will have them in OO code if you need to do anything SQL doesn't support, which is plenty.
See above about using procedural with RDBMS.
Aha, it all makes sense now. You're the negaverse version of an OODBMS evangelist. They want to come up with distributed serialized buzzword encrusted PrevaylanceLayer?s to keep from writing procedural looking code. You're right. Where an OO app touches an RDBMS it looks just like a procedural app. You want to avoid procedural code from the opposite direction. Good luck to you. I hope one of you comes up with something nice. Until then, the rest of us will keep doing what works for us.
You seem to be suggesting that BenefitsAreSubjective. Perhaps. Relational models my mind pretty well. But the important thing is that you seem to agree that they are not orthogonal when you said, "Where an OO app touches an RDBMS it looks just like a procedural app". The more you use the DB, the less you use OO. Objects originated from physical modeling, where the "nouns" carried around state with them. If the DB carries the state instead, then we are no longer doing "classic" OO. Perhaps some OO fans here no longer subscribe to classic OO. I invite them to describe what kind of OO they do subscribe to.
No, I don't agree that they aren't orthogonal. OO apps also look procedural when they touch a printer. That's the nature of external APIs. The commands an OO app sends to the printer are analogous to the commands it sends to the RDBMS. Using a DB doesn't make code less OO, just like using a printer doesn't make code less OO. My OO code has nothing to do with physical modeling. My classes model concepts. They coalesce through refactoring to give the methods a nice home. Sometimes they map to real world objects, but when they don't I don't sweat it. In most of my apps that talk to databases I'll write one class that insulates the rest of the code from the database. Just like I would for a printer.
If you compare a RDBMS to a printer, then you must be one of those people who use the database only for persistence.
No, I use the database for persistence, data sharing, transaction management and fast ad hoc queries. But the code that interfaces with it looks procedural, just like the code that interfaces with a printer.
Well, we have established that at least some of the code is more or less procedural due to the database. But why don't you use it for the *rest* of the database features listed under DatabaseDefinition? I contend that IF you do, then OO has very little to do that is "OO". For example, why have an Employee object if the data of employees is in the database? The only thing left in an Employee class/object is perhaps methods like "fire". It is then little more than "tasks" physically grouped by entity in classes. The class no longer "wraps" the state but is a mere grouping of functions that operate on employees. It is cutting OO's nuts off.
I use the database for all of the features listed under DatabaseDefinition. If you can figure out a way to write apps without writing apps, I'm all ears. Otherwise I need some sort of programming language in which to write the apps. Right now I use OO programming languages. My apps use the data in the database, but they do a lot of other things that can't be done by a database.
It would be interesting to inspect your code.
"OO" covers a broad range of things. Are you talking object-oriented design? Object-oriented languages? And "relational" is often misused. The usual meaning would be "relational theory" -- there are in fact very few relational databases available on the market today. Although people often use the phrase "relational database", they very rarely use it accurately.
"Relational-based" may be more accurate.
If you're trying to compare relational theory to OO theory, you'll have a hard time. OO theory is diffuse, diverse, and often not rigorous.
That is partly why they are not orthogonal. Either you choose the rigid discipline of relational, or you go with the willy-nilly nature of OO. (I suppose the 3rd option is to translate back and forth between the two, but that is costly.)
To the extent that one can talk about it at all, I'm not sure if it could be labelled "orthogonal" to relational theory, since it tends to (try to) encompass models of data organization.
If you're comparing OO languages to relational databases, which seems more likely, then I would say that they are definitely not orthogonal. Most OO languages are general-purpose languages, and you can certainly organize and manipulate data with them in many ways. But relational database implementations are tailored to the tasks of storing and retrieving large quantities of data efficiently, combining that data in various ways to get customized views of it, letting you state what the correctness requirements for that data are, and ensuring that the data adheres to those constraints. Of course you can do all this in a general-purpose programming language. But, for non-trivial amounts of repetitious data, it will take you many times longer than if you use a tool designed specifically for these tasks. -- DanMuller
I am not sure it is just for "large quantities". I used to use NimbleDatabases to improve the organization and maintainability of code. I look at things like GOF Patterns, and often think of them in terms of relational formulas.
Point granted. As I point out in a later comment on this page, the choice really depends on many factors.
The longer I look at this page, the more I think that the original poster must have an odd definition in mind for the word 'orthogonal'. Further complicating things is that even this term is relative. In the context of many popular programming languages, for instance, it's reasonable to think of the concepts of 'data' and 'code' as orthogonal. And yet, in a language such as Lisp, it's unlikely that someone would say this. This discussion is likely to go nowhere without a more concrete context. -- DanMuller
I may be naive, but isn't OO concerned with the manipulation of data, while Relational is concerned with the persistent storage of data? [See DatabasesAreMoreThanJustStorage] It seems to me that except in the most trivial of programs, persistent storage of data between sessions is needed and Relational technology provides an efficient way to do this. Likewise, it seems that stored data always needs some way to be manipulated and displayed and OO technology provides an efficient way to organize those routines. There are times when it can be difficult to mesh the two, but I am not sure I see the supposed conflict between OO and Relational.
That's a very limited description of OO, by most definitions. Most OO languages are general-purpose, and as such encompass all aspects of programming. "Relational" is not concerned with persistent storage of data per se -- databases in general are. Relational theory is about how to organize data, operate on it conveniently to get various well-defined results, and how to constrain data so that it remains meaningful. If persistence is all that you need, a system based on relational theory may well be overkill. You could only make that judgment in the context of what specific tools you have available, and what your program's requirements are with respect to performance, footprint, development time, etc. -- DanMuller
I didn't mean to oversimplify, so would it be more accurate to say that OO is concerned with the organization and relationship of data manipulation elements, while Relational is concerned with the organization and relationship of stored data? I agree there is a lot of theory behind both OO and Relational, but the essence of each seems to be data manipulation and data storage, respectively. As such, these are largely complementary technologies, in terms of purpose. As the two are based on different organizing principles, there are often conflicts in implementation that require trade-offs on both sides.
As an aside, regarding relational being "overkill" for some systems, I believe that is more a result of cost than underlying technology. File management systems have long been part of operating systems, thus they are "free," while database management systems are (usually) large, expensive add-ons. A lot of programming effort gets wasted in smaller jobs by trying to use the file management system, when a database management system could have handled the job easily. I suspect that the availability of cheap, small databases will change the economics of that decision. [See NimbleDatabase]
No, I wouldn't say that "OO is concerned with the organization of data manipulation elements". OO languages seem usually to be a mere variation on imperative programming languages, adding a means of packaging data and the code that manipulates it, and usually also adding conveniences for selecting different bits of code based on 'types'. (Although even saying that much is shaky, because the notion of types and the details of the dispatch mechanism differ from one OO language to another.)
[I think the dissenter above and I may actually be in agreement. When I said, "OO is concerned with the organization of data manipulation elements," I was merely trying to say that OO was providing a set of rules to organize code into modules and files ("classes").]
{Saying OO is "about types" leans toward the static-typing view of OO. I think many OO'ers would disagree. Also, "types" tends to be a hierarchical concept, but relational is more set-driven. Using set-centric techniques is generally mutually-exclusive to tree-centric techniques in practice (at least in app code). This is part of issue between OO and relational, in my opinion. SetsVersusTypes.}
OO languages are usually general-purpose programming languages with convenient syntactic sugar, and to constrain the definition further is probably futile. So you can do just about anything with them.''
Database manipulation languages (I won't say "relational", because there's really only one such language implemented nowadays) are much more limited and special-purpose. Relational theory is emphatically not primarily about data storage. It is about defining how facts are organized as data, defining constraints on data so that it continues to represent what it is intended to, and how to manipulate the data to derive new facts from existing ones. Additional considerations like transactioning and storage/retrieval efficiency go beyond relational theory, and then you're talking more generally about database systems, which is fine. All of that can be done in a general-purpose language, it's just usually going to be much harder. I don't see how they can be considered orthogonal.
By analogy, take the language awk. Very special-purpose, almost entirely concerned with scanning strings. Would you call awk 'orthogonal' to C++? Hardly. It's just special-purpose, with a more limited domain of application, but much more convenient to use within that domain. Is it easy to make awk and C++ work together? Not particularly, but that doesn't make them orthogonal.
Regarding cost: There's monetary cost, and cost to integrate, possibly also cost to learn, cost in executable size, etc.. Your analogy to file systems is good -- the file system is just there, ready to be used through (in most languages) at-hand APIs, which themselves add little overhead since all the supporting code is in the OS. With database systems, that's rarely the case. So when I said that it might be overkill to use a relational system in some cases, this is based mainly on reasons related to implementation. But practical considerations do count. :-) (Surely, 'NimbleDatabases' might help here, but few of them are even remotely relational, so that seems a bit off-topic.) -- DanMuller
For the sake of discussion, how about we consider multi-user systems. In other words, applications or systems that more than one user may use at the same time.
Summary [I think it may be time to bring this discussion to a conclusion. Please feel free to edit the following strawman statement as you feel necessary. If we can't find a common conclusion, but instead spark the level of quality discussion above, that would be fine as well!]
The underlying theories of OO and Relational are orthogonal; neither even references the other. The theory of OO is largely concerned with organizing actions based on the data being acted upon, while Relational is largely concerned with organizing data based on ...("actions that may be performed on the data." - Relational people, please help. Make sure this is an accurate representation and I am not going overboard trying to find symmetry.) In practice, however, actions and data do not stand alone; each needs the other. Thus in practice OO and Relational are cooperating technologies.
Good golly, I don't think this discussion is anywhere near convergence. First let me address some comments made on my contributions above.
Someone wrote:
Someone else wrote:
Relational theory is not set-centric. This is a common misconception. It is based firmly on predicate logic. Relations are collections of facts; queries are derivations of new facts from existing ones; database constraints are predicates that must at all times be satisfied by the data. I haven't looked at SetsVersusTypes yet, but if it compares them and draws conclusions about relational theory, it's likely wrong.
Someone wrote:
I am generally sure that one would be forced to choose mostly one or the other for things like concurrency management, cross-referencing, data filtering, and persistence. Relational systems generally provide these out-of-the-box, while you have to build them yourself with OO, or get an OODBMS or OODBMS-like tool. Few would use both for the same application. Relational design says, "If you follow rules X, then you can do Y with an existing relational engine." You follow the constraints, and you get benefits for sticking to them. If you follow such constraints, you are generally not doing OO. I liken relational to the systems of roads we have. If you follow the traffic rules than you can generally depend on the traffic system and conventions handling intersections (concurrency), road signs, rest stops, reasonably smooth roads, etc. However, if you toss that and drive over the hills with an SUV, then you are outside of that system. Since true off-road SUVs (not the status-symbol kind that would probably break an axel) are not optimized for on-road efforts (bumpy ride and gas guzzling), you are generally forced to choose a road-car or SUV. They are not orthogonal, at least not in a given local. You generally will take one approach or the other, perhaps depending on local conditions.
Someone wrote:
Also, I think it's impossible to make such blanket statements about OO theory. Relational theory has a very compact and widely accepted core; matters of contentious debate center around a very few well-known issues, and there is still research ongoing to expand the scope or understand better all the implications of the theory, but there's little disagreement at the core. Nothing similar can be said about OO theory; there are even endless and acrimonious debates on what the central features of an 'OO system' are!
Finally, I ask what benefit there is in labelling them orthogonal. As a guideline for novice programmers, it is misleading. It implies that if you're working with a relational database system and an OO language, it will be clear what tasks are done with which, because there is no conceptual overlap. But this is patently not true. In such a system, you would have numerous chances to ask yourself which system should be used to implement some bit of processing. Which should validate data entered in a particular field? Which should ensure a database-wide lock for maintenance work? Etc. etc. Other tasks might clearly be far easier to do in one or the other.
Better to teach people what relation theory and relational systems are good for, and why the latter are often better than ad-hoc solutions. (The fact that one can even talk about ad-hoc solutions to the same problems, written in an OO language instead of addressed by a relation system, is stark evidence of non-orthogonality, i.e. overlap in capabilities!)
-- DanMuller
I have been kicking around the idea that the root philosophical difference is that in OO, behavior is the primary communication conduit between different parts of the application/system, while a RDBMS view tends to see data as the primary conduit of communication. For example, a data-centric GUI system would use meta-data to describe the interface elements and event dispatching information. (Maybe the event handling code itself is not in the meta-data, but a reference to it might be via address pointers or method/routine/action name.) The OO view would generally be to have a bunch of method calls to run and interact with the GUI. It does not make a lot of since to do both, so they are not orthogonal for the most part. -- top
OO programming languages are used to create new behavior. RDBMSs apply existing behavior to new schema and data. They both use data to communicate. In an OO program the "different parts" can emulate any machine. In an RDBMS there is only one part and it can create records, delete records, select records and modify records.
OO programming languages are used to create new behavior.
But they also tend to create data and data relations. Class hierarchies can be represented as meta-data, for example (See ObjectsAreDictionaries). And, most classes have at least some attributes. In fact, for business systems, I bet the average class has more attributes than methods (assuming we count plain set-get accessors as attributes). The bottom line is that OO systems are not pure behavior, but have data represenation facets to them also. Using the above example, I doubt you could build an OO GUI engine/API entirely devoid of data-ish aspects, and be just behavior.
Yes, you usually need to manipulate data when creating new behavior. I feel like you're ignoring my point, though. If I need to search data I use an RDBMS. If I need to create new behavior I use a programming language, often object oriented. That's the "root philosophical difference" between such divergent technologies, if there is any. One is used for fast ad-hoc queries. The other is used to create new software.
RDBMSs apply existing behavior to new schema and data.
True, but that existing behavior is often reinvented from scratch in OO systems. It is my position that if you factor out those aspects, you no longer really have OO.
I've never reinvented relational queries in an OO system,
No. It is about doing queries, not relational queries. You either do the queries (searches or filtering) using relational or using OO. This is about whether we use OO to do database-like things or use relational, NOT whether we use OO to emulate/do relational.
and I've been writing them for over 10 years. Nor have I seen anyone else reinvent them. When we want relational queries, we use RDBMSs.
They both use data to communicate. In an OO program, the "different parts" can emulate any machine. In an RDBMS, there is only one part and it can create records, delete records, select records and modify records.
The emulation issue and subset issue were addressed above already.
Then I don't think you understand those issues.
I will agree that I don't understand your presentation of them as they relate to this issue. I don't see how TuringEquivalency affects anything here. Any T.E. language/tool could be used to write a RDBMS. That is a given. We are talking about OO doing X using OO, not OO doing X by emulating relational doing X. (Did I say that right?)
I've never reinvented relational queries in an OO system,
No. It is about doing queries, not relational queries. You either do the queries (searches or filtering) using relational or using OO. This is about whether we use OO to do database-like things or use relational, NOT whether we use OO to emulate/do relational.
But I don't need relational queries for all queries. I only need them for ad-hoc queries and shared data. When I know about the queries beforehand and the data is local, I use faster and simpler alternatives.
"All" is not the issue. You are even implying that at specific spots you are choosing either relational queries or OO versions (such as looping thru an array of domain objects).
I don't understand. Who loops through arrays for queries? And "all" is the issue. Some queries benefit from relational. Others don't. Please clarify.
Nobody said "loop through arrays of queries". I don't know how you are reading this, but it appears to not be as I intended. Time for a specific example I think. See below.
You just said I was choosing between relational queries and OO versions, and then said looping "thru" an array of domain objects was an example of an OO version of a query. Most of the queries I execute within an OO program are hash table lookups, but again, I'd do the same regardless of programming paradigm. Using an OO paradigm doesn't increase the use of hash tables.
Jumping back in again to clarify something: I have not argued in any way against the use of a relational system in preference over an OO system for data manipulation, nor, I think, has anyone else. Modulo pragmatic engineering factors mentioned earlier, it's almost always a win to use a relational model to represent repeating groups of data. What I question is the moniker 'orthogonal'. It's a strong metaphor; orthogonal axes in a coordinate system are independent of one another, and measures taken along a complete set of orthogonal axes are a completely non-redundant way of defining a point in a system. I think the person proposing to label 'relational' and 'object-oriented' is watering the term down -- something which happens all to often in our field, to the point where such metaphorical terms eventually become meaningless.
BTW, I have seen OO systems wherein inner and outer joins were done 'by hand'. In this case at least, it was not really justifiable, but there's not particular difficulty to implementing such things in a single-user application, and gross granularity locking for multi-user applications is also not terribly hard.
One common reason for not using an RDBMS in conjunction with an OO language is probably the questionable quality of the interfaces typically available between the systems, and the attendant difficulty of mastering and using such APIs . It baffles me that no mainstream general-purpose programming languages have included language or standard library support for such interactions. -- DanMuller
They are orthogonal from my perspective because an application can use both to varying degrees, and there is no constraint on the relationship between them. An application can use no OO programming, a lot of OO programming or some measure along that axis. It can also use no relational queries, a lot of relational queries or some measure along that axis. Therefore one way to describe an application is as an intersection of these two orthogonal axes. If they weren't orthogonal then there would be a function that described how relational an application was in terms of how much OO programming it used, and vice versa. I can prove that such a function does not exist by keeping the dependence on relational queries constant and varying the use of object oriented programming versus other styles of programming. -- EricHodges
Your example chooses to measure an application's location in relational/OO space by some measure of how much each is applied. You defined the axes as orthogonal a priori; that's how you defined your space. That may be a useful thing to do in some context, but it begs the question of whether the two technologies (or theories, or methods -- nobody on this page has yet clarified which) are somehow intrinsically orthogonal. Besides, the function you deny exists will exist if 'varying the use of object oriented programming' involves doing something in the OO language that was previously done using the RDBMS, or vice versa, keeping the overall functionality of the program constant.
I've usually heard the term 'orthogonal' applied during design work, with respect to functional areas of the system. (Cf. JimCoplien's book MultiParadigmDesign.) For instance, during design it may become apparent that an application requires a user interface, and a concurrent database, and an email notification system. These could be described as relatively orthogonal, i.e. each of these areas can be separated from the other to a great degree architecturally, they typically have different, idiomatic approaches to implementing them, and we are relatively free to choose different technologies to implement them (provided that we can bring them together at their interfaces, which we usually can). Experts in these domains will in fact tend to choose different technologies: a third-party UI library, an RDBMS, etc. 'Orthogonal' in this sense is meant to indicate that implementation choices in each area can be made with a degree of independence
When talking about small-scale design issues, I often use the term 'orthogonal' to describe two pieces of functionality that don't (need to) interact. Each can be designed separately, or have separate APIs, or separate representations. Again, they're orthogonal with respect to choices that are being made; the choices that apply to each are reasonably independent of the choices made for the other.
Labeling OO and relational technologies as 'orthogonal' might make sense in some context, but as a general unqualified statement, it simply doesn't make sense. For the task of representing and working with data, they seem more like alternatives, and can sometimes be used in a complementary fashion. Depending on your application, one alternative might seem clearly better than another, but that doesn't make them 'orthogonal', at least the way the word is usually used in our field. -- DanMuller
I can write a program using an OO programming language. It can use an RDBMS to persist, query and share data. I can then write a program with identical behavior in a procedural or functional language. It will send the same SQL statements to the RDBMS as the one written with an OO programming language. It doesn't matter how I map objects to tuples. I don't have to use objects at all. The style of programming language and programming techniques used to create the program are orthogonal to the use of a relational database. That isn't an a priori definition. It can be proven. -- EricHodges
Yes, now I think we agree. The choice of implementation for the application and the choice of whether or not to use an RDBMS, or which RDBMS is to use, are fairly orthogonal. The technologies themselves are not; they overlap in capabilities, and could overlap considerably more in the future if RDBMS developers incorporate objects as values in relational domains, for instance. -- DanMuller
They overlap in capabilities because any Turing complete language can implement all or part of an RDBMS. That's any Turing complete language, not just OO languages. The knob that controls OO'ness and the knob that controls relationalness aren't geared against each other. -- EricHodges
Given your assumptions, that may be true, but so what? I could as easily say that the "knob that controls use of string expressions and the knob that controls the use of floating point expressions aren't geared against each other". What have I learned from that? And under what circumstances is it true?
What you've learned is that the use of string expressions and the use of floating point expressions are orthogonal. This page grew out of the position that developer must decide how OO vs how relational they make their software. I maintain that there is no such decision. We can (and do) make software as OO and relational as we need because relational databases are a small part of software development. Relational databases are tools we use when we need them. They are not general purpose programming languages. -- EricHodges
I agree with most of what you say. I disagree with the practice of overusing metaphors such as 'orthogonal' to this extent, and I don't agree that choosing between alternate technologies to implement the same functionality makes the choice of how much of each to use independent of each other.
I don't understand what metaphors have to do with this. Any quality can be assigned a position on an axis. If there is no function to describe the relationship between two qualities then the axes are orthogonal. -- EricHodges
'Orthogonal' is a concept from geometry; it is used metaphorically in computer science. It is not as simple as "no function describing a relationship"; orthogonality depends critically on the context. The way you are using the term is akin to saying "the axes of my coordinate system, which I define thus, are orthogonal". This is a trivial thing to say; this is a property of most coordinate systems. The metaphor is used loosely in computer science to mean that two things can be varied independently of one another without affecting the functionality of a program. Your examples make a different assumption: that you can add or remove functionality using either technology, and then measure how much of each technology you're using. That seems a trivailly true; you can change a program in a thousand ways, and measure a thousand different things, but if you stipulate no constraints on this process, there's not much worth measuring about it. Perhaps it would help to think of it in terms of a scientific experiment; if you don't control or measure all the variables, you can't draw any conclusions.
OTOH, if the functionality is constrained to remain constant, then you can choose to implement the functionality using one technology or another; in that case "how much" of a technology that you're using obviously affects the other, because you'll implement each behavior one way or the other, but not both ways. They are not independent, given this reasonable and much more interesting assumption.
Object oriented programming languages and relational databases are not on the same technological axis. OOPLs can be used to imitate any machine. RDBMSs are one machine. Functionality can remain constant. The use of RDBMSs can remain constant. The use of OOPLs can be varied by using other kinds of programming languages and techniques. Therefore OO and relational are orthogonal. -- EricHodges
Define "technological axis". What do your axes measure? How many axes do you have? Please be specific.
Technological axis: a continuum of values describing the amount of use of a technology. In my example, the OO axis measures the use of object oriented programming techniques to write software. The relational axis could measure either the use of relational queries or RDBMSs to write software. Any program can be assigned a value for each axis. Individual analysts may disagree about where to place a program along each axis, but I hope we can agree that there are programs that use no OO techniques and others that use many OO techniques, describing endpoints of the OO axis. Likewise there are programs that do not use RDBMSs and others that use them heavily, describing endpoints of the relational axis. I can move any given program along either of those axes without affecting its position on the other and without changing its functionality (although there are certainly optimal performance maxima). I can replace OO techniques with other styles of programming. I can replace RDBMSs with other kinds of databases. That's what I mean when I say the two are orthogonal. -- EricHodges
In your most recent example, what happens to the measures on your other 'technological axes' if you vary the use of an RDBMS, while keeping program functionality constant?
If we use more features of the RDBMS or use it to share more data that doesn't increase or decrease our use of object oriented programming languages or techniques. The program can be as object oriented, procedural, functional, aspect oriented, etc., as we like. If we move behavior to the RDBMS that will remove the same behavior from the program regardless of which programming style(s) we used. -- EricHodges
OK, I assume that you don't write code just for the sake of writing code, and that for a given technology, we're using it reasonably optimally to achieve the functional goals of the program. Under those assumptions, how can you get "if we use more features of the RDBMS or use it to share more data that doesn't increase or decrease our use of object oriented programming languages or techniques"? The first part (using more features) sounds like adding code (or db constraints, or whatever) for the sake of doing it, the latter (share more data) sounds like a change in functionality (or the addition of data for no reason).
The use of OO techniques doesn't depend on how little or how much data we share through the RDBMS. The program's behavior can be expressed with functional techniques, OO techniques, procedural techniques, etc., or mixtures of them. We can share data with a messaging system. We can share data with a navigational database. If we decide to share more of the data with an RDBMS it doesn't change the "OO'ness" of the program any more than deciding to use more messaging. -- EricHodges
"If we move behavior to the RDBMS that will remove the same behavior from the program regardless of which programming style(s) we used." -- Exactly my point. Hence they're not independent variables.
It removes behavior from the program, but it doesn't make the program less OO, any more than it makes the program less functional, procedural, etc. The size of the source code doesn't affect its position along the OO axis. Imagine a large program that is 50% OO. Remove some of its behavior. It is still 50% OO, just smaller. -- EricHodges
Then you'll have to explain what you're measuring along your axes, because this makes no sense to me at all in the context under discussion. The last time I asked for clarification, you said "Technological axis: a continuum of values describing the amount of use of a technology". So how do you determine "amount of use"? Does the mere presence of a technology in a program give it an equal share to all the others, by your measurement scheme? If so, then all this talk of measurement along axes seems rather nonsensical. You're not measuring "amount of use", but merely tallying how many technologies you're using.
I'm measuring how "object oriented" a program is. A program can be described as more or less object oriented than another program based on the percentage of code that uses OO techniques. It isn't just the presence of a technology that is measured on this axis, but the degree to which that technology is used. Sorry if I'm not being clear. I'm trying my best. It seems obvious to me. Imagine three programs that define the axis:
-- EricHodges
But that means that you're measuring the program separately from the database. You're not measuring the system as a whole. That's not a valid way of looking at it, because the functionality is provided by the system as a whole, not a piece of it. If you look at the functionality provided by the program, you've reduced it -- because you've transferred responsibility for that functionality (e.g. constraint checking) to the RDBMS.
As I've said, reducing the functionality of the program doesn't make it less OO. I'm measuring the program separately from the database. I'm a programmer.
If you're going to treat the program (written in whatever language) a priori as distinct from the RDBMS, then of course you can say that they're orthogonal -- you've defined your system of measurements such that they're independent. If you can't see that, then there's not much point in continuing this discussion.
I'm going to treat the program as distinct from the RDBMS (unless the program is an RDBMS) just as I treat the program as distinct from the messaging system, the OS, authentication, network protocols, etc. Why shouldn't I? -- EricHodges
Look, the statement 'OO and relational technologies are orthogonal' relates OO programming technology to relational data handling technology, right? As such it treats with both technologies. For that statement to have any meaning, it has to be relative to a system or to functions that can use either or both. So that's what your measurements have to apply to.
If you only measure the 'amount of OO technology' relative to some context that cannot use relational technology (in this example 'the program', which you define as distinct from the RDBMS), and measure the 'amount of relational technology' relative to some distinct context that cannot use OO technology (in this example, 'the RDBMS', which you define as distinct from the program), then it's not very useful to compare these two measurements, is it? And since 'orthogonal' is about the relativity of these two measurements, your explanation doesn't support the statement. At all. Not one bit.
A little earlier, you described three axes. (One of which was a combination of two others, thus they were not all mutually orthogonal in any sense, but leave that aside.) You didn't include an axis for relational technology. Then you take measurements in this system, and draw a conclusion about the relationship of these measurement to some other system (RDBMS) that you've defined as completely separate. That's truly meaningless.
It's kind of like saying that you can use more or less cream in your coffee, and it doesn't affect your shoe size, so shoe size and coffee creaminess are therefore orthogonal. At that point, they're just completely unrelated; saying they're orthogonal is so meaningless that it's ridiculous to even make the statement.
I don't know if I can find a way to describe it that will make sense to you, but the logic error seems quite fundamental.
And by the way, the statement "I'm a programmer" doesn't absolve you from being concerned with the database system where I work. :-)
I don't measure the amount of OO technology relative to some context that can't use relational technology. A program, be it OO, procedural, functional, etc. can use relational technology. It's use of relational technology is relative, as is it's use of OO technology. The two uses are as unrelated as shoe size and cream content. Therefore they are orthogonal. I've never argued that programmers should be absolved from being concerned with the database system. I've argued that the use of relational technologies is independent of the use of OO technologies. -- EricHodges
Regarding the last bit, that was a joke relative to your statement: "I'm measuring the program separately from the database. I'm a programmer.".
Regarding the rest of it, forget it. If you can put statements like this together in one paragraph and call it reasoning, then reasonable discussion is impossible:
* "A program, be it OO, procedural, functional, etc. can use relational technology." (After previously declaring the RDBMS separate from the program and omitting to measure use of relational technology in the program.) * "(The program's) use of relational technology is relative." (Relative to what?) * "The two uses are as unrelated as shoe size and cream content. Therefore they are orthogonal." (The first statement is exactly what needs to be supported. Restating it without support is not helpful.)Perhaps you're simply baiting me, or not making an honest effort to question your assertion. In any case, adieu. -- DanMuller
I promise I'm not baiting you and I'm making an honest effort to explain my view. The RDBMS is as separate from the program as the OS or a messaging server. The program can use relational technology, just as it uses any other technology. Any given program's use of relational technology is relative to other programs. Some use a lot, some use none. I believe I've demonstrated that the use of OO techniques is unrelated to the use of relational technology.
I continue to argue my case because I believe many OO programmers have an irrational and counter productive desire to enmesh the two technologies. I used to be one of those. I think we'd all be better off if we treat RDBMSs as what they are: great tools for sharing data that enable fast ad hoc queries. Our OO programs can speak their language when necessary. It won't infect the rest of our code. It won't make it less OO. Keep the bridge between them as lightweight and flexible as possible. Treat them like any other tool.
Instead I think it is you who haven't explained your view. Why do you think that OO programming techniques are not orthogonal to the use of relational technology? Let's say we have an OO program that uses flat files. We migrate from flat files to an RDBMS. How has the program become less of an OO program?
"Any given program's use of relational technology is relative to other programs." -- But we're not measuring relative to other programs. Your thinking, or at least your writing, is vague to the point of being merely a series of impressions.
I am measuring relative to other programs. I'm assigning values of "relationalness", a position along an imaginary axis. What's vague about that?
"I believe I've demonstrated that the use of OO techniques is unrelated to the use of relational technology." -- Because of the aforementioned vagueness, you have not.
"Let's say we have an OO program that uses flat files. We migrate from flat files to an RDBMS." Can we agree that the program is written in an OO language, and not obscure the topic by bringing in the irrelevant fact that you could of course rewrite it in FORTRAN or assembler if we chose? We're comparing OO versus relational technology, yes?
I've written OO code in procedural languages (and procedural code in OO languages.) The language is less important than the coding techniques when determining the "OO'ness" of a program. The fact that we could rewrite an OO program as a procedural or functional program is relevant to this topic, so I it seems we can't agree.
If you use flat files, you will need code to ensure data integrity, and code to extract views of the data (queries) needed at any given point in the program. As soon as you move the data to an RDBMS, you don't need this code anymore. The functionality is being provided by the RDBMS at that point. (If you don't use any of these features of the RDBMS, i.e. you use it only and strictly as a replacement for flat files and continue to everything else related to data management using OO code, then you most likely should not be using the RDBMS - you're introducing a lot of overhead for almost no benefit.)
Using flat files doesn't mean I need code to ensure data integrity or code to extract views of the data. I can use flat files to load a list of names, as in the Menu example later in this page. The need for data integrity and view extraction comes from external requirements, not internal use of flat files. I didn't say using the RDBMS was more wise than using the flat files; I'm proposing a thought experiment to show that changing the use of relational technology doesn't change the use of OO techniques. This isn't about what we should do but what we can do. If we can replace flat files (or messaging, or whatever) with an RDBMS and keep the program just as object oriented as it ever was, the two technologies are orthogonal.
"How has the program become less of an OO program?" -- That depends on how you want to measure this, and whether you really mean "program", not "system". Clearly, in the system that implements the functionality of the original program, you now have less OO code, because our use of RDBMS features has replaced some OO code. So if your criteria is amount of OO code versus total functional system, then the system is definitely "less OO" at this point.
I explained above how I measure it. Making an OO program smaller doesn't make it less OO any more than making a procedural program smaller makes it less procedural. My criteria is not the amount of OO code but the proportion of it.
"I continue to argue my case because I believe many OO programmers have an irrational and counter productive desire to enmesh the two technologies." I'm not sure what you mean by 'enmesh' here, but certainly I agree with the goal of encouraging programmers to consider using relational technology when they have to manage data. But I think that calling the technologies "orthogonal" is wrong (perhaps "complementary" would be more accurate), and doesn't serve your goal well.
By "enmesh" I mean entangle. I agree that they are complementary. I also see them as orthogonal. I don't see any contradiction between those two terms (in fact I see them as orthogonal :-)). Why do you think it is "wrong" to call them that? (I notice you didn't say I was wrong, or that my belief was wrong, but that the act of calling them orthogonal was wrong. Interesting.) What bad can come of calling them orthogonal?
"I think we'd all be better off if we treat RDBMSs as what they are: great tools for sharing data that enable fast ad hoc queries." -- By itself, this sells relational technology short. Just as important is the ability of relational technologies to give you succinct ways of stating and enforcing constraints on data, to help ensure that the data continues to mean what it's supposed to mean.
But there are many ways to do that. Relational is just one. Where it shines is fast ad hoc queries. When performance matters and queries are known up front, a program using a navigational database can enforce constraints just as well but faster and cheaper.
"Instead I think it is you who haven't explained your view." -- My view is that 'orthogonal' is not the right term to relate use of OO versus use of relational technology. They are alternatives for implementing certain kinds of functionality.
Ah, I think I see the source of our disagreement. I don't see OO as an alternative to relational for implementing certain kinds of functionality. I see OO as an alternative to procedural, functional, etc, for implementing certain kinds of functionality. I can use OO (or any kind of programming techniques) to implement relational, but I'm still using relational. It isn't an either/or issue.
If you want to measure OO'ness the entire system and not just a program, does it matter what technology was used to write the RDBMS? Is a system that uses an RDBMS written with primarily OO techniques more OO than a system that uses an RDBMS written with primarily procedural techniques?
I find this discussion difficult to continue, because you argue in vague terms, choose to see some distinctions and choose to ignore or deny others that are exactly parallel, and often seem to contradict yourself. Thus the conversation sort of meanders about. Some examples:
"The fact that we could rewrite an OO program as a procedural or functional program is relevant to this topic..." -- So some functionality could be written using procedural techniques, or using functional techniques. And some functionality can be expressed in OO techniques, or in relational techniques -- but the latter fact you choose to ignore, or consider somehow qualitatively different from the other. Explain, please.
There's a fundamental difference between programming paradigms or techniques and relational math. Relational math describes how to organize and manipulate data. Programming paradigms describe how to organize and manipulate behavior. I can't rewrite an OO program as a relational program because there's no such thing as a relational program. Neither can I rewrite an OO program as a set theory or ring theory program. They are apples and oranges.
"I am measuring relative to other programs. I'm assigning values of "relationalness", a position along an imaginary axis. What's vague about that?" -- Measuring what? Since you've never once answered that, it's obviously vague.
I'm measuring "relationalness" or "OOness" relative to other programs. You just quoted me saying that. Are you reading what I'm writing?
"I explained above how I measure it. Making an OO program smaller doesn't make it less OO any more than making a procedural program smaller makes it less procedural. My criteria is not the amount of OO code but the proportion of it." -- No, you haven't explained it, at least not in any terms that could be considered at all concrete. In fact, this sentences ia a good example: "... not the amount of OO code but the proportion of it." Proportion of what to what? I can't know if your thought processes are fuzzy, but your writing certainly is!
Proportion of OO code to any other code. A program can contain OO code, procedural code, functional code, etc. It's position along the OO axis indicates the proportion of OO code to anything else. I thought that was obvious from what I said.
"What bad can come of calling them orthogonal?" -- That should be obvious by now. Since you imply that you want to teach something about the relationship between OO and relational (technologies? techniques? tools? still unclear), it behooves you to teach clearly and not misleadingly. The aphorism "relational and OO are orthogonal" is potentially misleading, if for no other reason than that there is obvious disagreement on exactly what 'orthogonal' means or implies in the context of software design - either because the term as used is too vague, or the context (what is measured, or what is meant by OO and relational) is unknown or ill-defined. You'll notice that I'm not the only one questioning the use of the term here. I'm not necessarily arguing that the term cannot apply, but I am still waiting for some sort of firm description of a context in which it does apply.
What I mean is simple. You can change the OOness of code without changing the relationalness, and vice versa. The two values are orthogonal. Relational is not a way to program. It's a way to organize data.
"Where it [relational] shines is fast ad hoc queries." -- Again, you sell relational short, IMO. Ad hoc queries are a nice feature of relational systems. But where relational really shines (with even a halfway decent implementation) is the ability to succinctly describe, and thus simplify the enforcement of, database constraints.
How is that a quality of relational more than other database strategies?
"When performance matters and queries are known up front, a program using a navigational database can enforce constraints just as well but faster and cheaper." - First, if you're talking about relational theory, or the relational data model, you can't really say anything about performance, because that is mainly influenced by implementation. It is generally much harder to express (and thus implement and maintain) database constraints in a navigational database approach. I'm having to cover a lot of ground here, because you've never clarified whether you're talking about theory or technology.
In this sentence I'm talking about RDBMSs I've worked with.
"If you want to measure OO'ness the entire system and not just a program, does it matter what technology was used to write the RDBMS?" No, it does not matter -- unless you're writing the functionality yourself. Many OO compilers and their run-time libraries are written in procedural languages -- does that mean a program written with such an OO language is really procedural? Again it comes down to what you want to measure, and what your point of view is. You are very unclear about whether you want to examine designs or programs or architectures (or perhaps 'general attitude of the programmer'). Of course you can 'roll your own' relational behavior in any language you choose. If you are looking at it from a high-level view of subsystem functionality, the language is irrelevant, the relational features are there. If you're looking at it from the point of view of hands-on programming, there's a big difference between using an existing relational tool and writing your own.
So the OO'ness of an entire system is only a measure of the OO'ness of the code currently being written and not the code being exercised by the entire system? Then let's stick to measuring the OO'ness of a program and ignore the entire system. I can use OO (or any other paradigm) to write code to organize data according to relational theory. I can use OO (or any other paradigm) to communicate with a system that organizes data according to relational theory. OO and relational are as orthogonal as procedural and messaging, or functional and ring theory.
But don't let that lead you to believe that I would agree with the 'orthogonal' moniker at a higher level of abstraction. Just as I can choose the language (or other tools) when coding, I can choose the models that I use for designing and architecting a system. And relational and OO overlap there, too. At this level, the relational model is (again) usually preferable for the data-processing portions of a system (because it's better defined, more rigorous, and ultimately, I would claim, more flexible), but to say that they're orthogonal at this level again overstates things, implying that there's one unequivocal choice of model to use for any given aspect of the system being modelled. Although there may be a clearly preferable choice in some cases, it just ain't true that there is no choice -- and that's what 'orthogonal' implies to me.
Why does orthogonal imply lack of choice? How do you infer that? To me, it means the choices are independent. Using one doesn't affect using the other. The relational model is just one of many data models I can use when working in an OO paradigm. The OO paradigm is just one of many paradigms I can use when working with a relational model.
"There's a fundamental difference between programming paradigms or techniques and relational math." -- I think that's open to debate. If your programming paradigm includes methods for organizing data (which OO patently does), then there's overlap. If your programming paradigm includes methods of combining data to form new data, then there's overlap. If by 'fundamental difference' you mean there's no domain overlap, then you're wrong in at least some cases.
OO includes methods for organizing data? What are they? I haven't seen them. OO describes how to organize code, but data can be organized any way you want. I can organize data in tables, in trees, in lists, in sets, in bags, in maps, etc. in an OO program. OO doesn't impose any particular way of organizing data. Instead, it enables any possible organization.
"I can't rewrite an OO program as a relational program because there's no such thing as a relational program." -- This is a splitting of hairs. What would you call the concrete data definitions, queries, and constraint definitions of a DBMS, be they in SQL or some other language? Don't these bear the same relationship to the relational paradigm that the class and procedure definitions that make up an OO program do to the OO paradigm? And there are undoubtedly functions of a system that can be performed by either medium.
Any relational function performed by an RDBMS can also be performed by an OO program (and already is if the RDBMS is an OO program). That doesn't mean I can write a "relational program". Data definitions, queries and constraints are not Turing complete.
"I'm measuring "relationalness" or "OOness" relative to other programs. You just quoted me saying that." -- But how do you measure 'OOness' or 'relationalness'? Every time you try to describe measuring something, you mention code. But when you talk about relationships to a relational something, you retreat to these vague unmeasurable things.
We can use different criteria for measuring them. That doesn't matter. I assert that they can be measured, albeit subjectively, and their values are not constrained by a function. I've said this all before. Look at 1000 programs. If one doesn't use any relational math, assign it a relational value of zero. If it's all relational math assign it a relational value of 100. Do the same for it's use of object oriented programming techniques. The two values are orthogonal. They are distinct, unrelated axes. We can find programs that occupy any point in this imaginary 2D space.
"Proportion of OO code to any other code. A program can contain OO code, procedural code, functional code, etc. It's position along the OO axis indicates the proportion of OO code to anything else." -- Ah, now we're back to code.
We never left code.
"Relational is not a way to program. It's a way to organize data." -- And it's also a way to describe how to combine that data in new ways, and a way to declare relationships between data. And a relational database system (a concrete implementation of relational theory) provides ways to actually turn these descriptions into new data structures, and ways to enforce these declared relationships, which of course are things that you can also do with code, whether OO, functional, or something else.
Describing how to combine data in new ways and declaring relationships between data are aspects of organizing data. They use a limited set of existing behaviors and don't create any new ones. They are not a way to program.
"How is that [the description of data constraints] a quality of relational more than other database strategies?" -- Irrelevant to the discussion, but it's an important part of the relational model as it's generally understood these days. I don't know what you mean by 'strategies' in your question. What other rigorous data models are there? I'd be somewhat interested in pointers to any that include this feature. No doubt there are non-relational DBMS's that have this capability, too.
You said:
"But where relational really shines ... is the ability to succinctly describe, and thus simplify the enforcement of, database constraints."
I have succinctly described constraints for "navigational" b-tree databases. They were just as simple to enforce. I don't agree that this distinguished relational databases from other databases.
"In this sentence I'm talking about RDBMSs I've worked with." -- Not about general 'relationalness', then. That's part of the reason this discussion is difficult -- it bounces blithely back and forth between '-nesses' and their implementations.
It doesn't have to. We can keep it about "-nesses" if you'd like.
"So the OO'ness of an entire system is only a measure of the OO'ness of the code currently being written and not the code being exercised by the entire system?" -- Well, obviously your aphorism is intended to enlighten someone engaged in a software development activity. So I take the point of view of this hypothetical person when evaluating the advice that 'OO and relational are orthogonal'. That person will, presumably, be either choosing how to model something, or how to implement something. (More on these two alternatives below.) I think it's reasonable to assume that this person will not be implementing or maintaining the RDBMS that they might use.
Most programmers don't maintain their own RDBMS code. Some do, though.
"Then let's stick to measuring the OO'ness of a program and ignore the entire system." -- The question is: Who is your aphorism targeted at? If your audience is a programmer who is writing a program to interface with a database that he has no control over, then it makes sense to look at just the program. If it's targeted at someone, like a system designer, who actually has a choice of where to put functionality -- in the program or the database -- then of course it makes sense to look at the system. If your intention is the former, then the comparison of relational to OO seems rather pointless, since your audience has no say over the use of relational technology at all.
My target is all of the above. Use RDBMSs where it makes sense. Use relational theory where it makes sense, even outside an RDBMS. Neither of those decisions will make your code less OO. Don't imagine that they are on the same axis.
Generally, I think the problem might be that you're comparing relational models to OO programs. These are indeed apples and oranges, and you probably can say that they're orthogonal. But if you compare OO models to relational models, there's overlap in domain. And if you compare OO code to a relational database implementation, there's overlap in domain. This means that when you need to express a concept either at the higher level (when modelling a system) or the lower level (when implementing it), you can choose one or the other. But unless you're duplicating portions of your model or implementation, you're trading one off for the other -- more of one, less of the other, and vice versa. They are therefore not orthogonal.
We agree that the more RDBMS code we use, the less client code we may need. But that doesn't make any of the code less object oriented.
"Why does orthogonal imply lack of choice?" -- Because 'choice' implies 'alternative'. You choose one, or the other. (Or the third or the fourth... doesn't have to be just two.) That's not independence, which is what's implied by orthogonality.
It isn't an either or choice. It's a this and that choice. Pick the right ways to organize and share data. Pick the right ways to organize code.
Uncle. -- DanMuller
When I represent 2 technologies as being "orthogonal" to each other, I'm often trying to communicate that a change to one does not impact the other.
Without an ObjectRelational? mapping layer, it's been my experience that OO and RDMSs are rarely completely orthogonal.
This might sound a bit naive.... but can't you like, implement the data base as an object with methods that are pretty much analogous to the queries.... or something......
If the database itself was an object, then it really would be orthogonal to the rest of the program......
To me.. the word "orthogonal" brings to mind the two words "linear independence" and "Pythagoras".
The word "orthogonal" doesn't immediately jump to mind when I think of OO..... but if you think about it, objects with well-defined interfaces ARE orthogonal, in some sense of the word, aren't they? That's the whole point, isn't it?
By some weird twist of logic, increasing the number of dimensions actually decreases the incomprehensibility...... or something......
So, how does Pythagoras' theorem apply to objects?
Links
They are not orthogonal because relational and OO have different ways to manage the links between things/objects. Either we violate OnceAndOnlyOnce by duplicating the link info, or we designate either relational rules for managing links or OO rules. We cannot have both without duplication. I see no way out. (It may be possible to have neither OO nor relational posses link info, such as using an array or function calls.) Related: CantEncapsulateLinks
If they have different ways of managing links, doesn't that make them orthogonal?
A given link cannot be stored on both an OO system and a relational system without duplication.
The text is getting too long, so I am splitting this, and continuing it on AreOoAndRelationalOrthogonalDiscussionTwo
See Also: ObjectRelationalPsychologicalMismatch, WhenToUseWhatParadigm, TablesAndObjectsAreTooDifferent, RelationalWithSideEffects
EditText of this page
(last edited February 25, 2012)
or FindPage with title or text search