Re:SQL is 43 years old – Here’s why we still use it today
by elmigranto on Tuesday May 02, 2017 @10:00AM
(#14246351)
> 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.
Re:SQL is 43 years old – Here’s why we still use it today
by scarface74 on Tuesday May 02, 2017 @01:31PM
(#14248497)
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.
So by "checking data" can we check all of the business constraints?
Re:SQL is 43 years old – Here’s why we still use it today
by elmigranto on Tuesday May 02, 2017 @01:46PM
(#14248675)
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.
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.