Some RelationalWeenies say that Relational is better that ObjectOriented because ObjectOriented 
sees things only form a particular hierarchical perspective, and Relational sees things from an AbsoluteRelationalPointOfView
but I think that is precisely the problem with Relational, when I want to build I system may want to create a model that
works from any perspective, but the truth is, that in this imperfect world, i will only be able to build a model 
from a particular perspective therefore RelationalIsTooAbsolute, and  ObjectOriented brings the necessary particular point of view.
* Consider also ModularProgramming in addition to just ObjectOriented.  I find modules map my mind at times, as opposed to just pure relational programming,  if it even exists. 
* ''Also, consider studying ComputerScience.  Please.''
* I agree there are some situations where RDBMS are indeed "too boxy" (to barrow a phrase from below) when a kind of organic approach is needed. My solution is DynamicRelational, not OOP, however. --top
* ''How do you apply DynamicRelational as a solution?  It essentially doesn't exist except as text on the DynamicRelational page.'' -- DV
** True. But if it did exist, would it solve the problems you find with existing RDBMS? Even with their static nature, RDBMS still usually are superior to OOP for "complex structures" in my opinion. An AttributeTable can be used for some dynamism. Perhaps we need to study a scenario.
*** I think we create AttributeTable just because there is no good standard to deal with the metadata that describes the structure of a databases (if you want to dynamically query for the structure of a database, and dynamically alter it, on runtime, and do it in portable way, you are in for a lot of trouble, so you start creating stuff like an AttributeTable, and basically reinvent the database inside the database)
*** [I think it's because amateur database developers find creating tables scary, and try to avoid doing it whenever possible.  (Tongue {somewhat} in cheek...)]
**** (Moved disagreement to FearOfAddingTables)
*** ''In my opinion, the oddity of an AttributeTable is due to the lack of DynamicRelational implementations, not a flaw in relational. It would be like having to use "staticky" Java or Eiffel when SmallTalk or Python would be more appropriate. I AGREE with your complaint about existing relational tools not being sufficient for some needs. --top''

Relational is Absolute, but things, in this world are Relative.

''I don't know what you mean by "Relational is Absolute".''

I think Relational is Absoulte because it gives too much freedom to the developer, I believe OOP makes it easier to create a kind of language that describes the solution
you are trying to build, with relational you have too much freedom,yes, it is nice that you can make a join with any field(s) you like in any way you like, but in my experience that makes a lot of programmers create databases without caring too much about the initial datamodel... maybe the problem is not that RelationalIsTooAbsolute, but that RelationalIsTooPowerful, since you can join anything with anything, and you can pretty much take a mess of a database and get a dysfunctional model that can be twisted until it seems to be a functional thing(but a nightmare to maintain). OOP and Hierarchical might be more rigid, but they have the advantage that they create a kind of structure that forces you to be more careful when designing you model. 

Relational makes it just too easy to create a thing that looks so distant for you DomainModel and that can be reshaped so much, that a lot of times end up being really hard to map to the real world that it supposedly represents. In OOP you might be somewhat forced to fetch a "complete" shopping cart item object to deal with them, but that also makes it easier to understand that the code handles shopping cart items if you read it six months later and you weren't the original programmer, in relational you can just "load a bunch of integers that are the primary keys of the car items" and deal with them as if they were a meaningless list of numbers, and that just makes it really harder to re-read the code six months later.

I feel that Relational just make it too easy to deal with stuff as if you were dealing with putty, that is why if feel it is to Absolute, it just sees everything from a kind of universal point of view and makes it too easy to forget about its original structure, its structure as if it were seen from a particular perspective... mmmmm... I am starting to think that maybe I should have said RelationalAbstractsYouAwayFromTheDomainModel

''The RelationalModel and ObjectOriented programming are complementary, not contradictory.   ObjectOriented programming provides an effective means of defining types and structuring code.  Implementing the RelationalModel within an ObjectOriented environment provides an expressive, composable means for dynamically manipulating collections of object instances, and can be a powerful enhancement to the collection and container classes that most ObjectOriented systems provide by default.  This has nothing to do with either model imposing a "particular point of view," any more than (say) numeric algebra imposes a particular "point of view" on calculations.  The RelationalModel and ObjectOriented programming are tools to be leveraged, rather than viewpoints to be embraced or rejected.'' 

-- DaveVoorhis


* Regarding "types", I prefer weak a no typing, so selling OO with/as types hits deaf ears here [insert related type-fight topics here]. I do not find typing very practical, except maybe for certain domains where compile-timing "proofing" is more important than human productivity, such as medical apps.
** weak no typing? Do you prefer the same in math too? DoesMathRequireTypes
* As far as "complimentary", see AreOoAndRelationalOrthogonalDiscussion.

--top

''I meant (and wrote) complementary, '''not''' complimentary.  As for, "I do not find typing very practical," that made me laugh out loud.  See my comment above re "... consider studying ComputerScience."  Please.  Do.'' -- DaveVoorhis

English needs a refactoring. As far as ComputerScience, has it objectively proved that "types are better"? I don't think so. While ComputerScience has proven very useful for performance-related issues, it has utterly failed to objectively select among competing paradigms and design techniques (unless you decide to focus on very narrow criteria). --top

[Well, who uses untyped languages? Machine code? Computer science has empirically (statistically) proven that types are better, since the popular languages in use today have type systems! Although the languages of today do not have as rich or complete type systems as we would like, they are still type systems.  Are you seriously advocating something like machine code or something more untyped? Even the C language has a typedef system, and even languages like PHP have types (although they try to hide this fact and brush it under the rug, which is a bizarre thing indeed.. I don't know why they do that. Maybe TypesAreTooHard or EducationIsFailing. I don't even think TypesAreTooHard because even kindergarten students can distinguish between different TYPES of FRUIT in the fruit bowl. You don't even need to be a programmer to understand the advantages of different TYPES.). ]

Statisically proven better? Bullshit! Link it.

----

At times I find the relational model too "boxy". For example: try making this C2 wiki markup relational instead of markup. Each WikiCase link, period, dot, quote, etc could be potentially modeled into the database. Orphaned link problem could be solved, when someone deletes a page. However, it can be hard to design human oriented systems such as this wiki markup, into perfectly boxy databases. Article oriented discussions seem to be less boxy and square, and more free form. Although, I've had thoughts about a relational model to solve the WikiCase link orphan problem. 

* See DynamicRelational comments above. --top

''Too...  Boxy?  Huh?  Many Wikis are implemented using SQL databases, including MediaWiki, the software that runs WikiPedia.'' -- DV

The orphaned links are not fixed.. that is just storing each page in a cell. I have audited the Wikipedia source code and it is horrible. If you store each page in a cell you are essentially creating a spreadsheet. The wikipedia database is not a real database.. it uses spreadsheet style MYIsam tables. True relational design.. is harder to implement.. so that orphaned links in the actual text content, are relational (maybe the markup is even converted to some relvar (table)). Designing each page in a relational way is tough. FYI I run a wikipedia database of my own and I am not impressed with their parsing code either.. bunch of spaghetti code. 

''Admittedly, the MediaWiki source is anything but a model of perfection.  However, modeling a Wiki in a relational database is trivial.  Modeling it in a SQL database is only slightly less trivial.'' -- DV
* Modeling the wiki pages is not trivial.. only modeling the actual articles as "files in a database" is trivial. Each article is more like an XML file or a markup file,  but each page is not relational... hence there is no pure wiki that is truly relational, ever. This is what some people miss.. and just don't understand. A wiki article is ''data'' and is being stored in ''non relational'' form.. but the ''files'' or the articles are relational partly in that the entire wiki is ''organized''. But the wiki articles themselves are never trivially relational. For example if you can edit different sections of a wiki article, like those little "section edit" buttons on different parts of the page: how can it be mapped to a DB. You'd have DB tables inside DB tables. That's why XML and such markup languages are used, to avoid the relational model.  And then you have the dbdebunk folks using microsoft word to organize and build their website - each Word file could be stored in a database, but is the word file data relational? ''hypocrisy'' and ''irony''. Very few people have the guts and critical eye to see large flaws in the entire ''pure relational'' idea. We can accept it as a good guide.. and it is, kind of.. except that the relational model is too ''boxy'' for many situations. A very smart fellow at microsoft has exactly the same thoughts as mine and he says it on a video on Channel Nine.. I forget his name. I think it was when they were discussing LINQ (MicrosoftLinq) with Anders H. and another fellow made the comment who was with Anders in the video.. I'll have to find the video and insert_link_here.
* ''Because they didn't try DynamicRelational. As far as Wiki, I always thought that a RDBMS would be good for a ParagraphWiki.''


Some RDBMS have automatic orphan removal (I cannot think of the proper name for it right now), and one can create triggers if it does not. But I'm not sure such is good for a wiki as far as a feature anyhow. --top
* That it is not a good feature is exactly the point.. (human oriented stuff doesn't always fit relational model, hence I don't buy everything on the dbdebunk site about how ''they deal with real data'' (real men...) and other people are all wrong (those claims have been made by dbdebunk). Some solutions do not fit the relational model and that is why markup exists. Even the dbdebunk.com website is not run off a database and I'm not sure that the authors of dbdebunk ''even use a database'' to manage their articles... so in ''real life'' situations there are many database weenies who don't even realize ''what they are doing'' is not relational and not always a relational model fits the task. The guy on dbdebunk makes excuses like ''but it is too hard for me to have a real website, I just use Word.doc files''.. which is again proving the point that sometimes relational just doesn't suit the task at hand. This is the problem I see with things like TableOrientedProgramming because you can't map everything to a table. It could even lead to tables inside tables. Some of it is going to be loose unstructured markup, with after hacks like search and replace parsing per each cell, instead of ''pure'' relational design. My philosophy is not to be a purist and to combine aspects of a few paradigms.  We must prioritize what paradigms to focus on for the task at hand, possibly (purists JustDontGetIt).
*''I built a blog that used MySql to store articles. Its just that existing skills and tools are not built around the concept, a kind of QwertySyndrome. (Incentally, the hard-drive crashed, corrupting the data due to a quirk in MySql auto-number implementation.) If you have only 50 or so articles, existing tools work better under a file-centric approach. You have FTP, for example, but no standard DB transfer available from the hoster. --top''

''Are you thinking of cascading deletes?'' -- DV

Yeah, that's it. Thanks. I'm a visual thinker and sometimes cannot turn pictures into words. (I come from a family of professional artists.) --top

----
MarchZeroEight  See also: RelationalWithSideEffects