Sie sind auf Seite 1von 3

oracle can work in both windows and unix but SQL server is only windows security wise oracle

cost wise -sql server

Oracle and SQL Server have different extensions of SQL. Oracle has PL/SQL, while SQL Server has Transact-SQL (T-SQL). That means that while SQL (SELECT, INSERT, UPDATE, DELETE) is similar on a basic level, the syntax diverges quickly depending on what you are trying to do. When I work with T-SQL decision structure/control of flow, I believe it to be less accommodating than PL/SQL - CASE is an expression in T-SQL so it can't be used for control of flow while that's not the case in Oracle. Another irritation I have with T-SQL is that if you want to more than one operation within an IF branch - the entire branch must be contained in a BEGIN END block. Oracle doesn't care, but you have to define the END IF. Data types are similar, but Oracle doesn't descriminate between integer/decimal types - it's all NUMBER with the option to specify the degree of precision. Date functions in SQL Server are more accommodating. Both being popular products, it's easy to google for functionality equivalent in one for the other. Doesn't mean it will exist, but someone has probably posted the workaround.

The FIRST biggest difference: Transaction control. In Oracle EVERYTHING is a transaction and it is not permanent until you COMMIT. In SQL Server, there is (by default) no transaction control. An error half way through a stored procedure WILL NOT ROLLBACK the DDL in previous steps. Obviously, if you wrap the TSQL DML in BEGIN TRANSACTION and COMMIT then it will roll back but this is rare in SQL Server code I've seen. The SECOND biggest difference: MVCC. In SQL Server and Oracle is different. SQL Server will allow dirty reads, and writes can block reads in MS SQL (Again, it's configurable but the default in SQL Server is for performance and not read consistency, unlike Oracle where read consistency is default and unbendable. Also consider: When you setup an Oracle server, you tend to have one database with many "users/schemas", and tablespaces that are shared by all your users. SQL Server has separate databases that do not share disk files.

SQL Server uses "logins" to give you access to the SQL Server instance and each database has "users" that map to a login to get individual access to the tables and views etc. Typically, all the objects in a database are owned by dbo.

TSQL is similar to PL/SQL, but (in my opinion) less powerful. You may need to simplify your SQL to get it to work as well as you'd expect in Oracle. The SQL Server Management Studio (2008 SP1) is fantastic! If you like Oracle, all the "getting under the hood" and "explain plan optimisation" then this training and experience will work well for you against guy's who just code straight SQL Server TSQL and expect the server to perform fast by magic. SQL Server does not have packages. This might start off as a bonus (PL/SQL packages can be a PITA) but eventually you'll start to get a big nest of similarly named stored procedures in the database and you'll wish there was a way you could organise and group then them better.

Final tip, always play to your strengths. Admit that you don't have much SQL Server experience but highlight that you know the principles of how an RDBMS works, how to development a data driven application and how you design in performance from the start, etc.

Oracle strengths: a better transaction system packages Cursor For Loops anchored declarations (variables declared as table.column%type) initial values for variable declarations %rowtype variables much lower overhead for cursors BEFORE triggers FOR EACH ROW triggers While sequences require either discipline or before each row triggers, they are more flexible than SQL Server identity columns. SQL Server Strengths: Transact-SQL is just one language, so you don't have to worry about what's SQL, what's SQL*PLUS and what's PL/SQL. Because T-SQL is just one language, the T-SQL collections actually work decently with SQL. You can join T-SQL table variables to real tables. This tends to mean, while PL/SQL is more powerful for procedural programming, you just don't need to do procedural programming in TSQL. If you perform a select query with no target, the results are automatically returned to the client. For production code, this means you don't need to declare and pass sys_refcursor. For ad-hoc research work, this means you can easily make scripts that perform lookups and display multiple recordsets.

SQL Server Management Studio is much better than SQL*Plus or SQL Developer. Because it just displays any returned recordsets, data retrieval procedures are very easy to test. easier client connectivity setup (nothing as bad as tnsnames) less confusion about what drivers to use, apart from JDBC Declare a column "Int Identity Not Null Primary Key" and then you can forget about it. Every variable name starts with an "@" sigil, which looks terrible, but prevents name collisions between variables and columns. The case you declared a table or column with will be remembered, but it's not case sensitive, and you aren't limited to 30 characters. Crystal Reports can call SQL Server stored procedures, where you tend to be forced into a view with Oracle.