Safety Gold Plating

A form of GoldPlating based on the stated goal of reducing risk or errors.

(Based on conversation in FearOfAddingTables)

In some cases there may indeed be a tradeoff between simplicity/flexibility of design and "safety". We're right back at the ol' "anal safety tradeoff wars" that rage in relational and typing topics.

{Agreed. In some cases there are indeed tradeoffs. But it helps that the case presented in 'FearOfAddingTables' does NOT appear to be among those "some cases". The evidence presented thus far indicates we are actually GAINING simplicity AND flexibility by the same means we're improving safety - that there is no "tradeoff". All we have indicating the there are ANY measurable and relevant downsides are (a) your unsubstantiated protestations, and (b) lack of significant existing optimizer-support.} The latter can be remedied. If you wish your protests to have value, you should provide evidence.}

Airlines could be made safer with thicker chairs, per-passenger air-bags, shoulder harnesses, etc. However, as a society we've collectively decided we don't want to pay for those. We made a choice. pursuing every last safety mechanism "because we can" is not always economical. We resign to the extra chance that a few crash and burn to cut costs. That's life. If you want to form "8NF Airlines" for paranoid passengers, be my guest :-) --top

Do you have any evidence that air-bags would provide any 'real' safety to a plane? Or are you just claiming it for purposes of your didactic false analogy?
Are you claiming planes are as safe as they can possibly be, or just in a mood to nit for the hell of it?
As safe as they can possibly be? certainly not. But they're as safe as we know how to make them. Tell me: how the hell do you think thicker-chairs and airbags would really help you? and have you considered the downsides? and I don't just mean the economic ones; I mean the downsides to safety itself that come from naive attempts to acquire it. Here are a few: (1) greater weight applies greater stresses to the vehicle, reduces maneuverability, increasing likelihood of accident. (2) greater volume for safety gear reduces passenger manifest which requires a proportional increase in number of flights per day which overloads already stressed airports which increases likelihood of accident. (3) lack of evidence or tests to indicate that these will provide any help; with passenger vehicles, we have massive crash tests and dummies... people don't do that for multi-million dollar aircraft.
- I've actually heard a study that stronger seats would reduce fatalities, but the airlines didn't want to comply due to costs. If I find the source, I'll let you know. --top
  - "In the area of seat design, product improvement has focused mainly on survivability in a crash from both structural and restraint standpoints. FAA in 1988 required so-called 16g seats,which must pass rigorous static and dynamic tests that far exceed previous testing levels, for all new-production aircraft. The agency currently is working on a rule that would require existing aircraft to be retrofitted with the stronger seats in the next 14 years." - http://www.atwonline.com/magazine/article.html?articleID=1121
  - I'd note that there is no demonstrated improvement on human fatalities by moving to 16G seats, but it is nice to see them working to make us a safe as they know how.
Of course, as noted above, it isn't as though this airplane example applies too much here.
[I can't quite put my finger on what it is, but there's something about this off-topic safety-talk that makes me want to go ride my motorcycle down narrow, winding roads at jaw-droppingly illegal speeds.] -- DV
It's the WaterbedTheory of psychology: if you are anal at work, you have to be wild and crazy on the outside to compensate. Although, S&M seems to be the stereotype, not motorcycles ;-)

Actually, the airlines decided not to pay for those, not the public.

True, but we don't really know what the public's opinion is on this. Plus, in software, managers also make many of the decisions, not end-users. Thus, it tends to reflect the airline business. If there was really a demand for safer flights at more cost, then my "8NF Airlines" jokish suggestion may have merit. Volvo cars make safety a selling point, but it has failed to make a big splash with the public.

I've yet to see a case where the cost of proper normalisation plus the cost of implementing the code to use the properly-normalised schema exceeded the estimated cost of dealing with an insufficiently-normalised schema. This is trivially true because the former two costs are one-time, but the latter is ongoing. -- DaveVoorhis

I'd like to explore some such alleged disaster scenarios with an example, such as PublicationsExample. In my opinion, you guys tend to exaggerate such risk in proportion to all possible problems (including companies who expect to pay Chevy rates, not Volvo rates).

See http://en.wikipedia.org/wiki/3NF In particular, note that "the [non-3NF] table [is] vulnerable to logical inconsistencies, as there is nothing to stop the same person from being shown with different dates of birth on different records."

I don't disagree with that one.

See http://en.wikipedia.org/wiki/5NF In particular, note that "[i]f such a table is not normalized to 5NF, the burden of maintaining the logical consistency of the data within the table must be carried partly by the application responsible for insertions, deletions, and updates to it; and there is a heightened risk that the data within the table will become inconsistent. In contrast, the 5NF design excludes the possibility of such inconsistencies."

If you do not regard such potential inconsistencies as significant -- regardless of the application -- then I doubt there's anything I can do to convince you that they are. -- DV

The insurance one brings up an interesting scenario related to the "don't hardwire non-invariant divisions" rule described in FearOfAddingTables. If the insurance rule described is not a solid rule ("invariant"), we risk having to change our base tables. It is a matter of cost/benefit analysis. That's where domain experience is most helpful. If we have a hefty army of developers/DBA's to make such changes and test them well when they occur, then maybe we can live with the change risk. "Make the system easy to change" is often cited as a key goal. If that rule is rock-stable, it will not score high on change-friendliness. Medical and financial apps indeed do seem to lean toward safety instead of IT staff labor reduction, because the cost of data errors is higher than IT staff. My point is that it depends on domain issues.

Having personally maintained a 170-table schema deployed in over 70 sites -- that left time to do application development, management, support, and a number of other duties -- I have my doubts that a properly-normalised schema causes any additional difficulty with maintenance and implementing changes over an improperly-normalised schema. (Indeed, I suspect the opposite is true.) In other words, the personnel overhead required to maintain a properly-normalised schema (i.e., 5NF) is not significant. -- DV

Well, my experience differs. The thin-table designs were the butt of complaints from many IT specialists, not just me. One is currently being rebid for an overhaul or COTS replacement because people want it gone. The slicing not fitting the domain well (original or as it changed) was the main problem, but not the only. We'll just have to AgreeToDisagree because we're both depending on anecdotes. Again, maybe there is a right way and wrong way to do thin tables, and I encountered the wrong way (BetterOnlyIfDoneRight perhaps). --top

[Perhaps your experience differs because the entire industry is blown, and you've had to deal with twits just like the rest of us have (people that complain about performance, products, instead of correctness). Perhaps, they have dragged you down to their level. Perhaps the only solution is to do private projects that are controlled by yourself - since we live in an industry of fools.]
Perhaps you are making the "mistake" of telling the customer what they "should" have instead of what they want. Now, I put "mistake" in quotes because there is a philosophical/political issue here that roughly parallels the socialism-versus-capitalism debate. In socialism a central group (called "elitists" by some) dictates what the masses "should" have. In capitalism, the customer selects the weights of their own priorities. (There's a related topic somewhere on this wiki.) Your comment, "the entire industry is blown" suggests you fit into the socialist camp, at least with regard to IT.

Perhaps the designs were improperly normalised, or were generated by some ObjectRelationalMapping layer? Either of those can produce nightmare models. -- DV

LSD would be my guess. One known partial reason is that they tried to fit the style of existing paper forms, which had inherent duplication. It was either that or change the way they did business, and that was voted down. Paper forms are useful in the field. Maybe PDA's will replace them someday, but not yet. But, this alone doesn't explain a good portion of the mess.
I hope we've not been quibbling over this for days because you once got stung by a bad data modeler. -- DV
I've seen it in at least 5 different applications/databases, 2 medium-large ones. The ones I recall as being "okay or good" were generally wide-table designs (I'd do some parts different, but they served their need). Other than outright value duplication, I haven't seen many ways to screw up wide tables. If you want to show some, be my guest. True, it may force some of the validation into the app code that could be done via thin tables, but that's rarely created problems on my watch. In fact, it gives the app developer more control over the validation which is often a good thing because the DBA is too "distant" from the details of the domain in most shops.
{Methinks your assessment of "okay or good" and its opposite would often disagree with ours - it certainly does elsewhere on this page. Will you describe what you believed to be the problem and the associated parts of the schema with these databases you're making claims about?}

{TopMind, I've already presented evidence that 'wide' tables present a greater risk-of-change AND a greater cost-of-change. I'm inclined to believe that everything you are saying here favors thin tables if accepted as true.}

I found your assessments unrealistic and exaggerated.

I found them realistic and reasonable. -- DV

Here is an example of where a company (Microsoft) intentionally gave quality the shaft in order to beat the competition to market in order to gain vendor media content support. The author seems somewhat ambivalent as to whether the trade-off was worth it, but seems appears to agree that the decision was understandable and rational from a profitability standpoint. I am not promoting bad quality and rush-jobs, but only pointing out that market forces often give us developers tough choices. The comparative advantage of the US is not commodity items, but cutting edge technology and fads. To beat the competition, somethings quality has to give. We are often not given the resources for rigorous engineering. I don't think PaulGraham would have beat the competition if he used type-centric techniques.

http://venturebeat.com/2008/09/05/xbox-360-defects-an-inside-history-of-microsofts-video-game-console-woes/

AprilZeroEight

CategoryLanguageTyping