Re: yipeee!

joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0402061455.50ece075_at_posting.google.com>...
> I don't see this. Even if a company has a strategic initiative to go
> to a particular database, mergers, aquisitions, and specific
> application requirements still mean heterogeneity. There may be some
> pure MS companies around, but I wouldn't know about them (and I don't
> think MS is one of them, and of course IBM may well be its own world).
>
> The skillset problem is challenging, but a red herring since it is
> probably not a good idea as a strategic plan, except maybe in certain
> small companies. Even governments that specified Oracle figured that
> out. Enterprise software salespeople sell gateways, if they have to.

You misread my email: I didn't and don't advocate blind and complete adherance to a strategic direction for vendor products. I did, however, recommend putting a lot of priority on compliance with that strategic direction.

Sure, you can build appliations that are a mix of vb, clipper, .net, jdbc, and mainframe COBOL. But just because those technologies might exist in the organization is no reason to avoid attempting some consistency.

Same issue with databases - you can support Informix, Sybase, SQL Server, Oracle, DB2, Postgresql, MySQL, Firebird, and Access if you want. But you'll pay more for licenses, you'll have more human-error failures due to insufficient skillsets.

Gateways aren't an answer either - just another set of product version constraints, and incompatibilities. Want to be successful with this kind of middleware - make sure you've got experts on all databases *AND* the gateway. Nothing like finding that you've got to upgrade a database to support an essential new application version, but that your gateway doesn't yet support that version.

I'd firmly recommend trying to stick to an absolute minimum number of database and application technologies. These days, the pressure seems to be on one open source and one commercial product in most departments that I work with. My recommendation is often something like:

• mysql only if you have to (if required by application you want)
• postgresql for low-end databases
• db2/sybase/oracle/informix/sql server depending on:
  • application requirements
  • os preferences (unix vs windows)
  • cost

The fact that one database has feature a and another database doesn't (this year), is only very seldom the best reason for selecting a database. Decide databases exclusively on that kind of criteria and you'll create a disaster. Received on Sat Feb 07 2004 - 10:50:33 CST