December 22, 2003 at 3:16 am
quote:
There are 3 main reasons why I choose SS:
1. VB is really really a great programming language, but Developer 2000 is sucks. We all want to deploy some solutions right? Not just creating some database on a mambo jumbo server.
In my experience Dev2000 is a good development tool, closely intergrated with the back end database, fully supports PL/SQL whichis a superior product to TSQL and you are able to build fairly sophisticated apps relatively quickly.
2. For business intelligence, I think SQL Server is the best product so far. Oracle cannot even export a table to a text file. And client application for BI is also wider, from Office XP to VB or VC++ using ADO
Not true. What about SQLLoader? This would achieve the desired result and is simple to use, or have I missed the point?
3. You cannot easily deploy some applications for Starting Oracle DBA. In my case, I'm a solution provider. Can you imagine that you need to make sure that your client have an experienced dba, just because you cannot make some simple application for backing up database? This can do easily using sql-dmo and vb
I also think pricing is not really a problem. Sometimes I met a CEO which said that he had a money to buy any product.
Hendra
December 22, 2003 at 7:03 am
quote:
2. For business intelligence, I think SQL Server is the best product so far. Oracle cannot even export a table to a text file. And client application for BI is also wider, from Office XP to VB or VC++ using ADONot true. What about SQLLoader? This would achieve the desired result and is simple to use, or have I missed the point?
Oracle definitely has the tools for exporting tables to flat files. In SQL Server or Sybase, you can use BCP for imports and exports -- just change 'IN' to 'OUT' on the command line and it's a done deal. You can also use an ISQL or OSQL call and pipe the output into a flat file.
In Oracle (my knowledge is more or less chopped off at the knees at 8i), SQLLoader is one of the counterparts to BCP. However, it only works in one direction: going into the database. I should point out, though, that it's precisely 200 bazillion times more flexible than BCP. You can use format files in BCP to parse out columns, skip data, and so forth, but it's a primitive mechanism. The powers to manipulate the data going in, with SQLLoader, more than makes up for the fact that you can't pull the data out into a flat file using the same mechanism.
Another Oracle counterpart to BCP is Import and Export. This will not just operate on tables but on entire databases if you want, and doesn't include just data, but entire table or schema definitions. It's useful enough that, if you have the luxury of being able to shut the database down when you run backups, you can use export files as your backup utility. (It can't be used for hot backups, though, because it does not enforce data consistency.)
When you just want to put the contents of an Oracle table into a flat file, simply format the output in a SQL query, pass it to SQL*PLUS, and pipe the output to a flat file. SQL*PLUS is more or less Oracle's take on ISQL or OSQL.
I would propose a generality: Oracle is vaster, deeper, more complicated, more flexible, and probably better engineered than SQL Server, while SQL Server is easier to use in almost every possible way. Oracle can do practically anything SQL Server can do, and much more; but almost anything that can be done in SQL Server can be done with half the trouble.
I think SQL Server will ultimately win in the marketplace because ergonomics almost always beats superior engineering. For those old enough to remember the audiophile wars of the 1970s and 1980s, Oracle proponents are like the reel-to-reel purists who argued -- cogently, sanely, and in a most futile manner -- that reel-to-reel tape drives were sturdier, more reliable, sounded better, and allowed better editing than cassette drives. Cassettes, in fact, could never perform as well as reel-to-reel due to the physical limitations necessitated by slower tape speed, narrower tape, and less isolation from the motor noise. All true. But cassettes were easier to use and the public preferred them for that reason, and that was enough. So the engineers went to work and made them "good enough", and cheap enough, to win.
Edited by - Lee Dise on 12/22/2003 07:05:07 AM
December 23, 2003 at 9:55 am
quote:
...I find T-sql much easier and versitile than pl/sql...
I have gobs and gobs and gobs of experience with both Oracle and SQL Server, and I'd have to respectfully disagree with the "T-SQL is more versatile than PL/SQL" comment. The one nice thing about T-SQL is how easily it lets you return a result set (you can do this in PL/SQL, although it's harder). However, there are lots of features of PL/SQL that are flat-out missing in T-SQL.
Some examples: packages and package bodies, user-defined types that go beyond simple aliases for other system-defined types (types that can be complex data types, for example, or have user-defined behavior), and VERY importantly, structured exception handling. Some of these things will be addressed in Yukon, of course.
I'm not bad-mouthing SQL Server - I love SQL Server. But in my experience, not many people are actually qualified to speak about both platforms, and when people don't understand something, they tend to assume it's useless, complex, or inferior. But believe me, if some of these things were available in T-SQL, once people became familiar with them, they'd use them! These features are nice, useful, productive, and flexible.
Not wanting to start a flame war ... just suggesting that we should always be careful not to bad-mouth something just because we don't understand it.
Just my 0.02. Re-cloaking...
Chris
December 23, 2003 at 10:09 am
quote:
BTW, wouldn't Oracle's RAW file be the same as the file used by SQL Server? all tables in SQL Server are contained within a single file in SQL. Granted, the growth of the file may result in a non-contiguous file.
Not quite. Oracle's raw files are *not* managed by the OS at all. The question of whether or not to use raw files in Oracle is a very technical discussion that I think everybody here could understand, but I doubt anybody will take the time to write much about it - to say a little, you've got to say a lot, really!
I will say a few things. Lots of people have moved their systems to raw files, and then said they saw a performance improvement of X percent. But in has been shown that many of these people would have seen essentially the same performance improvement using OS-managed ("cooked") files ... if they had just defragged their database objects. :o(
The real issue with raw versus cooked has to do with caching. Since the OS does not manage a raw file, you don't get the OS caching to help you out. Now if you can reallocate that cache to the OS, that's great, but this is a big issue. For example, sometimes when a database server (doesn't matter if it's Oracle, SQL, or whatever) says it has incurred a physical read, it is lying. Well, not really. :o) Really, it just means that the required data was not in the DB server's cache, so the DB server had to ask the OS for it. On read-ahead scans, the OS might have already cached the data into its read cache, so that the "physical read" is really a read from the OS cache. This is very different from a read all the way from disk.
There are some things in which raw file i/o excels, and I know people who implement raw devices for Oracle and who wouldn't do anything else. In fact, I know one friend who just switched from cooked to raw files - he was a little hesitant at first, but doesn't think it's such a big deal now.
OS caching also comes into consideration with reads as opposed to writes. But like I said, I don't really want to get started ... or else there's just too much to write! But no, the short answer is that "raw file" in Oracle is not just referring to a database file in the OS, it is referring to a portion of disk managed directly by the database without OS intervention. SQL Server can do this also (or at least it could the last time I tried it!), but it's much less common in a SQL environment than it is in Oracle.
Gotta close. Hopes there's something in here worth reading!
Chris
The Database Guy
MCSE, MCDBA, OCP
Brainbench MVP for Oracle Admin
Author, exam author, trainer, and boring DBA
March 4, 2004 at 12:39 pm
In other forums, the debate still isn't dead. Here's my response to the article at: http://searchdatabase.techtarget.com/originalContent/0%2C289142%2Csid13_gci953120%2C00.html
I've worked extensively with both Oracle and SQL Server and there are things to like about both. But, to generalize, Oracle wins the "technical excellence" award while SQL Server wins the "ease of use and overall cost" award. And costs in business are like gravity in physics: at the micro level, they may be insignificant, but at the macro level, they are ultimately the most potent force.
Certainly, Ms. Lorusso should have omitted her remark that Oracle "gives you a lot more bang for your buck", because that's precisely what Oracle fails at. Oracle is for when there is no substitute for having the best-engineered, most feature-laden DBMS available, regardless of the cost. (Which, by the way, explains its popularity with government — Oracle is an easy choice only for someone who's spending someone else's money.) On the other hand, SQL Server is for database applications where some degree of power and flexibility can be traded off for gains in ergonomics and reduced costs — in other words, for all but a small percentage of applications.
How the two vendors have arrived at their current positions is a function of their core business models. Microsoft has built an empire out of providing easy-to-use software, and have simply applied this vision to their SQL Server releases. Oracle, on the other hand, is primarily a vendor of consulting services, and so they've had (until forced into it) little incentive to make their DBMS easier or cheaper to manage. Why, for example, is T.O.A.D., a non-Oracle product, the most popular GUI interface for Oracle? Because Oracle was quite happy to let customers struggle with command-line interfaces, all the more business for Oracle consultants. Ease of use almost always wins out over technical excellence, and SQL Server's ergonomic nature manifests itself in many ways: the simplicity of backing up; results sets returned from stored procedures; easy-to-use dynamic SQL capabilities; a decent management console with wizard-generated maintenance plans and DTS packages; a simple OS command-shell interface; and so on. Licensing costs are just a piece of the total cost picture; ease of use also translates to cheaper costs. Oracle may play well to the true geeks, but non-geeks such as managers and CFOs, being more interested in the bottom line, aren't impressed by the gee-whizziness of it all. "Powerful but cumbersome/Impressive but expensive" is how Oracle's epitaph may someday read.
When all else fails, the Oracle claque touts their champion's ability to run on numerous platforms, whereas SQL Server is consigned to the Windows dungeon. Once upon a time, this ballyhooed distinction may have actually mattered -- that is, way back when a computer with any power at all cost both arms, both legs, and a kidney. But this has all been rendered trivial by steeply reduced hardware prices. Today, you buy server boxes for the DBMS, not the other way around — heck, buy two, they're cheap.
What should worry Oracle most of all is that Microsoft has genuinely improved SQL Server in quantum jumps with each release. As the Beatles might have crooned, I have to admit it's getting better all the time.
To the die-hard Oracle devotees: You win the techie debate, no question. PL/SQL is more powerful, locking is better, data storage options are more flexible, and so on. All true, but if I'm right, none of it matters. Prepare to lose even more market share.
March 10, 2004 at 9:07 am
I would like to weigh in with this thread as well. I am relatively new to the SS environment but have had some experience with Oracle. In my view Oracle is targeted towards the higher end requirements and the cost is relative to that. I have a friend who works for Oracle (good friend, gives me the straight scoop) and he agrees that their is more technical support required. I like SS for its ease of use. I am a littel concerned about security with MS being the focus of so many attacks however it has not been a factor to me. My $.02.
April 30, 2004 at 2:35 pm
This post is a year old, but I'm still going to respond, as I think the points I want to make are still relevant.
> Scorpion_66: I have worked extensively in both [SQL Server and Oracle], and to date, have found no functions that cannot be duplicated in one or the other.
Maybe I misunderstand what you're saying here, but if I do understand you correctly, I would like to respectfully register my disagreement. True, with most tasks, you could get them done in either environment, with one or the other edging in front due to better ergonomics. But some things one can do just can't be done by the other.
In SQL Server, you can retrieve a results set by calling a stored procedure. In Oracle, no can do, you need to use a SELECT statement.
In SQL Server, you can mix and match collations. Don't know why you'd want to, but you can if you do. My knowledge of Oracle is dated, but as I recall, code is case-insensitive and data is case-insensitive, and that's that.
In SQL Server, you can run OS commands on the server box. Last time I checked, you couldn't do this in Oracle. I heard rumors that they had some kind of a Java engine now that enabled this, but I don't know. Anyone?
In Oracle, no matter what the error is, you can trap it with an EXCEPTION clause and keep the error goons from climbing back all the way to the OS. In SQL Server, the DBMS, and not the programmer, determines which errors can allow processing to proceed, and which errors slam the door shut on everything.
In Oracle, you can span a row across pages. Not in SQL Server, where the pagesize is a handy friendly one-size-fits-all and one row, one page, and that's that.
In Oracle, you can have a true 'before' trigger, not that sappy crappy half-hearted 'instead of' nonsense. You can also run trigger logic at the row level as well as the statement level. And you can always identify the row being updated, even if the primary key itself is being updated. Which it shouldn't be, I know, but sometimes it is.
I like them both, and can't really pick a favorite. Usually, when I need convenience, I'm thankful that I'm doing SQL Server these days, and when I need power and precision, I find myself missing Oracle.
Viewing 7 posts - 91 through 96 (of 96 total)
You must be logged in to reply to this topic. Login to reply