December 26, 2006 at 12:31 pm
A third party application vendor wants to extract data by installing their own triggers in our databases. This strikes me as unusual. Since we are responsible for our schema, performance, stability, etc, isn't doing this opening us to unacceptable risk? Under what conditions and restrictions might this be considered OK? We have hundreds of our customers in a Citrix farm. These triggers would be in all of their databases. We are considering replicating the data and allowing the vendor to use those rather than giving direct access to the production data. This has it's own challenges due to the number of databases.
Thoughts?
Bob
SuccessWare Software
December 27, 2006 at 5:07 am
This sounds very questionable, from what you tell us, but I suppose there could be something unstated about the situation that MIGHT make it reasonable.
More information would help, such as what kind of data are they looking for, what will they do with it, and why are you expected to provide it? What is the benefit to you and/or your customers?
Unless very strictly controlled, this seems to be the equivalent of giving someone a copy of your car keys and hoping they will only drive your car when you don't want it...
December 27, 2006 at 7:10 am
My response to the vendor would be "No way!".
Before I went that route, I'd try to find another application, or write my own.
December 27, 2006 at 7:15 am
The purpose is to extract, consolidate and analyse data and present it through an interactive web interface. This would likely include sales, inventory, and other operational data.
Strict control is the primary issue as far as I am concerned. It would require at least the following:
1) We would have to review and certify all code in the triggers. The ability to do this is already in doubt as it has been presented as a proprietary product. A strict NDA may be enough but there is some resistance even with this.
2) We would install the triggers. Object ownership would not be given to the vendor. Granular permissions would be set to enforce appropriate access to views and tables
3) Changes to the triggers would have to be re-certified.
4) The vendor would have no access to any administrative functions. They would not have any object creation permissions.
5) Any indexing related to their queries would also need to be certified and subject to change management. Optimization of indexing would be biased in favor of our application.
Anything else?
One big issue is who excepts liability for problems. If we certify their triggers but something slips through QA that seriously degrades performance, then our customers will not be happy. But because we certified it, who takes the hit for any costs incurred due to the failure?
Bob
SuccessWare Software
December 27, 2006 at 10:32 am
Installation of triggers to gather data for analysis on multpile servers on a Citrix farm ??? What kind of architecture is that ???
Their architecture is indicative of their design. support and skill. Do not just run away - run away from this vendor like they had the plague !
If you cannot stop this potential abomination then document your objections and get a superior to document the directive(s) that you need to take ("make you do it") so you are covered.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
December 27, 2006 at 11:24 am
any idea what kind of performance hit you are going to take with the triggers? where i work every time someone asks for a trigger there is big conference at the VP level to discuss potential performance hits
December 27, 2006 at 11:25 am
Terrible idea. Good products will not mandate that you install any types of agents on your databases and servers. You can never hold a vendor responsible for loss of data or any other business impact (check out their EULA; this is a standard clause in every EULA), so:
1. Triggers impact performance, therefore will have some impact (even if minimal) on your operations.
2. If they have the smallest bug in their tools, you may need to kiss you data goodbye and they will not be liable for it.
Bottom line- I would recommend to look for another tool. Beside, there are plenty of 3rd party tools that allow you to gather data from all databases/servers without triggers. SQL Farm Combine for one.
Editor's Note: : Dr. Omri Bahat works for SQLFarms, a software vendor of SQL Server tools.
December 27, 2006 at 11:32 am
Well! No equivocation in your assesment (though I tend to agree).
Perhaps I should be more clear. Our customers access our application via Citrix. The application itself uses SQL Server on the back-end. The database servers are all single use, SQL boxes with minimal services installed.
So far, from here and other contacts as well, I am getting a relative unanimous opinion. Don't do this. This is helpul because it helps bolster my case against this. My superior is already opposed to this approach abd he holds considerable influence on the outcome. I think we we will be able to successfully insist on another approach.
Bob
SuccessWare Software
December 27, 2006 at 4:00 pm
And not to mention that if their triggers fail, it can cause your transactions to rollback.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply