>>cpu speeds are always improving with more and more cores, so they are cheap too.
>
>We're talking about SQL server machines. The hardware may be relatively cheap, although the RAID stuff and some performance choices may make it perhaps cost two regular machines.
>
>But the cost of installation is workdays. Just running the setup, changing the default settings, trying a connection, finding one more setting that needs to be changed, one more service that needs to be started, repeating that until OK... that may take a couple of days of your most expensive workers' time. And then the migration of the data. SQL seems to be compatible just two versions back, so if you're migrating from, say, 2000, you may need to have 2008 (express would do) to migrate it to 2014 (of which I'm not quite sure, but I did have a case when I had to take such a path). Which then has to be run at least twice, once to find a path which works, and then for production.
>
>All of this is the reason why it may all be nice and shiny on a fresh server with a new database. Come to a customer with a database which has accumulated multiple years of data and you'll find that their servers will not be spanking new, their database may be some older version, may be using now deprecated features... and your calculation of the cost of running it this way or that way may suffer some drawbacks. SQL isn't javascript code where you can count on pretty much everyone running the latest version - it's a completely different game.

I don't want to dismiss your input, but here's what I've seen - college professor does a system - natural keys - calls a UDF that does a query - per row of a first query. There is so much junk being done in the field, that I really feel these key discussions are a waste.

The natural keys origin of this discussion is more of said junk.