xsevensinzx - Thursday, April 19, 2018 9:33 PM

Not sure I follow. We are talking about normalization, which is the methodology of restructuring a relational model to reduce data redundancy and improve data integrity. We are not talking about using a RDBMS without said relational model. But even then, have a relational model just like the process of normalizing said relational model are mostly again, methodologies. We can define a relational model with ZERO primary key and foreign key constraints in terms of the tech. We however can rely on the tech (i.e.: SQL query language) as well those define constraints to help ensure the relational model is enforced and defined. This is where SQL Server as a tool becomes a great option in that's your methodology. Yet, the tech in either ORM or your chosen RDBMS is not exactly preventing you from doing so even before you get into the quality of each approach with said tech.

I don't want to sound like I'm going around in circles here, but I feel I'm talking about facts here and you're talking about opinions and preferences. It does not matter if you think using SQL Server with a physical body is your preferred preference to define a relational model. What matters is if you can achieve the same output with SQL Server as you can with the ORM. As they are mostly methodologies, you pretty much can.

I would say that taking the approach of using methodologies to argue this is not a good stance. This is because it entirely depends on the person using the tech. A former DBA using ORM is going to be different than an application developer who knows nothing about the DBA side of things. This is where you are hung up on, which is a flawed argument and stance because people can be improved, your tech, unless you have the source code or control over the owners, cannot. 

Should stick to the fact stored procedures is native to SQL Server and not native to ORM in which the ORM is restricted on that tech if said stored procedure execution is thrown out the window. Then it moves into the quality of using stored procedure over straight raw SQL. That's ideally the core of this argument on top of the raw SQL generated from ORM may not be of quality versus a human writing it for you.

As I said before, stored procedures being written by a human can be a bottleneck just as poor SQL generation from ORM can also be a bottleneck -- on performance.

P.S

I just want to emphasize that I love SQL Server, usage of stored procedures, and so forth. I'm just pushing this for the fact it's a good exercise to highlight how similar arguments hinder innovation and new approaches in IT.