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).
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.