<story><title>Beware of Developers Who Do Negative Work</title><url>http://blog.professorbeekums.com/2016/12/beware-of-developers-who-do-negative.html</url></story><parent_chain><item><author>indexerror</author><text>Can you explain why you feel that &amp;quot;do everything in the database&amp;quot; is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won&amp;#x27;t trust anything that only has application level security, and nothing at database level to check&amp;#x2F;limit it.</text></item><item><author>renolc</author><text>This is definitely true on both ends.&lt;p&gt;At a previous company, the tech influencers believed in the archaic &amp;quot;do everything in the database.&amp;quot; While we were technically using the .Net stack, we weren&amp;#x27;t allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue).&lt;p&gt;Similarly at my current company, we had a product were the initial devs wanted to jump on the RXJS and Socket.io bandwagons. The only problem was the rest of the company was using standard REST endpoints and promises to do the same thing, so any new devs who joined that team suddenly had massive cognitive overhead they had to overcome. Any changes to the codebase we&amp;#x27;re done by people who only half understood what they were doing, and so the complexity compounded. Thankfully, I was given the chance to rewrite the whole codebase to match what our other products looked like, so now the code is much more sane to work with.</text></item><item><author>userbinator</author><text>&lt;i&gt;An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company.&lt;/i&gt;&lt;p&gt;At the other extreme is the developer who is so entranced by &amp;quot;newer is better&amp;quot; mentality that they rewrite everything in an attempt to conform to &amp;quot;latest best practices&amp;quot;, increasing complexity massively while introducing a bunch of bugs and huge dependencies no one ever actually needed. I&amp;#x27;ve experienced that (and had to undo the mess) a few times.&lt;p&gt;Relatedly, just as there are &amp;quot;10x&amp;quot; developers, there are &amp;quot;-10x&amp;quot; as well --- it takes the average developer 10 times as long to fix as one of these takes to break.</text></item></parent_chain><comment><author>Illniyar</author><text>Logic in the Database has the following issues:&lt;p&gt;1. it doesn&amp;#x27;t work well with source control&lt;p&gt;2. deployments, rollback, replication, synchornization - they don&amp;#x27;t work very well with db procedures&lt;p&gt;3. unless you connect directly to the db, then you must have some logic on the serverside, usually you end up replicating logic from the db to the serverside&lt;p&gt;4. Databases languages (even advanced ones like PL&amp;#x2F;SQL) are not expressive enough&lt;p&gt;5.It&amp;#x27;s much easier to scale out the server then the database (and if you are using Oracle&amp;#x2F;Sql-server etc... also cheaper), and you don&amp;#x27;t want your database&amp;#x27;s cpu to be clogged with logic code execution&lt;p&gt;6.Unit testing (or any testing) is extremely difficult&lt;p&gt;7.Debugging is hard and convoluted (also it doesn&amp;#x27;t usually work inside your IDE)&lt;p&gt;and a whole lot more.&lt;p&gt;Nothing is absolute or completely obsolete, but it is considered a bad practice for a long time by most industry professionals.&lt;p&gt;As far as I know the most popular article about it is:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.codinghorror.com&amp;#x2F;who-needs-stored-procedures-anyways&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.codinghorror.com&amp;#x2F;who-needs-stored-procedures-an...&lt;/a&gt;</text></comment>
<story><title>Beware of Developers Who Do Negative Work</title><url>http://blog.professorbeekums.com/2016/12/beware-of-developers-who-do-negative.html</url></story><parent_chain><item><author>indexerror</author><text>Can you explain why you feel that &amp;quot;do everything in the database&amp;quot; is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won&amp;#x27;t trust anything that only has application level security, and nothing at database level to check&amp;#x2F;limit it.</text></item><item><author>renolc</author><text>This is definitely true on both ends.&lt;p&gt;At a previous company, the tech influencers believed in the archaic &amp;quot;do everything in the database.&amp;quot; While we were technically using the .Net stack, we weren&amp;#x27;t allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue).&lt;p&gt;Similarly at my current company, we had a product were the initial devs wanted to jump on the RXJS and Socket.io bandwagons. The only problem was the rest of the company was using standard REST endpoints and promises to do the same thing, so any new devs who joined that team suddenly had massive cognitive overhead they had to overcome. Any changes to the codebase we&amp;#x27;re done by people who only half understood what they were doing, and so the complexity compounded. Thankfully, I was given the chance to rewrite the whole codebase to match what our other products looked like, so now the code is much more sane to work with.</text></item><item><author>userbinator</author><text>&lt;i&gt;An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company.&lt;/i&gt;&lt;p&gt;At the other extreme is the developer who is so entranced by &amp;quot;newer is better&amp;quot; mentality that they rewrite everything in an attempt to conform to &amp;quot;latest best practices&amp;quot;, increasing complexity massively while introducing a bunch of bugs and huge dependencies no one ever actually needed. I&amp;#x27;ve experienced that (and had to undo the mess) a few times.&lt;p&gt;Relatedly, just as there are &amp;quot;10x&amp;quot; developers, there are &amp;quot;-10x&amp;quot; as well --- it takes the average developer 10 times as long to fix as one of these takes to break.</text></item></parent_chain><comment><author>renolc</author><text>Absolutely. SQL is great, and having the DB just give you the correct data from the get go is convenient. But in the case where complex logic is necessary, SQL is much more difficult for correct implementation than something more expressive.&lt;p&gt;You _could_ delve into cursors or long merge statements or what have you, but in business logic specifically, the code will be read and altered numerous times by several different people. In that case, a language made specifically for expressive statements is significantly easier to deal with. That&amp;#x27;s not to say that I believe the opposite is true and that _everything_ should be done in programming space. I just think there is a better balance that can be achieved, and to default having everything in either category probably means you&amp;#x27;re not balancing correctly.</text></comment>