A reader, July 30, 2006 - 10:02 pm UTC
Looks like John is a from SQL SERVER background :-)
DB2
john, July 31, 2006 - 11:06 am UTC
Tom, I was wondering what your opinion would be, thanks for giving your opinion. Yes, chicken and egg.
I started with DB2, then Sybase, then the MSSQL version of Sybase, then Oracle. This provides a broad perspective.
DB2
john, July 31, 2006 - 11:09 am UTC
Tom, I was wondering what your opinion would be, thanks for giving your opinion. Yes, chicken and egg.
By the way, I started with DB2, then Sybase, then the MSSQL version of Sybase, then Oracle. This provides a broad perspective. Before DB2, I would organize my baseball cards by player's name, then by year, then by team. :)
Tablespace Growth
A reader, August 02, 2006 - 1:34 pm UTC
>>indeed it would make system "not a normal
>> datafile" (which is partially is already granted, but this
>> would make it even more abnormal and subject to dynamic growth as well
Tablespaces grow. That's what tablespaces do every day. Why the concern with dynamic growth of a tablespace that has uniform extents?
August 02, 2006 - 3:52 pm UTC
datafiles can "autoextend" if and only if the DBA says so.
controlfiles, we just grow em.
technically "tablespaces" do not grow.
datafiles maybe PERMITTED to autoextend. datafiles MIGHT be allowed to grow.
A reader, August 03, 2006 - 1:17 am UTC
>>I started with DB2, then Sybase, then the MSSQL version of Sybase, then Oracle. This provides a broad perspective.
and confusion too..
August 03, 2006 - 9:20 am UTC
no, a broad perspective.
The people that have used many RDBMS's are the only ones that truly understand whether "database independence" is a laudable goal.
I started with SQL/DS, DB2, Gupta SQLbase, Ingres, Informix, Sybase sqlserver, and of course... Oracle.
Only by doing that did I clear up the confusion.
A reader, August 04, 2006 - 1:17 am UTC
Tom,
Agree with the broad prospective but one effect i have seen is people start comparing which has its advantage and disadvantage as well.
August 04, 2006 - 7:51 am UTC
and that is bad why?
To me that is a win win situation. If all they ever use is sqlserver, they might start to think that all databases have to work in such a limited fashion :)
Another "Me Too..."
djb, August 04, 2006 - 9:21 am UTC
I am very much glad that I have gotten to know DB2, M$SQL Server, and Oracle - the others not quite as intimately as Oracle, but enough to use them adequately and to know their strengths and weaknesses.
This results in very little confusion to me. I could build an application on any of these databases, but I would *never* tell a client that they could build an app that would work across all three.
Well, I take that back
You could write an API (stored procedures) in all three databases that appeared identical to the application. That *might* work
August 04, 2006 - 11:59 am UTC
Hey - that is my approach to database independance :)
From my "database independence" talk;
My approach to DB independence
o 100% stored procedures returning result sets
o Outlaw the words select, insert, update, delete, merge in the client applications
o It is faster to code the process to the wire for each DB than to figure out what mystical, magical cool trick can we come up with to implement this query in an agnostic fashion
o You get an application that performs as good as it can against each and every database faster, more reliably (remember read/write consistency!)
reply to john
A reader, August 04, 2006 - 1:15 pm UTC
if system tablespace fails???.
By control file we can start databse in mount mode, atleast and recover.
if system tablespace fails how do you recommend to recover.
A reader, August 06, 2006 - 11:44 am UTC
>>and that is bad why?
Did i mention bad anywwhere?? :-)
>>To me that is a win win situation. If all they ever use >>is sqlserver, they might start to think that all databases >>have to work in such a limited fashion :)
Funny you mentioned this reminded me of one of our projects wherein business required hot-hot replication comparison/testing was done between oracle and informix as for one of their other application Informix replication was in place and things seemed ok.
The entire application was rewritten, procedures, functions, pacakages designed as per Oracles best practices. Lots of testing was performed but eventually there were bugs with Streams had to get Oracle Support involved further adding to time, money, energy eventually business said no go for Oracle and opted for Informix :-(
Disadvantages yeah sure no cool Oracle features and plus always prefer Oracle over other rdbms.