Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Databases / January 2006

Tip: Looking for answers? Try searching our database.

Opinions wanted:  MySQL and Oracle Decision

Thread view: 
Libertarian - 21 Jan 2006 19:34 GMT
About to embark on a new project... no customer at this time.

I've narrowed the backend choices down to MySQL and Oracle (partly a
tech decision, partly a market reality decision).  In a world without
constraints, I'd choose Oracle since I have used it since version 7 and
I can really leverage the proprietary bits if allowed to.

MySQL 5.0 on the other hand is a close contender.  It's not quite
Oracle, but you can see it from there.

The driving factor in my decision is what will my "potential" customers
like:  MySQL or Oracle.  Many potential customers have flexible site
licenses and existing ties to Oracle... my app would be a negigible $
addtion.  However, many smaller customers can only afford MySQL.  So who
to target...?

It will be about 2 years before I know who will like my product...
Oracle Shops or Shoe-string Shops.  So I'll start development using
generic ANSI SQL to the max extent possible.  I think, but am unsure, I
can proceed with development friendly to both.

Some Q's:

1.  Are the trigger/package capabilities in MySQL are similiar to Oracle?

2.  How far can one go down the develop road before they are married to
a backend?  (there's high bad joke potential for that stmt)

3.  Cognizant of the potential need to change backend db's in the
future, which would you start development with today:  MySQL, Oracle, other?

Other thougts...
Roedy Green - 21 Jan 2006 23:03 GMT
> However, many smaller customers can only afford MySQL.  So who
>to target...?

If you are a shoestring company yourself, you will more easily market
to other shoestrings.

A big company won't want to risk the investment in a product that
could easily disappear.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

HansF - 21 Jan 2006 23:55 GMT
Oracle Express Edition, with a price tag of $0 for production deployment,
it might be worth investigating. Since it uses the same core engine as
all the other editions, it is compatible in SQL and PL/SQL.  It just does
not include the internal JVM.  This does not impact any Java apps that
only want JDBC access to the database.

In my personal research, I've noticed that small organizations will
usually stay under the 4GB data limit imposed by Express Edition, and
larger organizations are generally willing to pay for the appropriate
edition for their needs (Standard One, Standard, Enterprise) if the app
grows that much.  The idea of simply swapping the engine to handle larger
organizations, and having guaranteed 100% compatibility appeals to me.

Signature

Hans Forbrich                          
Canada-wide Oracle training and consulting
mailto: Fuzzy.GreyBeard_at_gmail.com  
*** Top posting [replies] guarantees I won't respond. ***

Richard Wheeldon - 22 Jan 2006 11:45 GMT
> 2.  How far can one go down the develop road before they are married to
> a backend?  (there's high bad joke potential for that stmt)

If you're careful, a very long way. My last project was Oracle-based
from day one and could still be changed at a pinch to something else but
would require new schema creation scripts and changes to around 5
percent of the code. The biggest pain would be finding an equivalent to
catsearch. My current project was designed from day one to be compatible
with HSql, PostgreSQL and Oracle. The worst issue in attempting this has
been the inconsistent date handling.

Imho, the basic rules for allowing future change are:
1. Keep everything related to the database in a single package,
interface or API. Perform all database access through this. Write unit
tests to this specification where appropriate.
2. Avoid use of non-standard features such as Context which cause problems.
3. Avoid stored procedures.
4. Access everything non-trivial through views. This way you can change
everything in a single set of database creation scripts rather than
changing every nth line of Java code.

All this is about keeping all the changes in one place.

> 3.  Cognizant of the potential need to change backend db's in the
> future, which would you start development with today:  MySQL, Oracle,
> other?

Oracle or PostgreSQL. PostgreSQL has had many of the features that MySQL
has lacked for quite a while now. Oracle still wins for the following
reasons:

1. Scalability and speed - In my experience Oracle outperforms the
competition in almost any non-trivial situation. ymmv.
2. Better developer tools and more of them.

Richard


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.