Oracle Has More Flaws Than SQL Server 229
jcatcw writes, "Next Generation Security Software Ltd. of Surrey, England, compared bugs in Oracle and SQL Server that were reported and fixed between December 2000 and November 2006. The tally: Oracle had 233; MS SQL had 59. The products compared were Oracle 8, 9, and 10g; SQL Server 7, 2000 and 2005. From the article: '[The head of the survey said,] "The results show that the reputation that Microsoft SQL Server had back in 2002 for relatively poor security is no longer deserved."' Oracle's response: 'Measuring security is a very complex process, and customers must take a number of factors into consideration — including use-case scenarios, default configurations, as well as vulnerability remediation and disclosure policies and practices.'"
but ... (Score:1, Interesting)
Reported AND fixed (Score:5, Interesting)
Reported and fixed means that the company which doesn't fix bugs looks more secure. Not that I'm implying that MS is worse than Oracle on this, mind you. I just wanted to point out that this metric has loads of potential flaws.
If MS SQL Server only had one vulnerability (Score:2, Interesting)
More FUD (Score:3, Interesting)
Who cares?
Re:Summary title is vague (Score:1, Interesting)
YES! I'm tired of ceding parts of the English language to Microsoft. How did Microsoft end up owning the word Windows, forcing Lindows and wxWindows to be renamed, when X-Windows has been around so long? If Microsoft can't be bothered with coming up with unique names for its products, don't let them take over common words by dropping the "Microsoft" from the name.
In Oracle's (Pseudo) Defence... (Score:4, Interesting)
Re:Does this suprise anyome? (Score:3, Interesting)
Oracle needs a through refactoring. They'll either do it under their own steam or the market will do it for them.
Re:Does this suprise anyome? (Score:3, Interesting)
The "flaws" I've experienced with SQL Server either made my server crash or corrupted my databases to all hell. I've never had an Oracle server (or any other vendor's product) corrupt my tables, thank you very much. I think MS brought this "feature" over from their Jet / Access engine.
If you compare the severity of these flaws, not their category, I think you'll find that SQL Server has many more *unrecoverable* flaws. That's been my experience with every version since 7.0.
Re:translation (Score:2, Interesting)
If you offer a ton of additional features... (Score:3, Interesting)
...then it stands to reason that you will have a ton of additional bugs.
This argument in no way excuses Oracle for their timely patch cycle (or lack thereof), but may explain the higher number of patches.
I haven't looked at the Sybase/SQL Server family for awhile, but I assume that it still doesn't offer anything like Flashback, LogMiner, richer indexing, direct LGWR connection to DataGuard, resumable transactions, or even basic multiversioning.
Re:Summary title is vague (Score:4, Interesting)
Re:translation (Score:4, Interesting)
If that is the case, oracle's mgmt tools heavy reliance not only on java, but *specific* version of java
w/o updates I'm aware of, would explain a lot.
off the top of my head:
Input fields that don't register the first key press, menu item that don't redraw for some reason, refreshes and connection errors that require exit/relaunch.
Other frustrations like that, that aren't oracle's "fault" per se, but don't help the spec/check sheet for bugs.
Didn't RTFA (yet), but are those counted as bugs? I'd like to know.
Re:translation (Score:3, Interesting)
The bottom line is of course "Am I more likely to have a security problem while using Database A or while using Database B?" Perhaps some studies ought to be done to determine the relationship between measurable things like number of bugs, time to patch, etc, and various user's perception (or perhaps security pros' perception) of how many security problems were actually had. Then we'd be able to actually assign some semblance of meaning to these currently utterly meaningless studies of "number of bugs". I don't think that even knowing time to patch or severity of potential exploit or such things would really tell anyone much about the bottom line as I have described it, at least not unless some real investigation of the relationship is done first.
And of course this doesn't just apply to databases, but to any sort of software which has any security consequences at all (which winds up being essentially all software).
Re:translation (Score:3, Interesting)
My biggest surprise here is that they only found/or reviewed less than a couple hundred bugs each. Strange, because I am sure that I can find more bugs than that in 4 days work on each product. This research can't be all that deep. I must be missing something???
Any normal QA person would be able to find that many bugs in 10 or 20 days.
Re:Features? -- easy to defend your answer! (Score:1, Interesting)
Oracle has Oracle Spatial. PostgreSQL has PostGIS.
With SQL Server, you need to buy an expensive third party package (like ESRI ArcSDE or MapInfo Spatial) that does not work as well as PostGIS because ESRI doesn't have the hooks they need deep enough into the database to add spatial index types.
The PostgreSQL/PostGIS GIST index types are very well suited to geospatial data. The R-trees that I believe Oracle uses are good as well. Does SQL Server have R-tree indexes?
You can say the same about extension languages - SQL Server's fine if you want to extend it in their dialect of SQL (I hear their C# stored procedures exist but are recommended against) - while with Oracle you have their (very powerful) dialect of SQL and Java - but with PostgreSQL you have Java, Perl, C#, R (a SPSS clone), Ruby, etc.
Other pretty basic SQL Server features end up being hidden in their $40000/CPU versions of their product; so you won't see them in even moderately high volume products like Cisco's switches like postgresql is - or really large databases like GlobeXplorer's (http://postgis.refractions.net/documentation/cas
So basically, yes, it's not hard to defend the claim that even the most expensive SQL Servers with the most expensive third-party-ad-ons are pretty limited compared to PostgreSQL.