Hacker News Reader

Comment by saym | Hacker News Reader

At first, I thought this wasn't a big deal because JSON really is just text.

Then I realized that this will help in validation. Go Postgres!

...maybe my perspective is different, but WHY would you want to do validation of a "complex" field at the db level? (I mean, for a web app you end up with 3 (!!) layers of validation now: 1. client (javascript), 2. app (...), 3. db (javascript? PL/something?) and, as an added "bonus", you loose the ability to migrate to a different db

...all these db features seem like maintainance nightmare waiting to happen. ...why don't people keep the rdbms "slim" and mean and write the logic in your app code, where it belongs? (you don't even have version control for the code in stored db procedures and things like that!!)

> WHY would you want to do validation of a "complex" field at the db level?

Anything I build on top of this database now benefits from all of my consistency and integrity checks. While it won't prevent me from trying to put bad data in, it will prevent me from actually doing the storage (instead, it will remind me that I'm a terrible human and I forgot to validate certain parts of data).

> I mean, for a web app you end up with 3 (!!) layers of validation now: 1. client (javascript), 2. app (...), 3. db (javascript? PL/something?)

This is a legitimate concern, but not all applications need all these checks. Hopefully you've abstracted things apart enough so that you can build your application reusing logic where possible.

> as an added "bonus", you loose the ability to migrate to a different db

I hear this one a lot, and it's so misguided imo. Different database systems are implemented completely differently. If we strictly adhered to relational algebra and the relational model then we might be in a position where you could switch out databases and have the same performance. However, what we have no doesn't work like that. Even if you strictly use standard SQL, I can almost guarantee that for large databases you'll see difference performance characteristics over the different database implementations.

> why don't people keep the rdbms "slim" and mean and write the logic in your app code, where it belongs?

That isnt where it belongs at all. Your app should interact with the database, but the database should have the final say in guaranteeing consistency. This provides an excellent foundation that allow you to now layer future projects on top of, without being tied to a specific application framework/library/programming language. Remember, we already have the impedance mismatch so whenever you map from the database to your application, you make a decision about how that mapping is done. So even if you offload all the database stuff to your 'app', you limit yourself to what you can truly do with the database.

Seriously, let the database do its job and be a database.

> you don't even have version control for the code in stored db procedures and things like that!!

This is nonsense. http://pyrseas.projects.postgresql.org/ https://github.com/theory/sqitch https://github.com/depesz/Versioning. Do your research.

(you don't even have version control for the code in stored db procedures and things like that!!)

You should absolutely be storing your scripts to create your database schema, including stored procedures, in version control.

As in most things in software engineering, it's a matter of tradeoff. Consider for instance the case where multiple applications access the database. You could either build a service abstracting, or you could build your validation layer in the database via stored procedures (maybe you can't afford the latency of the service), in which case you'll appreciate the additional safety.

Or you could have used a domain with a validator written in PL/somelanguage as constraint

Reply on news.ycombinator.com