good design practise for creating table/design [closed] - postgresql

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
The community reviewed whether to reopen this question 8 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
while inserting data into a RDBMS, we often validate data during api call using various data validation libraries, so I'm wondering if further table-level check constraints are good thing for a production like environment:
CREATE TABLE IF NOT EXISTS myTable
(
the_date date NOT NULL DEFAULT now(),
sentence character varying(10) COLLATE pg_catalog."default",
dayNumber integer NOT NULL CHECK (dayNumber BETWEEN 1 AND 7),
dayNumberInMonth integer NOT NULL CHECK (dayNumberInMonth BETWEEN 1 AND 32),
monthNumber integer CHECK (monthNumber BETWEEN 1 AND 12),
CONSTRAINT pk_myTable PRIMARY KEY (the_date)
);
is this a good thing in practise/production, or is this being more verbose and specific than required?

Answer 1

I guess it's a matter of opinion and trade off.
I favor not having checks defined both in the table definitions and performed on the application level, to avoid the duplication of the logic and improve maintainability (cf single responsibility principle).
For the field validity stuff, like a number being within a range or so, I tend to position those in the app itself, because the DB is often not capable to validate them all with precision (how to make sure a string is a valid email for example), and having all the checks in app also helps build consistent error messages.
OTOH, the DB is the only place where you can check for some invariants, like unicity of some column, consistency of the foreign/primary key relationship, transaction isolation, atomicity... This is especially true in a concurrent and distributed setting: the DB is the only part of the system that is strongly consistent, and therefore "knows enough" to do some of the checks.
Also, all the work that the DB can do is logic that you don't have to re-implement in your app, and the code of the DB is often battled-tested => you can choose to delegate a lot to your DB in order to keep your application code lean.
Some say that you should not depend too much on vendor-specific features of your DB and de-couple it from your application via some abstract interface, although I often disagree with that: vendor-specific DB features (like specific checks in your example) are usually where most of the added-value of that DB lies, and in 20 years of software engineering I've almost never encountered the mythical situation where a project decided to swap their DB vendor for another (or when they did, they precisely did it to benefit from some specific features => the abstraction was in the way and had to be refactored or removed, without providing any protection nor benefit).
In short:
make sure each piece of logic is defined in only one place overall
let your DB do all it's good at, and try to have a large proportion of your code doing business value-added stuff instead of technical stuff
it's all a trade-off really, just pick a philosophy and accept its down-sides :)

Answer 2

There are many valid ways of looking at this sort of question, and it depends on your overall application architecture.
There's a spectrum of validation, from "data" to "business".
Data validation includes things like "is this primary key field unique?", "is this date actually a date?", "is this field really an integer", "does this field have a value?".
Business validation includes things like "we don't accept new orders at the weekend", "we don't accept orders from customers with a balance lower than $100", "All orders must have at least one product from category XYZ".
You want data validation to happen in the database. Standard SQL supports a lot of this.
Business validation can be in the database, but typically requires non-standard extensions - and even then, is often hard to implement.
The benefit of doing it in the database is that you can support multiple clients and ensure they adhere to the same rules.
The drawback is that it's difficult to deliver, and hard to maintain - and even harder to change. Database changes typically are a big deal, and the changes can ripple through many layers of the application. For instance, allowing a column to be null may change the UI logic. And business validation logic is much more likely to change than core data type validation.
So most architectures have a "business logic" layer - the "model" in model/view/controller, for instance - which applies business logic, and validates it.
Your example, however, is not as clear cut.
The validation you propose is much closer to "data type" than to "business logic". It's hard to imagine a scenario where a week would have more than 7 days.
My preference would be to enforce those rules by unit testing the business logic code, rather than the database. It's easier to verify alongside all the other business logic, and I prefer business logic validation to live in a single place (the API) rather than two places.