Re: Oracle #1? Then why are these still missing...

No need to apologize - I enjoyed your response immensely. Presenting a legitmate list of desired enhancements is one thing, but whining about the lack of (mostly) unrelated functionality is something else.

Kenneth C Stahl wrote:

> Paul wrote:
>
> > When are Oracle going to listen to their users and start to implement
> > fundamental requirements which already exist in other RDBMSs. I am
> > sick and tired with Oracle Support saying, "it's a bug, and there are
> > no known fixes", "it might be in the next version, but then again it
> > might not", "you want me to put in an enhancement request..might take
> > 3-5 years though", "it has been asked for before, but we have no plans
> > to do it", "you'll have to write a work around", "speak to your
> > account manager, he might be able to get it put in, if you are a
> > really big corporate customer"
> >
> > Listen Mr Ellison and your crew, Oracle is still missing basic
> > functionality. So let me suggest something, instead of poncing around
> > with new Oracle technologies like Java, why don't you sort out the
> > basics first.
> >
> > Oh and before you read this list and reply: "But this is easy to
> > implement" or "I've written something to do this anyway" let me
> > explain....so have I had to write / find workarounds for all these.
> > But at the end of the day it shouldn't need to happen, it should have
> > been in Oracle years ago. They're fundamental.
> >
>
> If you don't like using Oracle then go try your luck with Sybase or
> Informix. I've been using the Oracle RDBMS for years now and am quite
> satisfied with it.
>
> >
> > 1. A "RANDOM" function.
> > 2. A RANDOMIZE function to accompany "RANDOM" function.
>
> Neither of these are essential to the concept of a relational database. In
> fact, theoretically they would be diametrically opposed to the concept of
> "organized" data. If you need to perform randomization then you need to do
> it programatically rather than blaming the database for not providing that
> functionality.
>
> >
> > 3. A native "DIV" function. Oracle has MOD an integer remainder
> > function but not an integer division function. DIV and MOD always
> > appear together, but not in Oracle.
>
> Again, Oracle doesn't need to provide such functionality. You've been
> working with COBOL too long.
>
> >
> > 4. Bitwise boolean functions OR, XOR, AND, NOT (not the same as
> > boolean operators). Ever tried to write a decent encryption algorithm
> > in Oracle without these? Ever tried to mask an integer to see if a
> > bit is set? Just overload the existing boolean operators to allow
> > Bitwise boolean opeartions.
>
> What on earth do these have to do with Oracle? What were you smoking when
> you came up with this nonsense. The Oracle RDBMS provides a means of
> storing data and extracting data. Except for data columns like RAW (which
> can only be stored or extracted), Oracle has no concept of binary data.
> That only exists outside of Oracle. If you want to do this stuff then
> learn C.
>
> >
> > 5. TO_HEX function. Are they stupid or what?
>
> You mean you don't know how to do this yourself? I learned this 20 years
> ago.
>
> >
> > 6. TO_BASE function which can handle bases up to 64.
>
> This too.
>
> >
> > 7. A variant of REPLACE that only replaces the first instance of
> > search_string found. Come on Oracle simply overload it and add another
> > parameter Max_Replaces (Max_Replaces > 0).
>
> Have you ever heard of instr(). Duh!!
>
> >
> > 8. Alter Table RENAME COLUMN .... How bloody obvious is this? How
> > many times do you need to be asked? OK you have constraints to
> > consider but they know this. We don't like using the data-dictionary
> > hack.
>
> Why didn't you name it correctly in the first place? Those of us who are
> EXPERIENCED with Oracle know a dozen ways around this problem.
>
> >
> > 9. Constraint fk_MyForeignKey References MyOtherTable (MyPKField) ON
> > UPDATE CASCASE. Is Oracle the only RDBMS that doesn't have a native
> > on update cascade?
>
> Have you ever heard of programatic solutions? The RDBMS isn't there to
> solve your MIS problems - it provides a means of storing data so that you
> can retrieve it in a relational way. Learn programming and you'll solve
> these problems.
>
> >
> > 10. Constraint fk_MyForeignKey References MyOtherTable (MyPKField) ON
> > DELETE SET NULL. Another Oracle gotcha. It is basic referential
> > principles. Every single DB design case tool has this but oh no not
> > Oracle, it is far too obvious for them.
>
> How many of the other RDBMSs have decode()? How many of them have the
> equivalent of pl/sql? You've been reading too many database weenie theory
> books lately. But then you are probably the type that would argue with
> Donald Knuth because he has never developed a compiler consistant with the
> books her wrote.
>
> >
> > 11. The ability to find out who is the locker when using pessimistic
> > locking (e.g. when "select 1 from MYTable where MyPrimaryKey = MyValue
> > for update nowait" fails because someone else has already
> > pessimistically locked it.)
>
> Have you ever heard of security? It is none of your business who has a
> lock on a table. If you want a lock then you need to wait for it. What are
> you going to do? Kill the pid of the process that has the lock? Gimme a
> break. That is hacker mentality.
>
> >
> > 12 The ability to move the cursor back to correct typos in SQL plus.
> > Why is it still not possible? Sometimes we haven't gone into another
> > editor and we accidentally make a typo at the end of a 200 character
> > line, so Oracle makes us retype the whole lot again. SQL Plus is and
> > always has been an extremely poor interface.
>
> Why don't you learn how to type accurately? Alternatively, why don't you
> RTFM - there are plenty of editing capabilities in sqlplus and it also
> allows you to use the OS native editor. sqlplus is ONLY a tool. If you
> don't like the tool then write your own. What? You don't know how to write
> your own version of sqlplus? I wrote a replacement years ago to serve my
> own particular needs and it works quite well.
>
> >
> > 13 Polymorphism in Objects. What other object modeling language
> > doesn't have Polymorphism? derrrrr
>
> Oracle is not a language. Oracle is an RDBMS. Oracle has supplied
> interfaces such as pre-compilers, Developer 2000, etc., but they are for
> convenience in developing appliations. There is nothing essentially
> object-oriented about the database itself.
>
> >
> > 14. Binary operator XOR.
>
> Get off the binary kick. If you need to do binary operations then use a
> 3GL language. Don't blame Oracle for your own shortcomings.
>
> >
> > 15. Give SQL Loader the ability to skip columns in CSV format. Not
> > all fields in a CSV file may be needed Oracle, so come on.
>
> If you don't like SQL Loader, write your own load program. It is so simple
> that I'd even let an intern do it.
>
> >
> > 16 Allow Oracle Debugger Probe to watch of implicit loop variables.
>
> Can you spell PROPRIETARY? If you want this stuff then buy the company so
> you can learn all the secrets.
>
> >
> > 17. Allow "OR REPLACE" syntax on all create object commands.
> > etc. etc. etc.
> >
>
> You don't know a lot about how this works do you? If you did, you wouldn't
> make such dumb requests. In some cases this would be disasterous -
> especially when integrity constraints are involved.
>
> >
> > I could continue, but I'm sure others will add to this.
> >
>
> I sure hope not. My advise to you is just get out of the Oracle
> programming world if you find it so dxxx inconvenient. I'm sure with all
> your wisdom you'd be able to come out with a product that can do all these
> things, so why are you wasting your breathe moaning and complaining about
> why Oracle doesn't. I bet they won't come groveling and ask you to come
> work for them to solve all these problems.
>
> To all of the other reasonable people on the forum, I apologize for the
> harshness of this responce, but the originating author was asking for it.
>
> >
> > Kind regards
> > Paul Scott
> > aspscott_at_tcp.co.uk
> > ^^ remove 'as' anti-spam prefix to E-mail
Received on Wed Jul 28 1999 - 19:40:34 CDT