undefined | Better HN

0 pointsscarface749y ago0 comments

But the GPs point was that by not keeping a consistent schema you end up moving the definition of the data into the application, and you need to be very aware of the trade-off.

Why wouldn't the defaults be in the application? Why wouldn't it be treated like any other piece of business logic in code that should be unit tested?

That being said, I only caught the NoSQL religion about six months ago when I started using Mongo. But SQL Server 2016 has such great support for JSON natively, as long as I'm spending other people's money, I prefer having the best of both worlds.

0 comments

3 comments · 1 top-level

elmigranto9y ago· 2 in thread

> Why wouldn't the defaults be in the application? Why wouldn't it be treated like any other piece of business logic in code that should be unit tested?

How about we check our data in the place where it lives given how very robust and mature products that do that were already written, tested, and used in production by literally thousands of people for decades.

scarface74OP9y ago

So by "checking data" can we check all of the business constraints?

elmigranto9y ago

Yes. If you really want to.

Definetly stuff like presence of fields and their basic sanity (string not being empty or within a certain length), date intervals, uniqueness of certain fields or combinations, etc.

You can go as far as you want, really; but like with most cases, when there's a range of possibilities, both extremes are probably a wrong answer.

j / k navigate · click thread line to collapse