Depends on what "rules" you're going by. Generally if you're using a relational database, you're going to start with rules of normalization. This violates nearly all of them at every level of normalization, take your pick.
As far as selling the need to rework it, focus on the benefits of a relational approach that you are NOT getting by allowing this to remain in production. The academic support I've seen for the associative model is just that, academic. Ignoring the actual industry implementations of the "relational model" and sticking to the books, one can have a compelling conversation about the mathematical purity of each approach. Back in the real world, one better have a really good reason for why they ditched baked-in features like constraints, indexes, atomicity/consistency, etc.
For you it sounds like maintainability is tantamount. Instead of blowing holes in the associative approach, I'd instead focus on increased OVERALL efficiency, stability and security you'll gain from moving to a less bizarre approach.
Quote:
Originally Posted by pootle flump
If you are presenting the efficacy of two competing designs to the stakeholders then better to avoid dry academia (especially since you are coming from a position of ignorance compared to the consultants) and focus on the nults and bolts they can understand. Usually alternatives to the relational model are seductive when measured by the flexibility and ease data can be inserted, and highly expensive when the practicalities of extracting information (not data, information) are taken into account. It might not be the case here, but it is a good start since the cost of writing 5 lines of code Vs 25 lines of code can be understood by anyone.
|
This. The academic merits of either approach are completely worthless in production IMO. Academically, I can argue that a non-relational model gives me EXTREME flexibility and blinding speed as an application developer. In the real world, this is a bad, bad, BAD idea. Discipline and rigor are difficult and expensive enough to implement in your average SDLC with a "restrictive" relational model. Just how easy do you want to make it for developers (and possibly users) to circumvent business rules with lightening speed at the expense of everything else? Then there's maintainability... I'm guessing you don't need any help poking holes in that one.
But really, stack up the merits, not the drawbacks. Bump those up against your business requirements, which one makes more sense? There aren't many scenarios (though they DO exist) where a wholesale departure from a relational approach is well warranted. There's a point where performance and flexibility outweigh the possibility of inconsistent or incorrect data (think Google/Facebook). Chances are you'll know if you're in one of those scenarios long before you actually start building anything.
dBforums
>
I have a modeling question
10-08-10, 15:47
Linear Mode
