Re: Can I remove a table from the recycle bin?

On Apr 9, 2:01 pm, "EscVector" <J..._at_webthere.com> wrote:
> On Apr 9, 2:35 pm, "joel garry" <joel-ga..._at_home.com> wrote:
>
>
>
>
>
> > On Apr 9, 6:36 am, Mladen Gogala <mgogala.SPAM_ME...._at_verizon.net>
> > wrote:
>
> > > On Mon, 09 Apr 2007 06:19:22 -0700, EscVector wrote:
> > > > That said, the environments are Alpha/Prototype environments, so giving
> > > > access and helping out is just good PR especially when some of the
> > > > worlds top java devs don't believe they need DBAs. They're database
> > > > independent....
>
> > > I've recently encountered an idiot giving a horrible advice how to make
> > > Oracle behave like SQL Server. I've fought people trying to create
> > > "database independent" applications all my life. Different databases have
> > > different locking strategies, different way of dealing with connections
> > > and different optimizers, not to mention different security mechanisms.
> > > In my life, I've dealt with Oracle, PgSQL, CICS/DL1 and Informix, not
> > > much but enough to know that all the databases are different, they're all
> > > individuals, as stated in the "Life of Brian". When the vendor tells me
> > > that his application is portable, I usually ask for the way that this
> > > portability is achieved. If the answer is "Hibernate and WebLogic", I
> > > advise the CIO against the application and explain him the risks. The
> > > only type of database independence I have nothing against is so called
> > > ifdef portability, named after the #ifdef pre-processor in CPP. I have
> > > never seen a database independent application beat database specific
> > > application on a performance benchmark.
>
> > Actually, I have. The performance benchmark measured being
> > productivity.
>
> > I can pretty much guarantee you can't write an ERP package with all of
> > the bells and whistles faster and cheaper than I can bring up a
> > "database independent" COTS. Vaporware fails any performance
> > benchmark, of course.
>
> > I agree with you on the technical issues, but the users don't give a
> > flying squirrels tail about that. They care about whether the
> > application can fit into their business. If the vendor provides
> > easily modified source code and costs a tenth of Oracle apps, there's
> > some strong motivation there too.
>
> > Another thing I've seen that isn't just playing with semantics: Apps
> > custom built on 9iAS slower than COTS built with OCI. You may recall
> > before 10g the typical way to configure involved having the database
> > separate from the, say, Portal (so you can say WOW! n-tier!), with a
> > bunch of synonyms and network access necessary to actually get any
> > data. Meanwhile, the n-tier COTS would typically be built with the
> > broker and db tiers on the same box, again with OCI to get to the db,
> > just way faster. I've been quite surprised at times at how well
> > certain db independent apps actually perform - the translation of fair
> > and proper benchmarks to the real world is problematic. Of course,
> > I'm working with OLTP apps, I can certainly see how newfangled things
> > beyond O7 could use newer features that would make a difference. On
> > the other hand, I'm also watching someone install a SQL-Server based
> > BI that sucks from the O db, because all the Oracle BI stuff is
> > currently in, umm, transition (and is still an order of magnitude more
> > expensive - or more). He was impressed by Mark Rittman's blog when I
> > sent him a link, though.
>
> > Of course, this means I wind up doing stupid things like implementing
> > a custom security system on top of logins that are hardly different
> > than keeping the password the same as the username, but there you go.
>
> > jg
> > --
> > @home.com is bogus.
> > "You do have a really nice ass, but, you know how the camera adds 10
> > pounds, and well, you had like 5 cameras on you... Ow!" - heard on
> > radio.
>
> But OCI is not database independent. The independence I'm talking
> about is passing ANSI SQL

Well, the particular product I'm working on has a 4GL, which picks the code path it uses based on which db engine is being used. ANSI SQL and java aren't the only ways to database independence. If you have separate code paths, you don't have to use lowest common denominator code, theoretically anyways (although practice can't always keep up with theory).

Can't say as I recommend the 4GL paradigm, it's just one that has been out there a while.

jg

--
@home.com is bogus.
http://www.theregister.co.uk/2007/04/09/shockley_fruit_closed/