beginner student PL/SQL to T-SQL

[JAK]

Hi,

I'm finishing up a beginning SQL class where we learned on an Oracle
database and the transition to working on SQL Server is easy. The next more
advanced course will be in PL/SQL, but I know I will be working on SQL
Server in the workplace, so my question is if I should take this course.
Will I benefit from the basic philosophies that will be covered, or will it
just make a transition for me more difficult? Will it be partly a waste of
time and money and I'd be better served getting a book and self teaching
myself? I know that in a greater sense learning something isn't necessarily
a waste, but I mean from the perspective of my goal of being able to use Sql
Server, will this course be useful?

thanks.

[Erland Sommarskog]

JAK (NO****@hotmale.com) writes:

I'm finishing up a beginning SQL class where we learned on an Oracle
database and the transition to working on SQL Server is easy. The next
more advanced course will be in PL/SQL, but I know I will be working on
SQL Server in the workplace, so my question is if I should take this
course. Will I benefit from the basic philosophies that will be covered,
or will it just make a transition for me more difficult? Will it be
partly a waste of time and money and I'd be better served getting a book
and self teaching myself? I know that in a greater sense learning
something isn't necessarily a waste, but I mean from the perspective of
my goal of being able to use Sql Server, will this course be useful?

I have no experience of Oracle, but judging from the questions I have
seen from Oracle users who have started using SQL Server, there appears
to be considerable differences. Oracle supports syntax that SQL Server
does not support and vice versa. And what may be good for performance in
Oracle may not be good in SQL Server and again vice versa.

Those who have experience of both engines might have more to add, but
my gut reaction is that if SQL Server is what you want to learn, then
try to find a course about SQL Server instead.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Dan Guzman]

I agree with Erland that you should probably find a Transact-SQL course or
book since that is what you'll be using. Much of your SQL knowledge is
applicable to both products but the differences are significant once to get
into the declarative and procedural elements of PL/SQL vs. Transact-SQL. My
observation is that PL/SQL is a much more procedural language than
Transact-SQL.

My Oracle experience is limited (mostly DBA) and I learned Transact-SQL
first. Perhaps someone who has had to make to transition from PL/SQL to
Transact-SQL can provide more insight.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"JAK" <NO****@hotmale.com> wrote in message
news:By********************@twister.rdc-kc.rr.com...

Hi,

I'm finishing up a beginning SQL class where we learned on an Oracle
database and the transition to working on SQL Server is easy. The next
more advanced course will be in PL/SQL, but I know I will be working on
SQL Server in the workplace, so my question is if I should take this
course. Will I benefit from the basic philosophies that will be covered,
or will it just make a transition for me more difficult? Will it be partly
a waste of time and money and I'd be better served getting a book and self
teaching myself? I know that in a greater sense learning something isn't
necessarily a waste, but I mean from the perspective of my goal of being
able to use Sql Server, will this course be useful?

thanks.

[DA Morgan]

Dan Guzman wrote:

I agree with Erland that you should probably find a Transact-SQL course or
book since that is what you'll be using. Much of your SQL knowledge is
applicable to both products but the differences are significant once to get
into the declarative and procedural elements of PL/SQL vs. Transact-SQL. My
observation is that PL/SQL is a much more procedural language than
Transact-SQL.

My Oracle experience is limited (mostly DBA) and I learned Transact-SQL
first. Perhaps someone who has had to make to transition from PL/SQL to
Transact-SQL can provide more insight.

Good advice. But the architecture differences are an even larger climb.
With SQL Server you can not expect Oracle's multiversioning
With SQL Server you will likely find a different behavior of NULL
and many many other significant differences between the products.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[David Rawheiser]

There is an O'Reilly SQL in a nutshell book that gives some side by side
comparions of TransactSQL, Oracle, and MySQL syntax. I have also found the
SQL Tuning book to be helpful, as it also goes over DB2, TransactSQL and
Oracle side by side.
"DA Morgan" <da******@x.washington.edu> wrote in message
news:1102127907.949800@yasure...

Dan Guzman wrote:

