Relational Vs Xp

Does relational philosophy conflict with XP?

(I am not sure if this will stay in this topic. I am still looking for a home(s) for this content. Suggestions welcome.)

There are various terms for how XP works with relational databases. Most commonly known as AgileModeling. ScottAmbler has written a great deal on this subject. One of his papers has the following description of the agile dba:

...when it comes to data modeling Agile DBAs will:

Mentor application developers in fundamental data modeling techniques.
Mentor experienced enterprise architects and administrators in evolutionary modeling techniques.
Ensure that the team follows data modeling standards and conventions.
Develop and evolve the data model(s), in an evolutionary (iterative and incremental) manner, to meet the needs of the project team.
Keep the database schema(s) in sync with the physical data model(s).

Some people would rather avoid RDBMS altogether. See DbasGoneBad. They say YouArentGoingToNeedIt and not to add it until you do, which would be a big overhaul IMO. BTW, what is "physical data model"?

I don't know about all RelationalWeenies, but this one thinks that relational thinking and modeling tends to go against ExtremeProgramming philosophy. I believe that the "power" of relational is not likely to organically emerge. Organic design tends to lead to NavigationalDatabase-like structures. (The human brain is navigational for the most part.) Further, the failure rates that have lead to the XP push are in my opinion the result of the messes created by excessive OO modeling, and would not be needed if RDBMS were used for the NounModel instead of mostly code. (More links on this opinion to come when I find better topic titles.)

Further, it is often said that XP works better for "larger projects". Relational-centric designs tend to break "large projects" into smaller projects. One tends to focus on one "task" (module) at a time and the primary communication between tasks is through the database, not code. This makes it easier to DivideAndConquer IMO. (SystemSizeMetrics) One mustly just has to know about the database rather than a jillion other tasks (and some shared libraries). Oo just ends up with a BigSoupOfClasses IMO.

Few if any people claim that XP works better for larger projects. XP tends to work best on smaller projects with less than 20 people. The above is inflammatory and wrong. Please cite anyone in the XP community who has written that "XP works better for larger projects". This is really the wrong place to make spurious, anonymous and unverifiable claims about XP.

I disagree with the "organic leads to navigational" argument above. I tend to design organically, and (like others with whom I work) tend to build a relational model in from the beginning and modify it freely. At any time, the relational model reflects my (emerging) understanding of the problem (ScottAmbler is right). I don't really understand why some sort of big-design-up-front approach would be required to work with relational structures.

(refactored from DbasGoneBad)

I reject much of XP. It is actually counter to the idea of "change-friendly" since it accepts code rearrangement as a formal role. There are change patterns which are fairly predictable, and data structures growing more complex or more shared is common. Plus, a well-designed relational API is not bloat. Relational done right can be lean, mean, and clean. To be frank, I think XP is a movement resulting from sprawling OO messes that decent relational-centric systems don't have nearly as much. Flame back all you want, but that is my honest opinion.

Based on quite a bit of experience with both approaches on large enterprise projects, my observation is that XP-influenced projects are much more likely to 1) result in delivery of a product, and 2) result in a maintainable and long-lived codebase. But you're right, that's a separate topic, covered in detail in other places on this wiki.

I would like to study the alleged failures of relational-centric designs. See below.

I propose that a business software project is not likely to fail if:

The schema is carefully and skillfully designed
The schema and shared code libraries are well documented
Developers pretty much deal with one task at a time (ProceduralMethodologies)
Libraries which have complex state are converted to use more of the database
The more experienced designers dole out tasks and library assignments
Experienced designers do code spot checks
Keep in communication with customer
It is something feasible to automate
Reasonable repetition factoring (as opposed to "mercilessly")
Features or tasks are prioritized by need
All engineers stand on their heads while programming.

If you know of a project that failed, yet followed these guidelines, I would like to know more about it.

The above is just too naive for words. There's no mention of testing, requirements or the quality of the development team.

Funny thing is, this is almost exactly the list I'd say will kill any project. These are almost all things to watch out for as a sign of bad things to come IMHO!

How would anyone determine if the first item is true? This appears to be entirely subjective evaluation leading to the assumption that if the project fails the schema was not "carefully and skillfully designed."

I think the problem with software development really has more to do with the schism between database and coding that the industry invented than the things XP raves about. This is bad, since DBAs can't deliver an application, while application programmers can't deliver a working information system. Tragic comedy at its finest.

IAC, the way you tell if a schema is "skillfully designed" is if the relational model has been appropriately followed. See the Fleming and Von Halle book "Handbook of Relational Database Design" for a practical discourse on the subject. Things have not improved on their simple approach, except the realization that waterfall doesn't work. Oh, and that testing and integration have to be continuous, and that refactoring code has to be done, the same way that remodelling your database needs to be done, whenever your understanding of the model (and thus the solution) changes. Of course, when you automatically generate your DAL classes, presentation-tier proxies and CRUD classes from your relational model, all of this gets to be easy and may be fearlessly engaged in, as it is just the press of a button. :-)

XP seems like a bit of overkill, but Relational augmented by a good template-driven code-generator takes care of more than 50% of the code in the typical business application. I guess the only problem there is that you have to teach programmers how to data model and data modellers how to program, but that's really a solution more than a problem.