Showing posts with label Databases. Show all posts
Showing posts with label Databases. Show all posts

Monday, January 28, 2008

The best Database Server

Moving stuff to Oracle from SQL Server. Well, Oracle certainly has come a long way to nowhere. It is still cumbersome to use and in it's own little world. But at least Oracle would be happy because they think that they are the more robust database.

In today's world where people really don't have mass amounts of data, Oracle's supposed egde doesn't make much of a bargaining chip. SQL Server does more than fine for all the corporate needs. Most companies aren't in business long enough to have a database big enough to really cause problems. Others have backups and rollovers and database syncs and server farms to solve problems. And many really huge ones still use mainframes. So what is the point of Oracle? It has it's place but they're making it hard to let other people use the database system. By making simple things hard, they exclude a big group of people.

The TNS thing alone is a big nuisance. Any client that needs to connect must use TNS names. There's a cases where people have been able to make connections without using the TNS names entries and the oracle client. Mostly, the oracle client needs to be isntalled with all of it's MB (disk space) eating additions. Plus it needs to be configured. In a world where 2000 workstations need to do database stuff, it's not always easy to deploy the Oracle client and configure it remotely. Not to mention updates are not very easy to implement.

On the other hand if you want to hire someone who can write instructions to Oracle in bad english, and use PL/SQL instead of plain SQL or T-SQL then you'd want Oracle. If you want to have snobby DBAs who can hold up everything to their schedule, you really want Oracle.

Tuesday, January 22, 2008

SQL Server vs. Oracle

So we wrote some pretty involved code for a project. It was using SQL Server 2000. There was all kinds of .NET controls that use the SQLDataSource component. All of a sudden at the last minute the requirement was changed to use Oracle 9.2. Now you would think simply changing the connection string would good to set all things pointing to Oracle.

Well! You'd be wrong!

The SQLDataSource component need to be specifically told the client type is Sql.OracleClient and it won't just read the correct configuration from the config file.

So all the code needs to re-examined. All test cases need to re-run.

Not to mention all schemas need to be regenerated in Oracle. And of course, Oracle doesn't do anything the easy or nice way. So that'll be who knows how long spent trying to fix this.

SQL Server 2000/5 have it so much better. Any thougths?