Re: Which one is better? Oracel 9i or DB2 7.2??

To a degree yes, but I have been places where they did the following because not all databases did it the same:
No Referential integrity
no triggers
No function based indexes
No sequences or auto generated primary keys No stored procedures
All text fields that needed to be very large (eg a LOB) were put into a table where the rows were split up in 2K chunks and reassembled for each query to that.
No vendor specific builtins (eg functions like nvl or cast) which means almost no functions
No joins

If you are building a large complex system (eg a trading system) the likelyhood that you are going to switch backends once you have made the decision and gotten it working without a rewrite (due to something other than the database) is almost nil. People don't do this type of thing with C compilers - make sure their code compiles with most C compilers that work on the chosen platform or even platforms!
Jim

"Robert Dean" <noemail_at_hatespam.spam> wrote in message news:3CCFF6A1.37631409_at_hatespam.spam...
> The primary point for saying "use the standards" is that it would
> enable to original poster to not experience vendor lock-in. The
> primary danger in utilizing the "extra" features of any particular
> product is that it makes the cost of jumping off that product
> higher. I've seen this happen for other software products a lot...
> vendor gets their foot in the door, gets the customer to depend on
> the product, and then raises the price. The customer must either
> spend the extra money on support/upgrades, or spend a lot more money
> to convert to a competitive product.
>
> However, I think it makes sense to use the "extra" features when they
> provide an extra compelling value to the application, that can't be
> done simply or cheaply using just the standards.
>
>
> Robert
>
>
> Jim Kennedy wrote:
> >
> > I disagree. If you are going to buy a database use what you paid for.
My
> > first inclination would be to go with something I know well and not with
> > something you don't know well. If you are familiar with choice X and
have
> > staff who are also familiar with choice X and choice X will do the job
then
> > I would be hard pressed to make a different choice. It would have to be
> > something very overwhelming and I would want it proven to make a
different
> > choice. The comfort level that my developers have and familiarities
with
> > the strengths and weaknesses are much more important than dragging the
> > respective companies marketing types into it. The marketing types are
> > usually NOT technical and don't do any day to day development. If you
want
> > a free lunch then maybe invite them in. :-) But to buy an expensive
> > database and make the decision not to use its features to the benefit of
> > your business is like buying a high performance car and driving it like
a
> > Yugo - just so you don't relief on a feature some other car doesn't
> > have.(Yugo being lowest common denominator)
> >
> > Jim
> >
> > "Robert Sundström" <robert.sundstrom_at_upright.se> wrote in message
> > news:aam9lg$b6d$1_at_yggdrasil.utfors.se...
> > > In article <3CCD6A14.6090206_at_netcape.net>, KPNG <japang_at_netcape.net>
> > wrote:
> > > >Hi All,
> > > >
> > > >I'm comparing these two brand database server for our new trading
system.
> > > >
> > > >I know that both of them are famous and occupied large market share.
But
> > > >can some tell me, or has link to the research document which can
compare
> > > >these two products objectively.
> > >
> > > I believe the most important design choice/decision when implementing
your
> > > system is to make sure your trading system will only use standardized
> > features
> > > provided by both vendors, and possibly other brands as well. If you
are
> > able
> > > to do this, the choice of database vendor will be less important for
your
> > > business. Since it will be easier for you to migrate to another brand
> > sometime
> > > in he future, you will be less dependent on those
suit-and-tie-equipped
> > sales
> > > drones who in a few years inevitably will try to have you pay higher
> > support
> > > fees.
> > >
> > > -
> > > Robert Sundström, Mimer SQL Development
> > > Upright Database Technology AB, http://www.mimer.com
Received on Wed May 01 2002 - 09:38:45 CDT