SQL Server: fundamental design issue? [closed]

Question

The director of the company I work for met another director of a software company at a party (this is not a joke !).

The second director told my director that,

'he had spent a fortune abandoning SQL Server' because 'if several people were querying the same table in different ways the database locked up'. Further, this is a 'known fundamental design issue with SQL Server where each query competes for maximum resources until SQL Server locks up after about 7 concurrent queries to the same table'.

Now I know a bit about SQL Server locking and IO and this is news to me. AFAIK there is nothing inherent in the SQL Server architectur that causes such problems. And SQL Server performs well in the TPC benchmarks, esp on price/performance.

Feel embarrassed asking but I have to be sure - is there any grain of truth to what he said ?

EDIT - after reading some of the comments I thought Id make it clear that I agree its possible to write poorly performing sql in Sql Server, as it is on any db platform. Sort of asking if there is anyting inherent in the architecture that blocks it out under certain high concurrency conditions irrespective of how well your db/sql is crafted?

Answer 1

There is absolutely no truth to this, and the other director clearly had one of the following two scenarios in his IT department, which can be found at very many firms:

1. No DBA, or the (idiot) director was the DBA, or someone with no DBA qualifications whatsoever was forced to act as the DBA
2. An incompetent DBA or incompetent IT employees who created the DB schema(s) and queried the database in incompetent ways given those schemas. Also, see TomTom's comment to this answer below, which expands and expounds on this item further.

Also, do have a look at SQL Server's market dominance at the moment, before coming to any conclusions of its inability to do something.

That is not to say that SQL Server is perfect and has no "fundamental design issues," such as for example this unbelievable bug you can encounter when using identity columns which practically everybody does for surrogate keys:

SCOPE_IDENTITY() sometimes returns incorrect value