Hi,

When someone mentions a DBMS such as MySQL in this newsgroup in connection with
implementing something non-trivial, it is often dismissed out of hand (search
the group history if you need examples).

I would agree that ORACLE is the undisputed market leader, but I don't think
that we need to consider everything else as a plaything. After all, MySQL is
used for a lot of serious projects (I for one wouldn't mind being responsible
for the design of Wikipedia or YouTube) and is available (uncrippled) as GPL.

If one was starting a business that needed to support the load of (say)
Wikipedia, it would surely be financial negligence not to consider using MySQL
or Postgres.

Does anyone disagree?

On 30.04.2007 11:45, Robert wrote:
This has been mentioned so many times: license cost of a piece of
software makes up only portion of the overall cost. These kinds of
decisions should be based on much more complex reasoning - cost is just
one dimension.

Kind regards

robert

Robert Klemme wrote:
I would hope that most readers understand the concept of TCO. Unless this is
always going to be minimal by using ORACLE then your comment is beside the point
(which is not necessarily a bad thing).

Robert <robert@email> wrote:

are developing commercial software then MySQL AB assert that you
cannot use the GPL version of MySQL
<http://www.mysql.com/company/legal/licensing/index.html>. They claim
that _using_ the database makes your software a derived work. No other
GPL database attempts any similar restrictions.

In contrast, Oracle provide the full version to developers at no cost
<http://www.oracle.com/technology/software/products/database/oracle10g/index.html>
and the free "crippled" version "can be installed on any size host
machine with any number of CPUs (one database per machine), but XE
will store up to 4GB of user data, use up to 1GB of memory, and use
one CPU on the host machine". If my web site is ever handicapped by
those restrictions I will be delighted.

On Apr 30, 7:02 am, Robert <robert@email> wrote:
But the fact is many new deveopers do NOT understand TCO (Total Cost
of Ownership).

Go look back at some of my posts where I try to explain that asking
which DB in a newsgroup is a poor idea.

What should happen when looking for a DBMS product is along the lines
of:
phase I - examine the market for products and technologies
e.g. DB models (network or relational or object) , transaction
model(row, page, table locking models or read consistant model),
programming tools (SQL, embedded SQL, custom Libraries), support tools
(forms programming, adhoc SQL, Admin commands/reports), platforms
supported (WINDOWS, LINUX, Solaris, ...)and cross platform
support(will a program written to access the DB have to be changed or
recompiled if the target DB is moved from one machine to another? one
OS to another?, integration (ODBC, JDBC, Other?). . . license
restrictions?
It is a long list that I have not exhausted here.

phase II - which features are most useful in your environment?
e.g. large datawarehousing or small, in-memory DB required? Current
in-house expertise available? Training/reference material available or
needed? What are the Performance requirements? Volume requirements?
Transaction requirements? (none, commited, serializable?) Support
requirements (e.g. an embedded system versus a business application)?

phase III cross reference the products with your product/project
requirements.
At this point you might put cost in the mix. be sure to include:
* initial cost of DBMS license (development)
* cost of training (note availablity/price of training resources, such
as training classes, books, college classes)
* on going development costs
* ongoing support costs


Then you can make an informed decision.

In the past, some of the DBMS products were toys, but recently mySQL
and other open software products are getting closer to industrial
strength. It still surprises me that people looking into getting a
DBMS seem to start by eliminating perceived high priced products like
Oracle. Price should be one of many feature requirements.

Ed.

Am Mon, 30 Apr 2007 10:45:03 +0100 schrieb Robert:

I have the impression that in this NG, the "default DBMS" is not
Oracle, but DB2. Probably because it's SQL is closest to ANSI.

Joachim

I agree it's wrong to call MySQL a plaything. Playthings are fun.
PostgreSQL is a plaything.

"Ed Prochak" <edprochak (AT) gmail (DOT) com> skrev i en meddelelse
news:1177947430.344126.212170 (AT) h2g2000hsg (DOT) googlegroups.com...

Not quite.
A phase IV examining cost/problems exiting a DB as part of TCO.



Best regards,
Michael Weber

Bruce Lewis wrote:
I've used the following RDBMSes professionally, among others:
- Oracle
- DB2
- MS SQL Server
- PostgreSQL
- MySQL
- Red Brick

I usually test my database-aware code against at least two different RDBMSes,
which gives me practice translating between dialects.

I am not a DBA, but most jobs require me to act at least a little like one. I
have set up all of the ones I mentioned except Red Brick, from initial install
through defining users, tablespaces, schemas, yada, yada. I used them with
embedded SQL, ODBC and JDBC to develop desktop and web applications and
services. I mention all this to give you a perspective on how I garnered my
opinion.

Personally I liked MySQL the least and found PostgreSQL the easiest to
administer. Oracle and DB2 are a bit of a bitch to administer, but the
Express editions are easier.

MySQL in a group environment is dangerous without a competent DBA. You can
lose the ability to enforce foreign key constraints in a heartbeat if you
aren't on top of it. I am also deeply suspicious of its license terms. It
could be the only "free" system that requires you to pay for a license. As
pointed out, Oracle and DB2 have free-to-profit-from versions.

I like MySQL the least. Its really a handful of products, depending on which
DB engine you run. Don't even bother with MyISAM if you want an RDMBS. MySQL
generally is non-standard and seems a bit cheesy to me.

I like PostgreSQL the most because it's the easiest for solo administration
but has the same enterprise-scale strength as the other big guys.

If you have truly big-iron needs, like dropping segments while others remain
on line through other disk stripes, I don't know who has the best TCO.
Support and the availability of expertise becomes an important factor for such
configurations.

--
Lew