In relational you can just completely reshape you model too easily, so, a lot of people just don't try enough to make it right, they just throw whatever they come up with, and twist it until they make to somewhat work.

I have met a lot of people that say: It just doesn't matter if it not normalized, (for example if a OneToMany relationship is represented as comma separated values in a field) I can always fix it by creating a view on top of it. Relational gives you the ultimate flexibility to reshape your model, but that is a double edged sword, because it makes people careless.

Yes, in hierarchical you had to define each of your relationships and it was harder than in relational if you realized you needed a new kind of relationship (a new join) but in relational you have to deal with this shared values that make it easier to redefine joins, but also lower the level of abstraction and you loose the ability to just say: I want all the customers of that store "store.getCustomers()" you have to say: I want all the customer rows that have a store number 5 "select * from customer where customer.storenumber = 5" and, if, after time passes, it turns out you need more data to identify a store, you need to add that information to you customer: "select * from customer where customer.storenumber = 5 and customer.citycode = NY" but, if you are working with OOP/Hierarchical you just don't care, you just redefine the relationship and use  "store.getCustomers()" again.

Of course, this could be less problematic, if, for example, one could somewhat use integrity relation names as shortcuts for relationships in joins, and "abstract away" the particularities of the relationship... but that is not possible in any of the current relational databases... why is that? 

* Are you talking about NaturalJoin''''''s? They do exist. But, I don't like the way they are implemented. They should depend on a relationship dictionary and not on naming conventions.
** Exactly, they should depend on a relationship dictionary, for example the one that store the foreign key constraints
* [Evil!  They should depend entirely on attribute names (with a RENAME operator if needed), not on some external metadata.]
** Why evil? If anything is evil that would be the lack of metadata standardization between databases
** [It forces the reader to refer to (additional) metadata in order to interpret the meaning of relational expressions, it causes the meaning of relational expressions to be dependent on more than just relvar definitions, and it means joins on ad-hoc and temporary results must be pre-defined in the metadata.  In short, avoiding references to metadata reduces needless dependencies.]

''Relational is too boxy. And I realize the relational model is not about tables,  it is about '''relvars''' (according to dbdebunk there is no data stored in tables.. which is a nitpick). But boxes/tables are ultimately what we see the data presented as in our minds, no matter what '''relvars''' purism they want to argue about. '''Boxes are very powerful''', but they also are '''horrible in some ways'''. When you try to fit all your sharp pointy and brittle ornaments into a cardboard box.... sometimes things poke through the cardboard and just won't fit nicely.. and you have to add styrofoam and packing protection in the box (markup). Consider trying to model a wiki article into a relational model. The wiki '''files''' (so to say) can be stored in the database.. but the article is much harder to get into relational format. Especially if for example you have certain topics in the article that can be split up into sections as the wikipedia splits them into those edit areas. Try getting that into a database without disobeying every relational model rule in the books... what solution people use is '''markup''' which is not relational. So then the argument begins..hmm okay so if markup is okay and acceptable, then what else can we use it for and when is it not acceptable? Then the purists come in and try and force you to use relational for stuff that isn't naturally relational. Since humans sometimes spit out stuff (and grok stuff) in serial unrelational streams (config files, INI files, xml files, etc).. like this paragraph I'm writing now. It is also hard to make definitive decisions about what relates to what, such as page topics, paragraphs, etc. Some of it is '''partly''' related in ways you just cannot put into a pure boxy relational model.'' 

I can see relational being used at the paragraph (ParagraphWiki) and perhaps even sentence level. But I agree that things like formulas and linguistic statements are not readily tablizable, at least not in a form that most humans are comfortable with. Internally they could be, but not at the presentation and input side.

''There are also many cases when something like a spreadsheet (excel) is just good enough for what you are doing. Imagine doing a quick accounting calculation with SQL (or TutorialDee).. versus the Excel program. Excel is not relational but ItJustWorks.. for some tasks. Really it becomes about '''scalability of the data'''.  Excel is better for OneOffs, but not for '''long term scalable solutions'''. On the other hand, a perfect relational model has a big up front cost: you have to spend a lot of time getting it right. '''HumansDoNotHaveTime''. Humans are busy busy people. I say this as an XML hater myself.. too. I'm not advocating we not use relational models.. but sometimes, they just will not fit our minds when we need convenient solutions to get her going. Humans are very convenience based.. and we have not such good attention spans. The relational model requires a high attention span and careful meticulous calculations and thinking.. which you may not even ever get right even after sitting there for 8 hours.'' 

Quick-and-dirty and one-off things often work fine without being normalized. Its when scaling and sharing come into play that it starts to matter. Graphs and trees are indeed convenient and easy to grok on a smaller scale or scope. --top

RelationalIsTooPowerful - good. Feed me raw power.