|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Thursday, March 04, 2010 7:32 AM
Points: 5,
Visits: 69
|
|
I see that almost all responses are against encrypting. The few that have done so were to basically try to secure critical code for their system.
My perspective is that even the critical code should not be encrypted. If something is critical to your system and the company running your application is having a problem AND has a knowledgeable person that could investigate but not change anything, they might be able to see what is tripping by looking at how the processes are designed. If it's encrypted then the company is dead in the water until they get support from the vendor who encrypted it. In today's age, this company might be out of business or the person took off that encrypted it.
Folks, I've seen this with chemical instrument vendor in Milwaukee. They sold the business once, lost all of the developers, then someone bought this other company. So all of the knowledge of the design was gone. Your software may survive longer than the company you work for, or you built it for.
The other reason some people encrypt is for more or less job security. I have two words for that - YOU'RE FIRED. The best way to have job security is to be knowledgeable, helpful, and share your experience to help others. Someone who has to squirrel away their knowledge is useless.
|
|
|
|
|
SSChampion
Group: Administrators
Last Login: Today @ 3:50 AM
Points: 23,170,
Visits: 6,927
|
|
azz (4/10/2009)
Absolutely agree, that "If you can deliver a well performing, and good looking application, no one cares about the code."
But are there a lot of such applications ordered by middle and small size companies?
I think the absolute majority of applications are tested to "good-enough" state where developers assume maintenance issues.
You think so? I've worked in small and medium companies, and we've rarely been allowed to touch a 3rd party app. Even changing indexes for performance is frowned upon because of support.
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Sunday, January 03, 2010 4:54 PM
Points: 158,
Visits: 681
|
|
Steve Jones - Editor (4/10/2009)
You think so? I've worked in small and medium companies, and we've rarely been allowed to touch a 3rd party app. Even changing indexes for performance is frowned upon because of support.
Absolutely. It took an act of god, otherwise known as the Head Legal Counsel, and our corporate checkbook for our investment accounting vendor to allow us 1 minor change... To work-around a bug in the vendor's own code!
Honor Super Omnia-
Jason Miller
|
|
|
|
|
SSC Veteran
Group: General Forum Members
Last Login: Thursday, December 17, 2009 2:07 PM
Points: 206,
Visits: 393
|
|
Steve Jones - Editor (4/10/2009)
azz (4/10/2009)
Absolutely agree, that "If you can deliver a well performing, and good looking application, no one cares about the code."
But are there a lot of such applications ordered by middle and small size companies?
I think the absolute majority of applications are tested to "good-enough" state where developers assume maintenance issues.You think so? I've worked in small and medium companies, and we've rarely been allowed to touch a 3rd party app. Even changing indexes for performance is frowned upon because of support.
I work for a software company. We deal with both Oracle and SQL Server databases (fun and games, I can tell you). One time we had a client pay a consultant to tune one of our queries. They did this with something called an Oracle overlay - I never did work out exactly how they did this - that basically waited for a query with a specific signature to be used by our application, then would automatically replace it with their own tuned query.
I was amazed by how much money they spent. It had never occured to them to call us to tell us they were having a problem. When we did find out about it, we of course fixed it - as part of their support agreement. In other words, at no extra cost than what they were already paying.
Random Technical Stuff
|
|
|
|
|
SSCrazy Eights
Group: General Forum Members
Last Login: Today @ 6:35 AM
Points: 8,187,
Visits: 7,972
|
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, March 17, 2010 11:50 AM
Points: 117,
Visits: 250
|
|
I guess I'm peculiar. To my mind stored procs are for *database* logic, not application logic. Therefore I can't see a need to encrypt your sprocs since that's just obfusticating (and not very well) the design of the data--which is already complicated enough thank you, even following KISS principles.
In other words, to me sprocs are there to support integrity and not much more than that. I like having database logic in the database when the app doesn't need to mess with it, but it's all more or less mechanical logic. The real value of code lies on the application side, not the data side.
(Can you tell I'm from an app development background :))
|
|
|
|
|
SSChampion
Group: Administrators
Last Login: Today @ 3:50 AM
Points: 23,170,
Visits: 6,927
|
|
Honestly, having worked with startups, and for software vendors, there isn't a lot of IP that's worth protecting. Most of it is common procedures that are rewritten. An accounting application having IP? Come on, those are set, published rules for handling finances. They're publicly published, otherwise you couldn't implement the system.
If it is that critical and unique, you'll know if a competitor steals it and you can sue them.
If clients cause support issues, that's good, right? You charge them more if they constantly call because of "tuning" and sooner or later the guy writing the check tells the guy touching the code to stop.
|
|
|
|
|
Valued Member
Group: General Forum Members
Last Login: Tuesday, March 09, 2010 1:39 PM
Points: 72,
Visits: 129
|
|
AndyD (4/10/2009)
The quantum guys say there is no way to predict the flip of a coin. Einstein would argue there is. IFF you knew all of the forces and assumptions, you could predict the result. I interpret that as saying, we simply don't have enough information, yet.
I think it is a little more interesting than this. The Quantum Guy says the coin is both heads and tails at the same time; only when someone looks at the coin does it change from an indeterminate state to either heads or tails.
Now, how does this relate to encrypting our SQL code? hmm...
This is a little 2 sided now isn't it? Just to add a bit of Oh No's to this, we do live in a 3D world, not a 2D world. So, a coin *technically* does have a third option other than heads or tails. It also has an edge side. It just happens to be the rarest option to be hit, but still it is possible.
|
|
|
|
|
SSC Rookie
Group: General Forum Members
Last Login: Friday, March 12, 2010 12:20 PM
Points: 49,
Visits: 114
|
|
A few thoughts from a simple-minded DBA with near fatal deficiencies of caffeine at the moment.
1. Anybody that purchases an application accepts a software licensing agreement, which typically includes a clause like "you can't repackage this code and sell it." Stealing code to resell is seriously stupid and I have to believe most companies will not risk it.
2. Encrypting stored procedure code, in my experience, has been more harm than good.
|
|
|
|
|
SSCommitted
Group: General Forum Members
Last Login: Today @ 7:03 AM
Points: 1,586,
Visits: 4,460
|
|
The only time I have seen SQL Server procedure encryption used was for a vendor product.
I decrypted and looked at a few of the procedures. They appeared to have been written by very unskilled developers, so I would say in their case that encryption was used to try to hide what crap they were selling. There was certainly nothing that they had to worry about me stealing.
|
|
|
|
