3

From Wikipedia's article on DRY Software:

The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. They apply it quite broadly to include "database schemas, test plans, the build system, even documentation".

From Wikipedia's article on Single Source of Truth:

In Information Systems design and theory, as instantiated at the Enterprise Level, Single Source Of Truth (SSOT) refers to the practice of structuring information models and associated schemata such that every data element is stored exactly once (e.g., in no more than a single row of a single table). Any possible linkages to this data element (possibly in other areas of the relational schema or even in distant federated databases) are by reference only.

My question: If I am writing a database application, and I have already written specific code to validate user-inputted data, would I breaking the principles of DRY and SSoT to define my database field's data types to most closely match the data it's expecting? (As opposed to say, just using text data types for every field. For the moment, let's ignore other potential benefits like indexing).

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
Callum
  • 435
  • 1
  • 4
  • 14
  • http://en.wikipedia.org/wiki/Object-relational_mapping – Oliver Charlesworth May 27 '13 at 01:17
  • Absolutely not. The truth *is* the information - and the model represents it. (Now, the database model might not be able to know - and perhaps should not know - every detail, but it should not allow a blatant lie.) – user2246674 May 27 '13 at 01:22
  • Let's say I have an input field that only takes numerical values, but the system owner says they now want to validate that input so that any alphanumeric values are permitted. By your answer's reasoning, I now have to update code in two places; the validation code at the application layer, *AND* the data type in the database. If my application is truly DRY and SSoT, then I shouldn't be updating things in two places to accommodate one change, no? – Callum May 27 '13 at 02:12

1 Answers1

7

You wouldn't be breaking the principle of DRY if your build process used a configuration file to generate correct code for both the database and for the application layer.

It's not unusual for application programmers to validate only at the application code level. This is usually a mistake.

For example, you can use a single configuration file to generate javascript for validating through a web interface, to generate SQL DDL, and to generate a SQL check() constraint for validating at the database level.

You can't sensibly avoid running different code in both execution environments. (Legacy database apps might have dozens of different execution environments.) DBAs don't have to use your application code to update the database. Other application code--code that you might not necessarily be told about--doesn't have to use your application code, either.

Mike Sherrill 'Cat Recall'
  • 91,602
  • 17
  • 122
  • 185