I agree with Erland that you should probably find a Transact-SQL course
or book since that is what you'll be using. Much of your SQL knowledge
is applicable to both products but the differences are significant once
to get into the declarative and procedural elements of PL/SQL vs.
Transact-SQL. My observation is that PL/SQL is a much more procedural
language than Transact-SQL.

My Oracle experience is limited (mostly DBA) and I learned Transact-SQL
first. Perhaps someone who has had to make to transition from PL/SQL to
Transact-SQL can provide more insight.

Good advice. But the architecture differences are an even larger climb.
With SQL Server you can not expect Oracle's multiversioning
With SQL Server you will likely find a different behavior of NULL
and many many other significant differences between the products.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[Erland Sommarskog]

DA Morgan (da******@x.washington.edu) writes:

With SQL Server you will likely find a different behavior of NULL
and many many other significant differences between the products.

Not that I know how Oracle handles NULL, but I would not expect that
many differences in that particular area. Not as long as you run with
SET ANSI_NULLS ON and SET CONCAT_NULL_YIELDS_NULL ON, and they are default
unless you are using DB-Library.

If you turn these options off, you do indeed get another behaviour, and
this behaviour was indeed the only option in SQL Server up version 6.0/6.5.
(ANSI_NULLS came with 6.5. CONCAT_NULL_YIELDS_NULL in SQL7.)

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[David Portas]

Perhaps Daniel is referring to the non-ANSI compliant treatment of NULLs in
a unique constraint/index in SQL Server. This feature is indeed different to
Oracle and other RDBMSs. Those familiar with other systems might well find
SQL Server's implementation of unique constraints strange and inconvenient
although I think other architectural and language differences would be more
significant challenges to anyone moving between the two products.

--
David Portas
SQL Server MVP
--

[DA Morgan]

Erland Sommarskog wrote:

DA Morgan (da******@x.washington.edu) writes:

With SQL Server you will likely find a different behavior of NULL
and many many other significant differences between the products.

Not that I know how Oracle handles NULL, but I would not expect that
many differences in that particular area. Not as long as you run with
SET ANSI_NULLS ON and SET CONCAT_NULL_YIELDS_NULL ON, and they are default
unless you are using DB-Library.

I wonder what percentage of SQL Server shops do that these days? It used
to be a remarkably small number because of trying to simplify the
upgrade from previous versions.

But it is nice to see ANSI compliance as the default rather than the
exception.

--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[DA Morgan]

David Portas wrote:

Perhaps Daniel is referring to the non-ANSI compliant treatment of NULLs in
a unique constraint/index in SQL Server. This feature is indeed different to
Oracle and other RDBMSs. Those familiar with other systems might well find
SQL Server's implementation of unique constraints strange and inconvenient
although I think other architectural and language differences would be more
significant challenges to anyone moving between the two products.

You are correct. And while it isn't a big thing ... it is a thing that
someone moving between the products must be aware of. By far the
biggest things are multiversioning and locking.
--
Daniel A. Morgan
University of Washington
da******@x.washington.edu
(replace 'x' with 'u' to respond)

[Erland Sommarskog]

DA Morgan (da******@x.washington.edu) writes:

Erland Sommarskog wrote:

Not that I know how Oracle handles NULL, but I would not expect that
many differences in that particular area. Not as long as you run with
SET ANSI_NULLS ON and SET CONCAT_NULL_YIELDS_NULL ON, and they are
default unless you are using DB-Library.

I wonder what percentage of SQL Server shops do that these days?

I hope they are few, but it's very embarrassing to admit, that ours is one
of them.

Our system has a history back to 1992, which could serve as some excuse. But
a major reason a shift is not easy is poor design decision that I made
about a central concept in 1996. A change there would hit at least 50
tables.

David is right that I forgot about the difference about UNIQUE constraints
a NULL. Both the Oracle way and SQL Server way has its use, but I would
really like to see a UNIQUE_WHEN_NOT_NULL_ONLY in SQL Server.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[JAK]

Thank you to everyone who threw in their opinions. Greatly appreciated!