It's your right as a customer to confront your vendors.
This kind of thing doesn’t happen often, but after blogging last week I found myself in a meeting with a vendor who is definitely one of the ones I was complaining about. This vendor is storing images in the DB which yields such bad performance they have to cut the DB into 50GB chunks to be able to return data fast enough. So we’ve got dozens of these 50GB DBs lying around on this server and a convoluted method of determining which one houses the data.
So I was still a little amped after blogging about this very subject so I found myself grilling the vendor as to why they made the decisions they did… particularly the decision to go against 20yrs of standards about not storing images directly in the DB. He said he didn’t know but he’d try to find out for me. And I said, well this project is about upgrading our current install to your most current version on SQL2K8 yet there are no backend code changes. Can you explain why we’re going from SQL2K to SQL2K8 with not a single code change on the backend? He said that everything worked just fine so there was no reason to make any code changes. “Everything will run as it does now.” I said, yeah that’s the problem. How can you say everything runs fine now when you have to chop your data up into 50GB chunks? Does that sound like it runs fine to you? You do know that most DBs can handle much more data than that, right? He went silent for almost a full minute and finally said… I’ll have to get back to you on that. Then I said, so while you’re at it can you ask your devs why almost every query that comes with your app does some form of table scan. You have a few indexes in the DB, but none of them appear to be used by any of the queries. Do you think that may be the source of your performance trouble? He said, I really don’t know I’ll have to get back with you on that one too.
I have no shortage of stories of bad DBs. I work in healthcare and for those of you who don’t know, healthcare is a good 20yrs behind everyone else in technology. I have another vendor whom I haven’t with yet, who has upgraded their product from dos to windows over the years and has even put together a SQL Server version. We’re about to upgrade to the latest version which uses SQL2K8. The really sad thing is that when they “developed” their DB version, all they did was fudge together COM calls from the DB. So they’re still running off of the same ancient .dlls they were before, only now they’re calling them from SQL. So yeah, to say they have a SQL Server version is true only in the strictest sense. That’s the kind of thing that makes the DB completely untenable because you can’t access any of the code. I suppose you could get lucky with a trace and find a query that you’re able to identify a new index for, but it’s unlikely they’re querying the DB in a way that it’ll work out for you.
These are just more examples of how vendors HAVE to start taking responsibility for their products. You can’t keep pushing the same crap out on the market and expect it to produce gold. IT is coming around slowly to realize that DBs need to be architected as part of the process but it is coming around. So vendors like this are going to be called to the mat for stuff like this eventually. Seriously, your days are numbered because the industry as a whole isn’t going to put up with these shenanigans forever. And I’m doing my part to speed that along. So do your part and confront your vendors and make sure they know that throwing something together and calling it an upgrade isn’t acceptable.
