How long does it take to become reasonably proficient in Orcle given SQL Server

Question

In applying for jobs via agents I sometimes get blocked by an agent who says do you know software package X. When I reply that I know the similar package Y they might say unless you know X I cannot put you forward.

The problem is that some of these agents don't know what they talking about, they are merely being used by their clients as a screening filter.

It would be useful to be able to say to these agents that because I know Y I can expect to become reasonably proficient in X in a given number of days/months. However not knowing X determining the required time is why I'm asking this question.

Most recently X was Oracle and Y was SQL Server.

Please can those of you who know both express an opinion on how long is required to become reasonably proficient? NB I'm not talking about becoming a DBA!

Answer 1

If you're being hired as a DBA, it will take a while to switch between databases as the management of them differs (I base this on my experience with Oracle and DB2 only).

I DON'T know SQL Server but I can imagine a Microsoft program with its nice GUI management would be vastly different to managing DB2/z, for example (although you can use the fancy DB2 LUW (Linux/UNIX/Window) tools if you're that way inclined).

If you're just cutting code to use the database, the SQL differences are minor (relatively). That shouldn't take much time at all, assuming you're already proficient with SQL.

Answer 2

I went from SQL Server to Oracle in 2001 where I went from working on a VB6/SQL Server project (as a developer) to working as an Oracle development DBA for a large J2EE project. Here are the edited highlights of my experiences and some reflections.

For development, the basic principle of SQL is not radically differnt. T-SQL is a somewhat different beast to PL/SQL so the idioms are a bit different. Most competent programmers should be able to make the jump by just tinkering around and getting some good SQL server books such as the Guru's Guide or Oracle books such as Expert one-on-one Oracle, depending on which way you're going.

I'd say for a developer a week or two to get used to another database platform will get you most of the way there. The basic principles are fairly similar (modulo differences in the architecture); really only the window dressing is different. However, if you're going to Oracle, get a copy of a third-party query tool such as TOAD as these are much, much, much better than the ones that Oracle supplies.

Agents are notoriously bad for matching specific buzzwords and I get this on a semi-regular basis (I'm a contractor). If you need to bone up on SQL Server the Developer Edition is very cheap and will install on a desktop O/S such as Windows XP. Oracle also offers Free downloads for all their supported platforms that you can use to tinker.

You might also get some mileage from asking a stackoverflow question along the lines of "What are the main idiomatic differences between PL/SQL and T-SQL".

Answer 3

I've gone the other way (Oracle first, then SQL Server). My experience is:

SQL queries - trivial differences, except in the realm of string-date conversions, which are WAY easier in Oracle.

Stored Procedures - T-SQL syntax is significantly different from PL/SQL. There is a learning curve there, but nothing insurmountable.

Database Admin - very different, but WAY easier in SQL Server. If that's part of the job description, then they might be justified in considering someone else.

Answer 4

I've done SQL Server for 10 years, but started working with Oracle about a year and a half ago. Like any database, there's no magical proficiency point - you just learn more about it the more you use it. In terms of what a developer would need to know, it shouldn't take more than a week (and even that's a bit much) for an experienced developer to get up to speed with using it. PL/SQL isn't that much different than T-SQL, although stored procs are kind of different.

Programming-wise, the Oracle data access classes are modeled on ADO.NET (we use OleDb actually - one of the side benefits is that you don't have to futz around with the OracleBlob class in order to access BLOB data), so not much learning to be done there.

I originally had my team using TOAD, because I had heard that TOAD is what you're supposed to use with Oracle (although I also heard bad things about it). We eventually got to the point where I was the only one using TOAD, and everyone else was using SqlDeveloper. Avoid TOAD.

Answer 5

I'll state my bias upfront - Oracle is far more complex than Sql Server. So it depends what you'll be asked to do. You say that this is not for a DBA position but that definition is pretty fluid. At my company, Developers are charged with designing tables, adding the correct indexes, determining partitioning.

If you say, all I'll do is code in java or c# and call packages written by a DBA or Oracle Developer, then you are safe.

But if you take all of your MSSS experience and add semi-colons to the end of your lines you'll kill your Oracle instance. Many standard practices in MSSS are anethema to Oracle. In MSSS it's recommended to have clustered indexes on most every table. In Oracle we build IOTs (Index Organized Tables) only for specific purposes. In MSSS doing DDL in T-SQL is as easy as falling off a log. In Oracle it is made difficult on purpose, it's discouraged and in fact somewhat dangerous. In MSSS you whip off #temp table like they're jelly beans, in Oracle we plan them in advance since they are permanent database objects that aren't just created in the middle of a proc when the logic gets a little tricky.

That said, would you be able to make Oracle do something? Well, yah, but the real question is will it work efficiently and scale to meet the needs of the business your agent placed you at. And that's a resounding no.

Answer 6

If all you want to do is put a bullet point on your resume to get past the agents, just add it, that will get you past the agents and give you a chance to get your foot in the door. If you are an honest type, grab Oracle XE, Read the appropriate guide at the documentation library, and spend a day or 5 throwing together a blog/address book/flickr clone/etc in your favorite language against Oracle.

As others have suggested there is some significant difference in things you would do compared to SQL Server, if you just apply what you know from SQL Server to Oracle, you'll likely kill performance.

Answer 7

I would disagree that the SQL is similar. The SQL SYNTAX is similar (to the lowest common denominator of ANSI) for basic CRUD development. But actually building packages, writing multi-table / multi step joins, bulk updates and inserts, use of the rich and powerful Oracle feature set is very different from SQL Server. This takes a different mindset and can take many years to master. However...

The purpose of the CV / resume is to get an interview.

Work with your agent to highlight your best TALENTS and BEHAVIOUR'S, not purely skills.

Skill's can be learnt and taught. A talent for, and the demonstration of, learning new skills in new environments is gold dust for an employer.

Don't try to blag it. Don't lie. You'll be found out. Use your experience gained from SQL Server to demonstrate that you can solve the problem. Show eagerness to learn, train and graft.

But, if they really want a "parachute in and start running Oracle programmer", then your stuffed!