February 22, 2011 at 3:01 pm
Hey Threadizens, I'm trying to help someone with a MAXDOP issue here. I fear I'm digging for China as I haven't really done the research on this recently nor well, and I'd like some other eyes on it before I take this guy for a ride.
If someone can spare some time I'd appreciate it.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
February 22, 2011 at 3:25 pm
SQLkiwi (2/22/2011)
Steve Jones - SSC Editor (2/22/2011)
On a similar debating note, does anyone know of code in SQL Server that's worth protecting with CLR, obfuscation, or any hassles of encrypting? Not data, but code?In my limited experience, the only time I have seen attempts at obfuscation have been to hide the poor quality of the code. Seriously.
Actually there used to be obfuscated code contests (and probably still are); in many languages it's possible to write something (in 60 lines or less was the usual rule) that look as if it it does nothing like what it atually does. I've seen plenty of obfuscated code from those (and often been unable to work out what the code does without actually running it). There are also languages designed with the deliberate intention that it will be extremely difficult to understand anything written in them (contrary to appearances, C++ wasn't one of those), and all the code I've seen in those was pretty dark!
But I guess that's not the sort of obfuscation Steve meant.
So far as code obfuscated with an obfuscation tool is concerned I have seen some and there was no good reason to obfuscate it (concealing the author's incompetence doesn't count as a good reason) - in fact I'm with Paul on that.
Tom
February 23, 2011 at 4:29 am
LutzM (2/22/2011)
Jeff Moden (2/21/2011)
...I dun no... DE-troit boy goin ta ohia mur dan wonce in da sames yer mite git da kin folk resluss en tha lak.
Here's my ESL approach:
Detroit boy going to Ohio more than once in the same year might get the kind folk restless on the lake.
Wow. What does it say about me that I understood this.
FYI: The last few words are "restless and the like," (meaning, "restless, uncomfortable, worried, etc.") not "restless on the lake."
February 23, 2011 at 4:31 am
Steve Jones - SSC Editor (2/22/2011)
On a similar debating note, does anyone know of code in SQL Server that's worth protecting with CLR, obfuscation, or any hassles of encrypting? Not data, but code?
The only situations I see this happening in are when some new proprietary method for dealing with the data has been developed and the business doesn't want anyone (who hasn't developed these business rules, methods, procedures) walking away with their proprietary business process.
February 23, 2011 at 7:32 am
Brandie Tarvin (2/23/2011)
LutzM (2/22/2011)
Jeff Moden (2/21/2011)
...I dun no... DE-troit boy goin ta ohia mur dan wonce in da sames yer mite git da kin folk resluss en tha lak.
Here's my ESL approach:
Detroit boy going to Ohio more than once in the same year might get the kind folk restless on the lake.
Wow. What does it say about me that I understood this.
FYI: The last few words are "restless and the like," (meaning, "restless, uncomfortable, worried, etc.") not "restless on the lake."
*banjo music echoing from the hills*
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
February 23, 2011 at 8:01 am
Brandie Tarvin (2/23/2011)
LutzM (2/22/2011)
Jeff Moden (2/21/2011)
...I dun no... DE-troit boy goin ta ohia mur dan wonce in da sames yer mite git da kin folk resluss en tha lak.
Here's my ESL approach:
Detroit boy going to Ohio more than once in the same year might get the kind folk restless on the lake.
Wow. What does it say about me that I understood this.
FYI: The last few words are "restless and the like," (meaning, "restless, uncomfortable, worried, etc.") not "restless on the lake."
Don't know if this is correct, but I interpreted "da kin folk" to be "the kin folk", aka "the family".
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
February 23, 2011 at 8:53 am
WayneS (2/23/2011)
Brandie Tarvin (2/23/2011)
LutzM (2/22/2011)
Jeff Moden (2/21/2011)
...I dun no... DE-troit boy goin ta ohia mur dan wonce in da sames yer mite git da kin folk resluss en tha lak.
Here's my ESL approach:
Detroit boy going to Ohio more than once in the same year might get the kind folk restless on the lake.
Wow. What does it say about me that I understood this.
FYI: The last few words are "restless and the like," (meaning, "restless, uncomfortable, worried, etc.") not "restless on the lake."
Don't know if this is correct, but I interpreted "da kin folk" to be "the kin folk", aka "the family".
You are correct, Sir.
February 23, 2011 at 8:57 am
Brandie Tarvin (2/23/2011)
WayneS (2/23/2011)
Brandie Tarvin (2/23/2011)
LutzM (2/22/2011)
Jeff Moden (2/21/2011)
...I dun no... DE-troit boy goin ta ohia mur dan wonce in da sames yer mite git da kin folk resluss en tha lak.
Here's my ESL approach:
Detroit boy going to Ohio more than once in the same year might get the kind folk restless on the lake.
Wow. What does it say about me that I understood this.
FYI: The last few words are "restless and the like," (meaning, "restless, uncomfortable, worried, etc.") not "restless on the lake."
Don't know if this is correct, but I interpreted "da kin folk" to be "the kin folk", aka "the family".
You are correct, Sir.
I prefer Lutz's translation. Not because it's correct, but because of the idea of upsetting a group of nice people who are out boating gave me a bit of a chuckle.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 23, 2011 at 9:38 am
GSquared (2/23/2011)
Brandie Tarvin (2/23/2011)
WayneS (2/23/2011)
Brandie Tarvin (2/23/2011)
LutzM (2/22/2011)
Jeff Moden (2/21/2011)
...I dun no... DE-troit boy goin ta ohia mur dan wonce in da sames yer mite git da kin folk resluss en tha lak.
Here's my ESL approach:
Detroit boy going to Ohio more than once in the same year might get the kind folk restless on the lake.
Wow. What does it say about me that I understood this.
FYI: The last few words are "restless and the like," (meaning, "restless, uncomfortable, worried, etc.") not "restless on the lake."
At the time Jeff came to Cleveland that would have to have been an ice boat
Don't know if this is correct, but I interpreted "da kin folk" to be "the kin folk", aka "the family".
You are correct, Sir.
I prefer Lutz's translation. Not because it's correct, but because of the idea of upsetting a group of nice people who are out boating gave me a bit of a chuckle.
If it was a boat it would have to have been an ice boat
February 23, 2011 at 10:04 am
bitbucket-25253 (2/23/2011)
GSquared (2/23/2011)
Brandie Tarvin (2/23/2011)
WayneS (2/23/2011)
Brandie Tarvin (2/23/2011)
LutzM (2/22/2011)
Jeff Moden (2/21/2011)
...I dun no... DE-troit boy goin ta ohia mur dan wonce in da sames yer mite git da kin folk resluss en tha lak.
Here's my ESL approach:
Detroit boy going to Ohio more than once in the same year might get the kind folk restless on the lake.
Wow. What does it say about me that I understood this.
FYI: The last few words are "restless and the like," (meaning, "restless, uncomfortable, worried, etc.") not "restless on the lake."
At the time Jeff came to Cleveland that would have to have been an ice boat
Don't know if this is correct, but I interpreted "da kin folk" to be "the kin folk", aka "the family".
You are correct, Sir.
I prefer Lutz's translation. Not because it's correct, but because of the idea of upsetting a group of nice people who are out boating gave me a bit of a chuckle.
If it was a boat it would have to have been an ice boat
"on the lake" could mean a house on the lakeshore, but I read it as "on a boat". If the lake is frozen, they could of course be "on the lake" without any boat at all.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 23, 2011 at 11:39 am
GSquared (2/22/2011)
What I was asking was: Did Steve mean the question to be about legitimately protecting code, or did he mean to ask about people actually using completely ineffective means of protecting things? Two very different takes on the same question.
I mean legitimately protecting code and is it worth doing in the db layer. If you have an IP investment in your software, I'd think most of that would really be in the client code, which can be reverse engineered, of course. I am wondering what you might put in the db layer that's worth protecting?
It seems almost by definition of how you'd need to query data that any "algorithm" you might build into T-SQL could easily be deduced.
February 23, 2011 at 12:39 pm
Steve Jones - SSC Editor (2/23/2011)
GSquared (2/22/2011)
What I was asking was: Did Steve mean the question to be about legitimately protecting code, or did he mean to ask about people actually using completely ineffective means of protecting things? Two very different takes on the same question.I mean legitimately protecting code and is it worth doing in the db layer. If you have an IP investment in your software, I'd think most of that would really be in the client code, which can be reverse engineered, of course. I am wondering what you might put in the db layer that's worth protecting?
It seems almost by definition of how you'd need to query data that any "algorithm" you might build into T-SQL could easily be deduced.
I don't know about that. Simple procs, yes, complex business logic, not so much.
My first DBA job was with a marketing company. The systems we built, where 90% of the business logic was in table design, UDFs, and procs, allowed a 25-person company to successfully compete with a 200-person company in the same industry. The code outside the databases was commodity, for the most part. Nothing of any real value to any competitor. Nothing that couldn't be reverse engineered by simply taking a reasonably good look at the interfaces and using them for a few minutes.
Had the competitor obtained a copy of the database, even one without the customer data in it, it would have been a huge advantage for them.
They had the same business needs, but their devs and DBA hadn't arrived at anywhere near the system efficiency we had.
When the company I worked for went out of business (because of some very poor marketing decisions), the competitor bought the databases and their code for a pretty good sum, during the bankruptcy. Then they hired me to implement it into their business.
Took a couple of weeks to triple their production bandwidth in a whole department, just by integrating one of the database solutions I'd built for the prior company. Took a bit longer to more than double the speed of order processing. The steps after that cut per-order cost by a significant percentage by eliminating whole categories of waste and double-work.
They had more experienced personnel, more experienced developers, and better managers, and had been in the industry for at least a decade longer, but reverse-engineering an algorithm or two out of a few procs wouldn't have solved anything significant for them. They needed all of it to really benefit from it. And they needed not just the code, but the documentation as well, to get any benefit from it at all.
So, in that situation, the steps taken to secure that IP in that set of databases, was worth literally millions of dollars per year in revenue. Definitely worth securing. The inner workings of the code were WAY too complex to analyze input and output and reverse-engineer the path from one to the other.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 23, 2011 at 3:14 pm
Sorry to keep making calls for my blog, but this one is about Women in Technology. I'd really like y'all to take a look at it and comment away, if you wouldn't mind.
February 23, 2011 at 7:55 pm
Steve Jones - SSC Editor (2/23/2011)
GSquared (2/22/2011)
What I was asking was: Did Steve mean the question to be about legitimately protecting code, or did he mean to ask about people actually using completely ineffective means of protecting things? Two very different takes on the same question.I mean legitimately protecting code and is it worth doing in the db layer. If you have an IP investment in your software, I'd think most of that would really be in the client code, which can be reverse engineered, of course. I am wondering what you might put in the db layer that's worth protecting?
It seems almost by definition of how you'd need to query data that any "algorithm" you might build into T-SQL could easily be deduced.
Don't agree. There can be a very large investment in code and schema design in a database, so there is plenty worth protecting.
But provided the enemy doesn't have admin access and can't run profiler that can all (in theory anyway) be concealed without obfuscation, and even if the enemy has the source of the client code that just tells him about some of the interfaces of the black box. If he can deduce the data structures and algorithms from playing at those interfaces to see what happens you haven't got anything much in there (I know that many people advocate not puting anything much in the database; but basically I think those people are crazy). I don't see much point in attempting obfuscation if the enemy can see inside the database.
Tom
February 24, 2011 at 4:16 am
Tom.Thomson (2/23/2011)
I don't see much point in attempting obfuscation if the enemy can see inside the database.
That's a good point, Tom. But is "enemy" a good word choice here? Do businesses really see this as a war?
Viewing 15 posts - 24,256 through 24,270 (of 66,738 total)
You must be logged in to reply to this topic. Login to reply