spaghettidba (10/21/2014)
Hi!It's been a very long time since I last posted on THE thread...
Actually it's been a very long time since I posted regularly on the forums, but now I want to start again.
I've been very busy during the last two years and something had to go.
Now that I'm back, I'm glad to see that the same good people are still the soul of this community.
However, I'm a bit scared of the quality of the questions, which seem to have turned even worse (to go back to the original topic of THE thread).
I'm even more scared about the extreme slowness of the site. It's nearly unusable as it is.
Is it just me or does it load slowly for everyone?
Welcome back, ol' friend. The Force didn't feel right without you!
As to the quality of the questions and the problems presented, I've found that they represent what I've found in real life, as well. The economy here in the U.S. has gotten better and there's a real talent shortage, so many companies are hiring on an "if you show up for the interview, you have a job" basis. It's not yet as bad as the dot-com boom of the '90s but it's really sad because companies really need some high quality people that actually do understand data even in a NoSQL environment and they're not getting it. Instead, many people are now convinced that a database is just a place to store data.
I've just reviewed a brand new database made by a 3rd party vendor that we've hired. The BatchID column appears as an INT, an NVARCHAR(10), and an NVARCHAR(50) depending on what table you're in. The BatchID column also contains the same values as the BatchNumber column in other tables which is also the same as the Batch column in still other tables. One table has a single column index on every column and more than half the tables have no PK, clustered index, or even a unique index. When I made suggestions to change them all, the lead "developer" (lower case and in quotes for a reason) responded as follows...
I’m also not entirely sure I agree that every table needs to have a clustered PK (cross tables wouldn’t for example) nor would we always want to use the database to enforce referential integrity – sometimes we do this in the code instead of relying on the database. Sometimes we do things that aren’t perfect according to the way SQL server works simply because it doesn’t work the same in other DMBS systems, so we have to use the least common denominator.
Note that I included that the PK does NOT have to be the clustered index in my suggestions and gave some guidance on what would make a good clustered index.
This is also another reason why I say true portability is a myth.
Like Red Adair used to say, "[font="Arial Black"]If you think it's expensive to hire a professional to do the job, wait until you hire an amateur[/font]."
--Jeff Moden
Change is inevitable... Change for the better is not.