When To Touch

It seems that every product that has an underlying database has documentation that says not to modify the schema?  Do you always pay attention to that warning? The PSS blog at Microsoft says that for Reporting Services you ought to definitely keep your hands off, and gives some good reasons why you should.

However what about those other products? Dynamics, SAP, JD Edwards, and other common types of software that many companies use. Can you modify them at all? Perhaps.

We hear about the build vs. buy debate in software, but there’s also the modify vs. workaround argument. I was reminded of that from the PSS blog. There are times that you might be tempted to change things in a database built a software company, or add objects to that database. In many cases this can be seen as action that voids any support contract with the vendor, and more often than not they won’t want to give permission to make changes.

I can understand that, as it can substantially increase the support costs for a software company. However I also think that a blanket policy prohibiting changes is a bad idea.

I think there are plenty of things that you can do, especially with the latest versions of SQL Server, that could be useful “touches” that improve the use of a database. Adding indexes judiciously to improve performance of some queries is one very light touch that can add tremendous benefits. Adding reporting objects in another schema could help you extend functionality to get more value from the software.

Touching a database that you didn’t build should be done carefully, lightly, and with a lot of testing, and it can be something that creates a much more valuable system.

Steve Jones

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , , . Bookmark the permalink.