 |
You Say You Want a Revolution (or Dude, Where's My Database?)
by Lee Geistlinger, in Editorials - Sat, Mar 16th 2002 00:00 PDT
Remember those heady days of the mid-to-late 1990s? When Webmonkey
was required daily reading, Hotdog and HoTMetaL Pro were the "cool"
HTML editors (though vi and Notepad predominated), and the Browser
Wars were relevant? When virtually all Web sites were collections of
static pages, even if generated via some dynamic process(es) such as
VB widgets or Perl scripts? When Perl CGIs and .shtml pages were the
only true approximation of dynamic Web development available? When
Java still meant coffee, ASP was a snake, and Linus was a character in
the Peanuts cartoon? Remember? Ah, the bad old days.
Copyright notice: All reader-contributed material on freshmeat.net
is the property and responsibility of its author; for reprint rights, please contact the author
directly.
Today, things on the Web are unbelievably different. Reflecting the
entire culture of the Internet, the Web is today a collection of
mostly dynamic Web pages. From the high-traffic sites running
on custom or packaged software (such as Vignette Story Server or
Future Tense), through the smaller business sites running off Cold
Fusion/Access, to individual sites running off Blogger or similar
packages/services, dynamic pages are overtaking static pages at an
increasingly rapid rate.
Even so-called "HTML editors" are getting into the act, acting more
like (very) mini-publishing systems than simple editors. Dreamweaver
has morphed into Ultra-Dev, FrontPage has its own set of proprietary
form extensions to make autogeneration of input forms/collection from
the same straightforward, and most editors worth their salt have some
sort of "project" mode that automatically reassigns (relative) links
when a page is moved from one directory to another, etc.
However, "smart" or proprietary tools only get you part of the
way there. For a truly dynamic site, you need a database.
Database primer
A database can take many forms, but is generally categorized into one
of three slots:
- A flat file (Perl does wonders with flat files)
- A file-based database (Access)
- A true relational database, as described in 1970 by
Dr. E.F. Cobb. (MS SQL, Oracle, MySQL)
But here's the problem: While the Open Source Software (OSS) movement
has produced some exceptional tools for Web and other types of work,
it has either:
- Produced inferior database products that have become de facto
OSS standards (MySQL),
- Produced exceptional tools that for one reason or another have
been largely ignored (PostgreSQL) by the OSS masses,
- Or produced NO database tools that the non-OSS crowd
appreciates. (While many non-OSS folks know about Apache and
perhaps BSD (thanks to Apple's OS X), non-OSS folk haven't even
heard of mSQL or MySQL.)
Whether you realize it or not, there is a fulcrum that the entire OSS
movement is balanced upon, and, increasingly, that fulcrum is named
"database". While you can debate the veracity of the "Information
wants to be free" manifesto (I think it should read "I want all
information at no cost"), note the lead keyword: Information.
Such as is stored in a database.
What database? Are there really any valid OSS choices? I don't think
so. (Thus begins the flamewar....)
The two databases I will use for comparison's sake are those mentioned
above, MySQL and PostgreSQL.
The former, MySQL, has the largest install base, so is best poised to
succeed and endure (install base == endurance; see Microsoft...). It
is a terrible database which grew up quickly and, until very recently,
lacked the true database features (such as foreign key support and
replication) that make it something you can confidently recommend to
your boss (or your friend). However, it does have the install base
(this is very important; you can get another MySQL DBA easier than one
for, say, mSQL), it does have a small (but effective) number of tools
(GUIs and so on), and it is deployable on Windows (yes, the Dark
Side). On the business side, NuSphere has done well at promoting a
for-fee version of the database.
The latter, PostgreSQL, has both the pedigree (the Palo Alto area has
produced such meaningless baubles as BSD, Sun Microsystems...) and the
features of an enterprise-class database. Unfortunately, it came after
MySQL and has essentially been eclipsed by it. On the business side,
Red Hat approached and was rebuffed by Great Bridge, a NuSphere-type
business which capitalizes on PostgreSQL. Great Bridge filed for
bankruptcy shortly after this brilliant "strategic decision" (http://news.com.com/2100-1001-272715.html).
[Note: Red Hat has deployed a database solution for its customers
based on PostgreSQL; I have heard nothing about its success/lack
thereof.]
Which leaves the average Slashdot reader/developer with two questions:
- Why can't OSS databases match commercial databases in the same way
Apache meets/beats IIS and/or iPlanet (née Netscape)?
- What database should I use?
Damn good questions.
Which leads to a third, more dangerous question: What is OSS
development? DOES it rely solely on OSS, or is a careful/cautious mix
of OSS and commercial products (such as Microsoft's or Oracle's, not
NuSphere's) acceptable or even necessary?
What is OSS, at least in regard to databases?
There are valid arguments (and rebuttals) for almost any of the
questions listed in the preceding paragraph, but, for me, it comes
down to the following:
- Software is a tool, not a religion. (Is Pine a great email
program? Yes! Will I set up my Mom on Pine? No! Does AOL suck?
Yes! Will I set up my Mom on AOL? Yes!) Pick the best tool for
the project; don't set up a Beowulf cluster for your neighbor's
home network...
- What gives me the best bang for the buck? (This factors in
platform (OS) availability, support, cost, ability to find DBAs
for selected product, etc.)
- Will this tool endure/scale: Will it be around in 1/2/3/30
years? Does it meet or overreach my needs?
In other words, let's be pragmatic. Let's not bash Bill Gates for
sport, only when relevant.
OSS options
At some point, the OSS folks have to admit that they do NOT have a
viable OSS database, or they have to continue with their snot-nosed
claim that they do have one... and then, basically, fail to deliver
on this claim.
I'm not happy about this. I love PostgreSQL, but it sure doesn't look
like it's ever going to be a player, despite glowing OSS press
coverage. Without the community support, it won't make it. That's a
fact, however unpleasant.
So what are the OSS options with regard to databases?
Well, as mentioned above, it all depends, to a certain extent, on what
one believes OSS is. Still, here are, really, the range of options
(and the platforms they run on):
- MS Access
- With either MS's FrontPage or Macromedia ColdFusion, a winning,
low-cost, non-scalable solution. NT only. On every desktop,
serious scalability issues, good SQL92 support.
- MS SQL Server
- An excellent product, one of Microsoft's best (second only to
the Visual Studio toolset) that has a number of significant
flaws and "issues", but which is nevertheless widely deployed
despite its relatively (vs. OSS) high cost. Each release gets
better. Version 7 was a quantum leap over version 6.5, and version
2000 is better still, although there are things that I file as
"these improvements are like Access", which is not a good
thing. NT only, and MS, in it's infinite stupidity/arrogance,
has made the licensing agreements for this server more
restrictive/costly than in the past. This could help or hurt MS;
history will judge.
- MySQL
- The first real relational database on *nix that was embraced by
the OSS community. It has serious limitations but a
cross-platform environment and a wide install base of OSS
supporters running Linux/Apache/PHP|Perl/MySQL. Like Access,
it's everywhere (but on an OSS user's system).
- mSQL
- Inconsequential.
- PostgreSQL
- A product of Berkeley, a very Oracle-like database competing
with MySQL and (to a lesser degree) Oracle. MySQL has a
much larger install base and came earlier. Sad.
- Oracle (pick the version)
- The "best" (if money and personnel are no object) database out
there. It certainly has more features/options than
virtually any other database; that is what you pay for. Certain
"lite" (limited functionality) versions are available for low/no
cost for varying platforms. It requires considerable expertise
to operate effectively.
Reality Check
Repeat after me: Software is a tool, not a religion.
So what do we all do? There really are not scalable solutions to OSS
database conundrums; the most viable is the one that is most
distasteful to most OSS users: A Microsoft solution.
There are a countless articles on how to connect PHP (which, while
cross-platform, is essentially an OSS product) with Microsoft MS SQL.
Yes, connect with the Dark Side.
Why the hell are such articles even written? (Example:
http://www.phpbuilder.com/columns/alberto20000919.php3.) Because
they are necessary.
While most companies/individuals are too narrow-minded to mix OSS with
MS products, this is often a good solution, especially for
middle-range companies (that cannot afford Oracle). Yes, the hard part
of the OSS & MS equation is platform, but PHP works very well on
Windows, as well (no, not as good as on *nix, but that's my
opinion).
What does this all mean? That OSS databases are really not ready for
prime time in the way that Apache, BSD, PHP, and other OSS tools are,
and, to me, that we are way past "well, it'll be kewl in a few months
when we [whatever]". OSS database developers -- and especially users
-- have failed to develop/embrace good DB tools. This is a fatal flaw
in OSS; it leaves the door open to commercial, very non-OSS products.
I don't see an outcry, one way or another, about this.
Why is that?
Author's bio:
Lee Geistlinger has had more
careers than Heinz has pickles. He's jaded, but never fails to be
dazzled by the success of mediocrity (or frustrated by the same). He
dreams in hexadecimal.
T-Shirts and Fame!
We're eager to find people interested in writing articles on
software-related topics. We're flexible on length, style, and
topic, so long as you know what you're talking about and back up
your opinions with facts. Anyone who writes an article gets a
t-shirt from ThinkGeek
in addition to 15 minutes of fame. If you think you'd like to try
your hand at it, let jeff.covey@freshmeat.net
know what you'd like to write about.
[Comments are disabled]
Comments
[»]
What about Sybase?
by Warlock - Jan 15th 2003 09:04:05
I noticed that you did not include Sybase for Linux in your comparison, but
did include Oracle....
I would classify Sybase 11.0.33 (free version) for Linux as quite superior
to mysql....
Its Fast, and its free... I have a couple 100 GB+ Sybase databases running
on the free version with very little problem, and very good
performance...
It annoys me intensly, as sybase is always left out of the reviews, but
Oracle is included...
All I can really say regarding sybase on Linux is, Try it.... we did, and
threw out all our Oracle Databases and bought the New Sybase 12.x for
Linux.. and havnt looked back since...
[reply]
[top]
[»]
Open Source Database
by Damien - Jul 12th 2002 18:54:10
I would have agreed with your article until I read
"HOWTO provide Microsoft Access-like functionality on Linux with
open-source tools - OpenOffice.org 1.0, unixODBC, and MySQL" by John
McCreesh available at:
http://www.unixodbc.org/doc/OOoMySQL.pdf
Bye bye MS-Access...
Damien
[reply]
[top]
[»]
Putting a database in a computer is silly!
by linuxknight - Jun 14th 2002 20:31:43
Come on, a database in a computer? Everyone knows that
computers just aren't good for that, databases should be kept
on paper, in an office. Not on a computer! Databases have no
place in a computer.
--
Signed, Linuxknight
[reply]
[top]
[»]
SQLBoss Developer - Makes database development & content management much easier.
by SQLBoss Database Tools - Jun 7th 2002 08:26:58
I want to introduce you to a SQL tool which definitely helps to
speed up development and maintainance of various SQL
databases: SQLBoss Developer 1.3.1 Its natively
supports 11 different database types e.g mySQL, PostgreSQL,
OpenBase, FrontBase, dtfSQL, 4D, Oracle (Beta) and many
more besides the ODBC connection possibility.
You can download a free trial at:
http://www.SQLBoss.com
Or see SQLBoss @ Freshmeat:
Freshmeat Project
SQLBoss Developer
Short Description:
SQLBoss Developer and the upcoming SQLBoss Layouter from
SQLBoss Inc. provide you with a complete database and
content management system for many (11) SQL databases.
SQLBoss Developer is a tool for rapid database development
on remote hosts. It helps you to create and change
databases, tables and columns and to manage the content
within web-enabled databases. More features: supports 8
import/export file formats, dynamically generated data entry
layouts, HTML WYSIWYG Editor, database backup server,
mySQL Admin. Fastest SQL tool on the market.
--
SQLBoss - SQL Database Development & Content
Management Tools
http://www.SQLBoss.com
SQLBoss Developer
SQLBoss Layouter
SQLBoss Monitor
[reply]
[top]
[»]
Re: SQLBoss Developer - Makes database development & content management much easier.
by jeff covey - Jun 7th 2002 11:19:17
Wow. Spam in an article comment; that's a first.
--
vs lbh pna ernq guvf, lbh'er n trrx.
[reply]
[top]
[»]
Re: SQLBoss Developer - Makes database development & content management much easier.
by Tony Douglas - Jun 7th 2002 15:22:38
I'll bet it's not the last either ... :(
As an aside, much database related fun can be had at www.dbdebunk.com. SQL fans in general
(and MySQL fans in particular) should wear a hard hat ... !
- Tony
[reply]
[top]
[»]
Very good links page for databases running on Linux
by elucidus - May 29th 2002 18:05:06
SQL Databases
Includes substantial links to support info on PostgreSQL and MySQL. As
well as covering the commercial players such as Oracle, DB2 and more
obscure ones such as integra4 and PrimeBase.
--
Technology Observer
[reply]
[top]
[»]
DBMS :-( ODBMS :-)
by Petite Abeille - Apr 23rd 2002 16:45:29
I guess its time to move on from the relics of the fifties
(aka dbms). What about joining the 21st century and
using an odbms?
Just wandering...
[reply]
[top]
[»]
The right tool for the job...
by chris - Apr 23rd 2002 02:38:56
I have just read your article on Open source databases. Though I agree
with some of what you say, I do take a few exceptions to some of your
comments though, of which a few stand out.
You seem to forget other databases such as SAP, SyBase, ADABAS D, DB2
and
others. Each of these are competition for Oracle, and in some cases
cover
the same turf Postgress covers.
As to your comment about "Will it be around in 1/2/3/30 years?"
Can I get
a more realistic 8 years? Given most software projects by the time year
6
rolls around, the original developer is either a) forgotten history in
that company, or b) [S]He is looking to re-implement it on another
database that has some other super feature [S]He *MUST* have.
Not many software companies that have lasted 30 years. The closest
database company (in my brief memory search) I can come up with is
'Metafile'. It's about 20 years old. I think the company that makes
metafile is still in Rochester Minnesota. With the exception of DB2 it
is
the only database I am aware of that has been available since the mid
1980's that hasn't been taken over, bought, sold or abandoned.
As to why MySQL might be so popular:
MySQL had the tools and the 'right size' available at the right
time
(early to mid 1997). PHP3 had an arguably better interface than
perl
(with the module version for apache). MySQL was significantly
better
than MSQL 1.x, and generally better than MSQL 2.x; What clinched
MySQL for me was the more 'open' license than MSQL 2.x.
Having spent time working/developing with MySQL (and Oracle,
Sybase
and Informix in UNIX Admin roles) and almost no time with Postgress,
I
have little background to speak, however my impression is that
Postgress takes more administrative overhead than MySQL does, so I
stick with MySQL and this impression may be the reason why
Postgress
is not as popular as MySQL is.
You spend more than passing time on MySQLs short comings. Some of
these issues you speak of have been addressed in recent editions
of
MySQL. Since MySQL doesn't have transactions, foreign keys, sub
selects, et all, then a move to Oracle or Sybase would have been
my
choice. If a developer starts with a small light weight RDBMS on
a
project and then he bumps his head up against an issue as his
project
grows what is his choice? Reimplement on Postgress and continue
again
until he runs into a Postgress issue, or break down and buy Oracle
and
reimplement. If it were me, I would pick Oracle. At least I can
bitch as a sales droid about the 'vapoware' they sold.
The issue may not be that MySQL is/was first, but that it is a
'baby'
step to learning SQL and the issues associated with growing a
web/database application. MySQL to me appears to be a little less
complicated to deal with. When faced with learning a new language
(ie
PHP) and a new way to access data (SQL statements), managing a
database engine and apache modules, taking things in manageable
hunks
wins over the better technology just because it's a 'learning
experience'.
Take your pick. Your guess is as good as mine.
I saw some comments about the scalability of MySQL vs Postgress.
Again,
what is the task? I could easily say that Postgress is totally
inadequate
for the task of managing a 5TB database of case law for legal
searches,
especially since I was a contractor at a very popular legal publishing
company which uses ADABSE D with gobs of PL/1 on IBM big iron.
I would like to see a MySQL type database be included in all UNIXes
(perhaps as a standard), especially if system interfaces were written
so
that I could avoid things like /etc/aliases in sendmail having to be
read
from flat files and then written in to hash tables. Overkill to use
Postgress, but just right for MySQL. I have used PHP as a cgi-bin
program
to query a MySQL database to build a flat 'aliases' file to be read
by
sendamil and converted to a hash table. Roundabout way but a whole
lot
better than giving out 'root' to a dozen tech support guys who all
want
to be to BOFH next week (NIS+ wasn't permitted because of security
issues).
What it all boils down to is right sized tools for the task. Some
people
may have only run into tasks that you need multi joins, transaction
processing, sub selects, etc which makes Postgress the wonder tool.
Some
of us may have only needed to manage loosely knit tables together where
a
database like MySQL works fine. I don't need DB2 to manage my
/etc/mail/aliases, /etc/mail/virtusertable, and
/etc/mail/relay.networks
files.
[reply]
[top]
[»]
Re: The right tool for the job...
by Tony Douglas - Apr 23rd 2002 06:37:49
The interesting thing that seems to be coming out of the various comments
is a view of something like "start with MySQL, and if it outgrows that, go
to Oracle/Sybase/blah". This is an interesting challenge for the PostgreSQL
people; how to make it clear to everybody that "there is a middle way".
Rather than anybody going on about how much "better" PostgreSQL is than
MySQL blah blah blah, accept that there is a whole application space
("mini-relational" ?) that MySQL covers pretty well, but that once an
application goes beyond that space, commercial DBMSs aren't the automatic
choice - you can stay open source, and get many of the
(application-facing) benefits of those DBMSs (although not all the
management-facing benefits - see my other posts on that).
And for those "mini-relational" applications, what about the various
Berkeley DBs ? For the application this poster was talking about, LDAP
sounds a pretty sound bet too.
And it's PostgreSQL, not Postgress. As an Ingres user, which is usually
called "Ingress" by those not in the know, I get touchy about those double
s'es ! Why they didn't call it "Miro" I don't know (somebody else has
pinched that name, now).
- Tony
[reply]
[top]
[»]
Re: The right tool for the job...
by chris - Apr 23rd 2002 12:49:29
> The interesting thing that seems to be
> coming out of the various comments is a
> view of something like "start with
> MySQL, and if it outgrows that, go to
> Oracle/Sybase/blah". This is an
> interesting challenge for the PostgreSQL
> people; how to make it clear to
> everybody that "there is a middle way".
>startquote
> And it's PostgreSQL, not Postgress.
Apologies to those offended by Postgress vs PostGreSQL. IMHO .db,
.dbm,
and db3 were not as easy to deal with as MySQL was, particularly with
PHP
and web applications. When tying to tie a couple of ISPs who's ideas
about admining systems are vastly different at the time of acquisition,
an
application was needed in a hurry, and using 'MySQL-Apache-PHP' a solution
was there and available in a week. LDAP would have taken longer, and
I
was a contractor, I did was they asked me to do.
The vast majority of admins/developers are self teaching. The
community
learning curve may need to go through the MySQL step, before they move
to
something else. I watched something similar in the PC world in the
80's.
Odd little special applications using flat file databases, then
PC-FILE,
then RBase/dBase, etc. Eventually, they moved to Oracle, and it's
growing pains. As the people who developed their applications grew in
knowledge, so did their need for more sophisticated tools. True
database
weenies of the time were busy on the Mainframe loading DB2 databases
snickering at Oracle, and outright laughing at dBase.
Circa 1994 I remember a FAQ on 'free' databases available for UNIX.
It
contained a list of features and limits of many different databases
for
UNIX. A updated version of that document may have been a better place
to
spend energy rather than complaining as to which databse is more
widely
accepted, bemoaning the fact, and pondering the reasons it is the way
it
is. Complaining and pontificating are less effective at educating
than
comprehensive information is. MySQL has a niche it has etched out for
it's self. Is it the best tool? No. Is PostGreSQL? No (that may be
difficult to accept for some). Reading several of your replys to
others
you seem to have a strong aversion to anything MySQL. What ever MySQL
has
done to step on your tail, there is not much I can do about it, nor any
of
the other users of MySQL. Sorry you don't like MySQL, but MySQL
serves a need otherwise it would be so much discarded code littering
the information super highway.
In some ways MySQL-Apache-PHP-PHPMyAdmin reminds me of PC-FILE for DOS
in
the mid 1980's. Quick, dirty, not quite fully relational, but it
works for most and get's the job done.
As to why can't open source deliver a 'Enterprise' level data base
server?
Probably because it's not high on the importance factor of most
developers. It requires more complicated engineering from the start.
It
has always been the realm of the 'heavy hitters' (ie Oracle, Sybase,
IBM
et all). It's a long way to go from PostGreSQL to DB2. Even running
PostGreSQL as native code on OS/390 it would be a long journey filled
with
DB2 bigots slandering PostGreSQL at every line of code.
-- 73s SK DE Chris
[reply]
[top]
[»]
Re: The right tool for the job...
by Tony Douglas - Apr 25th 2002 15:23:16
Hi there,
Apologies to those offended by Postgress vs PostGreSQL.
None taken, and none intended I'm sure. I'm way more touchy about the
"Ingress" vs. "Ingres" one, esp. when it's techies in our own company (or
reporters in computing mags) !
IMHO .db,.dbm,and db3 were not as easy to deal with as MySQL was,
particularly with PHP and web applications.
They can be a pain, but they've got their place.
When tying to tie a couple of ISPs who's ideas about admining systems
are vastly different at the time of acquisition, an application was needed
in a hurry, and using 'MySQL-Apache-PHP' a solution was there and
available in a week.
Then it's the right choice by a mile. If you can move that quickly, and
there's enough of the right expertise about, why look any place else
indeed ?
LDAP would have taken longer,
LDAP is one of those "good things" I've always meant to spend a little
time with, but never quite got around to until recently, and I must admit
to being quite impressed with it for a few things. The O'Reilly "Network
Printing" book was a surprising place to get a shove into looking at LDAP,
but there you go.
and I was a contractor, I did was they asked me to do.
Being a contractor can put things into a whole new ball park; sometimes
you can be pretty restricted in terms of what you can and can't do or
install or use or whatever.
... snip (which I pretty much agree with, by the way) ...
Circa 1994 I remember a FAQ on 'free' databases available for UNIX. It
contained a list of features and limits of many different databases for
UNIX. A updated version of that document may have been a better place to
spend energy rather than complaining as to which databse is more widely
accepted, bemoaning the fact, and pondering the reasons it is the way it
is.
I think that FAQ is still out there somewhere, but it still mentions some
DBMSs that I don't hear anything about any more, and didn't list the
interesting Java DBMSs (PointBase, Cloudscape etc) for obvious reasons. It
might be quite interesting to see this brought up to date, but it would be
quite an undertaking nowadays.
Complaining and pontificating are less effective at educating than
comprehensive information is.
Very true.
MySQL has a niche it has etched out for it's self.
I agree with that wholeheartedly. But we're about to disagree now...
Is it the best tool? No. Is PostGreSQL? No (that may be difficult to
accept for some).
Before saying "best", define "best". Best for what ? For high volume
read-intense/low-write serving ? For reasonably concurrent write
situations ? For high volume read where SQL isn't required ?
Let's take an analogous situation; what's the best programming language ?
If you've already got an answer, then you're wrong, because I haven't told
you what I want you to do yet ! (OCAML fans are about to start hitting send
as I speak...!) If I want you to write metal-bashing code, then the answer
should be different to if I was asking you to write an expert system with
full backtracking capabilities.
The same thing holds true for databases. What is just the ticket for one
application could be horribly horribly wrong (for any number of reasons)
for the next one.
Reading several of your replys to others you seem to have a strong
aversion to anything MySQL.
No, I don't; honestly, and if I've given that impression then it's because
I haven't been sufficiently clear in my writing. It simply didn't do the
job I needed an open source RDBMS to do a few years back. This may be
because I followed the opposite route to the one you outlined earlier; I
moved from a commercial database (Ingres) to a free database (PostgreSQL),
so my expectations & demands may have been quite different to someone in a
different situation. As I said elsewhere, the situation with MySQL may
well be different now. When I was looking back then ('96 - '97) I started
with mSQL, then tried MySQL then wound up with PostgreSQL, so MySQL had a
shot (I had actually heard of MySQL before PostgreSQL). If I was doing the
same eval now, I might wind up with a different result. I'm open to that
possibility, but I'm quite happy with PostgreSQL (within reasonable
bounds), so haven't felt the need to dig about too much in the time
since.
What ever MySQL has done to step on your tail, there is not much I can
do about it, nor any of the other users of MySQL.
And I wouldn't ask you (or anyone else, for that matter) to do anything
about it; it's up to me to go and find out about these things if I
discover my current toolbox is deficient somewhere.
Sorry you don't like MySQL, but MySQL serves a need otherwise it would
be so much discarded code littering the information super
highway.
Absolutely it does.
...snip...
As to why can't open source deliver a 'Enterprise' level data base
server? Probably because it's not high on the importance factor of most
developers. It requires more complicated engineering from the start. It
has always been the realm of the 'heavy hitters' (ie Oracle, Sybase, IBM
et all).
I agree with some of this, but age & maturity of the code has a lot to do
with it too. DB2's roots are way back at the beginning of implemented
RDBMSs in the early '70s; Ingres dates from about '77, and Oracle about
the same (ISTR copyrights for about 1979 in Oracle installations). They've
had a long time to look at how to keep these beasties up and running,
backed up and safe as houses. The open source databases can do the
querying, but they don't have the management facilities that have been
built up into these products over time.
It's a long way to go from PostGreSQL to DB2.
A very long way. To get an idea, remembering that PostgreSQL's roots are
very close to those of Ingres, compare PostgreSQL to a current commercial
implementation of Ingres. Hell, have a look at the source code of
University Ingres (still available, but likely not buildable on anything
modern) and compare that. Open source databases could be extended to match
the "heavy hitters"; but it'll take a long time, and requires a type of
testing effort that might not be available in an open source environment.
Even running PostGreSQL as native code on OS/390 it would be a long
journey filled with DB2 bigots slandering PostGreSQL at every line of
code.
Well, they slag Ingres at every opportunity ... :)))))
Cheers,
- Tony
[reply]
[top]
[»]
Fun learning MySQL
by civad - Apr 7th 2002 22:58:20
I recently took a course in schhol in DB's, which was (plz: no laughs...)
using M$ Access. I asked my instructor if I could use something else, and
he said it would be okay as long as that 'somethig else' was good. So now
I had a bg question before me. What is 'good'? A lot of questions and a
lot more internet searches later I thought MySQL could be something worth
a try.
I used it to prepare a DB of all the songs that I had on my computer :-)
it was fun and easy to learn. Moreover, thanks to a friend of mine I used
PHP to have a nice lil browser-based interface. The server has been
running for about 10 days with no problems so far, and I get to listen to
my own 'streaming media' anywhere (minus the irritating popup ads).
For a beginer, I think three things are necessary:
a. Ease of install
b. Detailed documentation
c. Online support (forums, etc.)
I dont know if Postgres, etc. have these criteria met, but I did find
mysql quite useful.At the end of the day I was not only able to learn
something new and useful, but I had fun learning it.
Now I think I could swim into some 'serious waters'....
[reply]
[top]
[»]
Re: Fun learning MySQL
by Tony Douglas - Apr 9th 2002 08:29:03
Hi there,
I recently took a course in schhol in
DB's, which was (plz: no laughs...)
using M$ Access.
No laughs here; I hated Microsoft for releasing Access 2.0, because I
quite liked it for visually hacking with schema possibilities when
planning a database (it's a long story). I couldn't say Microsoft had
never released a product I liked any more ! Bah !!
... snip ...
For a beginer, I think three things
are necessary:
a. Ease of install
b. Detailed documentation
c. Online support (forums, etc.)
Enterprise requirements start from similar bases, actually. But you need
to add
d. scalability, to support probably unpredictable growths, ebbs and
flows in use
e. robustness, so that work isn't lost either through poor application
code (there's those dang transactions for you !) or poor database server
code (no crashing or table corruption !)
f. maintainability, that is, the ability to reconfigure either parts
of the DBMS subsystem or the database schema, and to do full backups of
your databases while the database is in use
g. restorability, that is, the ability to restore the database from
backups to a known point in time (say, for example, a developer wrote the
Query From Hell that deleted unknown rows from a table (should never
happen, but ...). You'd want to be able to get the database back to the
state it was in immediately before that transaction started.)
If you're coding up a fairly small application, with only a couple of
concurrent users, small amounts of data (so you could rekey it easily),
maybe the data is fairly static (updates aren't happening regularly) and
you don't need near-permanent availability (ie. you can do loads of
updates, then take the DB offline and back it up, then allow access again
until your next bundle of updates), then you probably don't need a lot of
this. If your app doesn't fit into those categories, then you probably
need at least some, and often all, of those additional features.
I dont know if Postgres, etc. have
these criteria met, but I did find mysql
quite useful.At the end of the day I was
not only able to learn something new and
useful, but I had fun learning it.
Now I think I could swim into some
'serious waters'....
It's excellent that you got into DBMSs this way. Even better if your
courses encouraged you to think properly about your data, what you were
storing it for and what you were going to use it for, thus the best way of
storing it and retreiving it. The problem is, you might bump into the same
"glass ceiling" you hit with MS Access. Maybe you won't. Horses for
courses, after all !
- Tony
[reply]
[top]
[»]
Won't make it?
by Mysidia (J. Hess) - Apr 5th 2002 15:42:50
% OSS options
>At some point, the OSS folks have to admit that they do NOT have a
viable OSS database, or they have to continue with their snot-nosed claim
that they do have one... and then, basically, fail to deliver on this
claim.
>I'm not happy about this. I love PostgreSQL, but it sure doesn't look
like it's ever going to be a player, despite glowing OSS press coverage.
Without the community support, it won't make it. That's a fact, however
unpleasant.
So you're saying the panacea of dbs won't "make it" without community
support. What does a piece of OSS software have to do to "make it" --
just because something is better doesn't mean everyone will use it instead
of something they are using presently (despite its problems), Linux is like
that; I don't see windows users switching en masse to avoid the crashes.
OSS projects don't have to sell things though, they only need a small
userbase, developer support, and distribution channels [like www, ftp].
MySQL has its incompatible "features" (extensions) to SQL that lock
its users in, since applications requiring a DBM use the MySQL API and its
custom extensions (not knowing better, but locking people into it). I
think other OSS dbms would be able to gather more users, if applications
could be used more painlessly between them all.
Perl's DBI/DBD is great, its ashame other languages don't have
db-neutral interfaces like that, and it's ashame that OSS developers write
applications on top of flawed databases.
[reply]
[top]
[»]
Re: Won't make it?
by Charlie - Apr 11th 2002 05:34:48
>
> Perl's DBI/DBD is great, its ashame other languages don't have
> db-neutral interfaces like that, and it's ashame that OSS developers
write
> applications on top of flawed databases.
>
*cough* PHP *cough*
[reply]
[top]
[»]
What about ODBMS and persistency?
by Basile Starynkevitch - Apr 4th 2002 13:55:38
I am surprised that nobody mentions object-oriented database
managment systems (ODBMS) and persistent systems.
ODBMS used to be hot a few years ago. O2 was then a significant
(commercial proprietary) ODBMS system.
Some research projects are about deductive database systems also.
persistent systems give the feeling of persistent data (which remains
after the program ended, and still exists when it restarts). See for
example Shoreand Texas.
There exist also the Orthogonal
Persistence concept. Persistency is vaguely related to object
serialization (customary in Java, Python, Ocaml, ...).
With the current XML fashion, I am wondering why there are no more
open-source ODBMS (which should fit nicely into XML formats). But
developping such a system requires a lot of efforts.
The TUNES site contains an interesting review of related concepts.
I find the current file and RDBMS models rather inadequate for today's
programming challenges.
--
Basile STARYNKEVITCH
[reply]
[top]
[»]
Re: What about ODBMS and persistency?
by Tony Douglas - Apr 9th 2002 08:07:48
Hi there,
I am surprised that nobody mentions
object-oriented database managment
systems (ODBMS) and persistent
systems.
As another poster says, horses for courses. a lot of data that is kicking
about suits the relational model quite well.
ODBMS used to be hot a few years ago.
O2 was then a significant (commercial
proprietary) ODBMS system.
I remember looking into CA's Jasmine (back when it was basically Fujitsu's
ODB-II with Ingres/Net stitched onto the front). It was ok, I suppose, but
at the time I couldn't find a worthwhile project to make me want to use it
more.
The other problem was that at the time there was no recognised standard
for object database languages. SQL is rather like the FORTRAN of database
query languages; it sucks, but at least everybody's had a go at
implementing it (even if fully complying with the SQL standard(s) is
nigh-on, if not completely, impossible).
Some research projects are about
deductive database systems also.
My pet puppy would be completely removing SQL from the scene and replacing
it with Prolog as the query language. Sick puppy or what ;) There has been
some work done on this in the past, but if anybody knows of projects
pushing ahead on this let me know !
persistent systems give the feeling of
persistent data (which remains after the
program ended, and still exists when it
restarts). See for example Shore and
Texas.
Perhaps some of the thunder has been stolen by implementations of
Transparent Persistence in Java, as they seek to provide a (nearly)
invisible link between the mountains of relational data and the (growing)
mountain of object code.
... snip...
With the current XML fashion, I am
wondering why there are no more
open-source ODBMS (which should fit
nicely into XML formats). But
developping such a system requires a lot
of efforts.
Maybe dbXML/Xindice would be of interest to you ? Or perhaps the xmldb
contribution to PostgreSQL ?
... snip ...
I find the current file and RDBMS
models rather inadequate for today's
programming challenges.
This is the most interesting comment ... what is it about the relational
model that makes inadequate for you ? Maybe it's more that nobody's really
made a decent job of implementing the relational model in full that's the
problem ?
I would recommend CJ Date's Introduction to Database Systems to anybody
with an interest in databases (of whatever kind). And also a look at Date
& Darwen's Guide to the SQL Standard, if only for what is possibly the
most poisonous preface ever published in a technical book.
- Tony
[reply]
[top]
[»]
Role of MySql
by astaines - Apr 2nd 2002 18:49:52
MySQL was written to store complex data structures, which didn't change
very often. This is a very common need in the real world.
I use MySQL to hold large tables of epidemiological data. This stuff is
collected once, and selected many many times. I do not need transactions,
I need a fast complex structured data storage system - I need (and dearly
love) MySql. My data may have cost several million dollars to collect, and
there is no possibility of collecting it again - I can't afford data
loss
I wouldn't store 500 million records in it in a fit, but I haven't got
500 million records, and neither do most of you. If you do, go to Oracle,
or Sybase.
Horses for courses, folks!
[reply]
[top]
[»]
No time for CrashGreSQL
by Paul Houle - Mar 28th 2002 14:57:59
or is it CorrupedTablesGreSQL. When I started learning how to use
databases, I believed the propaganda about ACID properties and tried
using PostgreSQL. What a mistake. Every time I had PostgresSQL crash
again and again and often I had corrupted tables.
Then I'd switch to MySQL and it would work just fine.
Then a new version of PostgreSQL would come out and the people around
PostgreSQL would say how great the new version was, how it fixed all the
new bugs, and I'd try a simple query and find that it takes PostgreSQL 60
seconds to do what MySQL can do in 0.1 second.
I can think of a number of major web sites that use MySQL. I can only
think of one that uses PostgresSQL -- the independent media center -- and
they have so much trouble with crashes that they really regret that
choice. MySQL's web site has case studies of major organizations that use
MySQL. PostgresSQL doesn't have any case studies -- maybe that's because
PostgresSQL isn't being used by any major organiations because major
organizations can't accept crashes and corrupted tables.
Sure, PostgresSQL has all kinds of features like subselects and
transactions -- maybe MySQL is 1/2 a database because it lacks them. But
after PostgresSQL crashes (particularly if your tables got corrupted) then
you've got no database and 1/2 is greater than zero.
What particularly angers me is that the PostgresSQL mafia is always going
around using lies and scare tactics. When they talk about performance,
they always mysteriously seem to get 100x better performance than anybody
else does. It seems like crashes and corrupted tables never happen to
them. And then they go blabbering about the ACID property and never
mention that corruted tables break the ACID property.
People are using MySQL because MySQL works. It might not be perfect. But
if you learn MySQL and understand how to take advantage of it's strengths
and work around it's weaknesses, you can build high-performing and robust
applications. PostgreSQL has been around as long or longer than MySQL,
but the fact is that it doesn't work -- at least not for ordinary mortals
who download it, compile it, and try to use it. Maybe there's some
secret about it that they're not telling us. If PostgresSQL can fix the
crashing and corrupted tables, I might give it another chance, but
they've lied so many times about the crashing and corrupted tables I don't
know if I trust them anymore.
[reply]
[top]
[»]
Re: No time for CrashGreSQL
by Tony Douglas - Mar 30th 2002 11:36:23
Hi there,
...snip...
> I believed the propaganda about ACID
> properties and tried using PostgreSQL.
It isn't propaganda, it really isn't. ACID properties are absolutely
essential for the safe, reliable operation of multiple concurrent update
databases. You can waste your life trying to write, test and debug your
own optimistic / pessimistic / whatever locking system, or you can have a
DBMS with one built in, with however many other people working on it. But
you do need one.
> What a mistake. Every time I had
> PostgresSQL crash again and again and
> often I had corrupted tables.
>
I can honestly say I haven't had Postgres do that to me; in 8 - 9 years
DBAing with commercial DBMSs I've had real data loss once and recoverable
corruption (ie. a stuffed cache, requiring a DBMS restart to fix) three
times that I can remember. I can honestly say Postgres hasn't done
anything cruel to me (yet !)
> Then I'd switch to MySQL and it would
> work just fine.
>
If it works for you, great, but I bumped into SQL issues with MySQL so
early that I just went looking for other products; this was back at
version 6.1...
...snip...
> find that it takes PostgreSQL 60 seconds
> to do what MySQL can do in 0.1 second.
>
Yep, that was a real problem. But things started getting better about
6.5.2, and get better all the time.
...snip...
> Sure, PostgresSQL has all kinds of
> features like subselects and
> transactions -- maybe MySQL is 1/2 a
> database because it lacks them.
Subselects not so much (although once you're used to them, they're a pain
to do without) but transactions, 'fraid so as far as I'm concerned.
...snip...
> What particularly angers me ...
Phew, there's a fair bit of heat there - guess you must have gotten really
burned - want to share what happened (so we can dodge the falling tree if
necessary) ?
Bottom line is (as I see it, anyway) :
- if you're in a multiple concurrent write scenario, you need
transactions
- if you're in a mostly read + seldom write scenario, you can probably,
maybe, perhaps (did I caveat that enough ?) work around lack of
transactions; but
- if you're in a read-heavy environment, maybe any kind of SQL database is
overkill, and an LDAP database (which is designed for fast reading and
occasional updating) might be advisable, or even
- if your data is already in XML format, maybe dbXML / Xindice might be an
idea.
All part of life's rich pageant, eh !!??
- Tony
[reply]
[top]
[»]
Re: No time for CrashGreSQL
by hqm - Apr 1st 2002 06:43:48
My experience has been just the opposite of what
you describe. I have been using Postgres
since version 7.1. I have never experienced
a crash nor have I ever had data become
corrupted. I have used Postgres as the back-end for the OpenACS toolkit,
as well as for some embedded applications that require constant inserts
and deletes from network daemons.
The use of subselects, transactions, and
full SQL syntax is a must for me.
I have seen SQL code written by people who use
MySQL, and it is a mess because they don't know how to use basic SQL
features that are not present in MySQL. If you believe that RDBMS ==
Hashtable
then MySQL is probably a good match for you. Otherwise, PostgreSQL is a
very good competitor for
Oracle at the low-end and medium-end enterprise application level.
[reply]
[top]
[»]
InnoDB
by Mark van Beek - Mar 28th 2002 08:55:12
I'm no expert, but I know a (dutch, www.tweakers.net) site that is running
InnoDB and does replication. Can anyone explain this to me and the
relation of it to the db's mentioned here?
[reply]
[top]
[»]
Re: InnoDB
by Joshua Eichorn - Mar 31st 2002 12:57:47
> I'm no expert, but I know a (dutch,
> www.tweakers.net) site that is running
> InnoDB and does replication. Can anyone
> explain this to me and the relation of
> it to the db's mentioned here?
>
Its a new table type for mysql that supports transactions and other
advanced features.
http://mysql.com/documentation/mysql/bychapter/manual_Table_types.html#InnoDB
[reply]
[top]
[»]
Hey you sap! What about SAP!
by Lewis Bergman - Mar 26th 2002 22:27:56
SAP went open source lately. Free for all. I still like PostgreSQL better
(maybe because I know nothing of SAP). But, I don't know many people that
would tell you that SAP isn't one of the most capable DB's in the
world.
I think recommending MSSQL to a client is a disservice. The licensing
scheme is a trap waiting to be sprung. Postgres can easily do well what
MSSQL tries to do well.
[reply]
[top]
[»]
You Say You Want a Revolution (or Dude, Where's My Database?)
by dotslash - Mar 26th 2002 01:51:46
Interesting, but....
Like a previous commenter said, it looks more like a highly opinionated
rant than an actual useful article, more's the pity. Having said that,
there are a few points that I sort of agree with the author. PostgreSQL is
underrated, however it is 600% more scalable than the author is trying to
make it. MySQL is not a true relational database system, but it is
relational enough and ANSI SQL complient enough to make for a really
useful tool. Both have got their place.
PostgreSQL does extremely well in situations where you would typically and
traditionally would have used Oracle/Sybase/Informix, even if it does lack
features that would be needed in an enterprise level RDMS. MySQL is
excellent for web-based content management where transaction locking is
not really needed. The speed and simplicity of MySQL counts heavily in
it's favour here. Insofar sheer speed is concerned, PostgreSQL is doing
some serious catching up - with each new release it's much faster. The
current version actually rivals MySQL in terms of speed!
A few case studies:
Interbase has indexing problems, yes. However, there are ways to work
around that without crippling your database so much that you cannot use
it... Interbase is still one of the fastest RDMS systems around in terms
of bulk data throughput, and that speed can be used to excellent effect in
some situations. For instance, I use Interbase in a traffic logger system
for an ISP to store IP flows measured with NeTraMet. Together they make a
tight team! I tried PostgreSQL, but it did not quite make it. MySQL was
too slow, which came as a big surprise to me. I have no intention (so far)
to do actual tests to measure data throughput, so my experience with the
above system is purely nuts 'n bolts, and the current arrangement works
like a dream.
A number of different clients of my current employer has a number of
franchised branches throughout the world. One client, a chicken-based fast
food chain (not KFC! ;-) uses Linux and PostgreSQL with ISDN links as the
backbone of their entire POS system. The ISDN links proved fast enough and
cost effective too, since they saved a fortune in not having to have
dedicated data links between stores. PostgreSQL replicates it's data
blindingly fast to the company's central PostgreSQL server, proving the
system to be incredibly scalable. An almost identical setup is used at
another client, this time specialising in electronic equipment instead of
chicken! ;-) They also open up branches at the rate of between 2 to 4 per
week all over the world, and this mating of using PostgreSQL/ Linux/ISDN
makes them incredibly competitive. Over here in Africa, PostgreSQL rules
the roost!
I hope that the author would write another article that has some more
useful content and post it here again. It is obvious that the author has
extensive knowledge in database systems, and it would be wonderful if he
can impart with some of that knowledge instead of doing it the way he did.
The article was interesting noise, but unfortunately it is still noise.
Pity.
For a really interesting comparison between MySQL and PostgreSQL, this
time by the MySQL development team, download the MySQL source and read the
"manual.txt" file that comes with it. You'll most probably be
able to download just that file via CVSWeb somewhere, but it succeeds to
be as objective as can be, even from the angle it has been written. If the
author could have written an A vs B comparison like that, my life could
have been a bit easier. Instead I've had to wast my time reading his
piece, and write this comment. Life's a bitch... ;-)
--
Regards,
./
[reply]
[top]
[»]
I did a similar review.
by Tadghe - Mar 22nd 2002 10:38:41
I did a similar review of my own, strictly on OSS RDBMS systems.
Those those that touted SAPDB, I can only say, first install it then look
at the security model then try to like it...
Interbase has probs with indexes, Mysql is still not a true RDBMS, (but is
fast as hell).
in any case you can read my review at http://mordikyn.dynu.com
-
[reply]
[top]
[»]
article? or opinion?
by Stefan Koopmanschap - Mar 20th 2002 07:51:55
though this piece of text was presented to me as an article, it looked more
like a rant, an opinion of someone highly in favor of postgres as opposed
to mySQL or any other database. it didn't really present any useful
information.
why was this published on a site like freshmeat, which normally protects
the high quality of information that is served to it's visitors.
[reply]
[top]
[»]
Hmmmm....
by Tony Douglas - Mar 19th 2002 09:09:51
Interesting article in some ways. I've been asking myself recently,
"why is it I would trust an open source O/S more than an open source
DBMS ?"
The answer isn't too straightforward. Some background first - a couple of
years ago, I wanted a DBMS for a quick development, but didn't want to
start taking up time and space on my production servers, so I had a look
for an open source DBMS to run on a spare machine. MySQL & mSQL I
dropped from consideration fairly quickly for lack of features, so I got
to PostgreSQL. (MySQL may have moved on a bit since.) PostgreSQL supported
a good subset of SQL (and has since added more), and had good support for
ACID properties - essential in a "real" multi-user
concurrent-update database, whatever the MySQL proponents might say. Its
Ingres ancestry was obvious - nice, since we're primarily an Ingres shop.
So in terms of SQL, tools, etc., PostgreSQL wasn't far behind in most
areas (and ahead in some, indeed).
The big difference was scalability & manageability. Discussing open
source databases with management recently, I described PostgreSQL as
having the core functionality in place, but not quite having the
scalability we need, and that managing the databases was like managing a
10 year old version of our current commercial DBMSs.
For example, in Ingres I have tables with between 5million - 30million
rows, striped across multiple disks by the database (e.g. there are
multiple mirrored locations, across which Ingres stripes the tables). I
honestly wouldn't like to throw that much data into a PostgreSQL database.
There also aren't enough index types - there are btree, hash and rtree
indexes, but hash doesn't seem quite good enough yet and isam indexes
(static versions of btrees, effectively) would be a boon - they are a good
compromise in a heavy update environment where data clustering is needed
but maintaining a btree becomes too lock intensive.
Also, PostgreSQL still needs a lot of work in the area of backing up and
recovering databases to known points in time. Ingres, Oracle (and no doubt
all the other major commercial players) have invested huge amounts of time
and money on developing backup, logging and journaling systems that allow
full online or hot backups, plus the ability to restore the database to a
precise moment in time from those backups by selectively applying
transactions from the logs to the database. This is essential, but not
terribly exciting stuff (can you imagine telling a company, "sorry,
there was a database problem but we've recovered it now - can you just
redo today's work, please ?")
However, I do use PostgreSQL for smaller scale jobs, and am very happy
with it (and getting happier with each release). Hopefully at some point
soon it'll gain the "extras" that the commercial DBMSs have, and
I can start thinking about it seriously as an enterprise system.
- Tony
[reply]
[top]
[»]
What about Interbase?
by Mattias Sundberg - Mar 19th 2002 07:48:30
In my opinion there´s no need to use big enterprise databases like
Oracle or the "Dark-Side" MS SQL. Interbase has full support for
foreign keys, stored prcedures and transactions and has somewhat joined
OSS. I do admit that IB is not exactly ideal for web-sites since the
connection-handling is slow (compared to MySQL and PostGreSQL) but for
industrial sites with large databases and much data-altering it does the
trick. Works quite well with PHP too.
[reply]
[top]
[»]
Credit where credit is due
by rz110011 - Mar 18th 2002 05:44:19
I believe it was Dr. E.F. Codd, perhaps this was a typo?
A database can take many forms, but is generally categorized into one of
three slots:
A flat file (Perl does wonders with flat files)
A file-based database (Access)
A true relational database, as described in 1970 by Dr. E.F. Cobb. (MS
SQL, Oracle, MySQL)
[reply]
[top]
[»]
Re: Credit where credit is due
by Sven Wåhlstam - May 28th 2003 03:17:44
> I believe it was Dr. E.F. Codd, perhaps
> this was a typo?
>
> A database can take many forms, but is
> generally categorized into one of three
> slots:
>
> A flat file (Perl does wonders with flat
> files)
> A file-based database (Access)
> A true relational database, as described
> in 1970 by Dr. E.F. Cobb. (MS SQL,
> Oracle, MySQL)
>
>
The key
the whole key
and nothing but the key
so help me Codd.
[reply]
[top]
[»]
MySQL vs commercial products
by Bruce Tobin - Mar 17th 2002 14:05:43
eweek recently did a database shootout test with MS-SQL Server, DB2,
Oracle, MySQL and Sybase. Guess who won?
http://www.eweek.com/article/0,3658,s=708&a=23115,00.asp
[reply]
[top]
[»]
Some answers??
by Gorm - Mar 17th 2002 08:18:01
my $.2
1. Why can't OSS databases match commercial databases in the same way
Apache meets/beats IIS and/or iPlanet (née Netscape)?
- The OSS databases do not have support from alot of 3rd party tools. This
is getting better, but its still alot of problems out there. MySQL is a
hardcore database that until some months ago lacked alot of funtionality
that make it hard to use in ebiz. Postgress have had some of this
functionality (FK and triggers) for some time but it got other
problems.
2. What database should I use?
- I think it's important to look on databases as something transparent.
The different databases all got positiv and negativ things bound to
them.
Until Pear::DB came PHP had big trouble with this transparency. Perl got
their DBI and this is very cool. I also find that most OSS developers have
great pain adopting new technology (I use emacs, but the guys that started
earlier than me still use vi as their main editor). When something
"works" for a OSS "hacker" it's very hard to replace
it.
Its also very hard (read: nearly impossible) to convert a big Microsoft
SQL databases with SP, Views, ER to MySQL. This will change when MySQL
supports the minimum funtionality needed to run a ebiz app.
[reply]
[top]
[»]
A Few Fundamental Misunderstandings
by Robert Uhl - Mar 16th 2002 22:56:52
This article has a few misunderstandings in it whose ramifications, I
think, cast some doubt on the veracity of its conclusion.
While you can debate the veracity of the "Information wants to be free"
manifesto (I think it should read "I want all information at no
cost")...
That particular slogan means that information does not want to be
enslaved, not that it wants to cost naught. It refers to the fact that
information is inherently transmittable, and that attempts to hamper its
spread are tantamount to shackling a man. The side effect of this fact is
that folks can receive information for no cost.
Are there really any valid OSS choices? I don't think so.
You say this after stating that PostgreSQL is an exceptional database.
Why is it not a valid free software alternative? Your reason seems to be
simply `not enough folks use it.' So what? Let it be your competitive
edge.
Software is a tool, not a religion.
Granted, so far as it goes. But usefulness as a tool is the reason for
the religion. Proprietary software is simply not as useful in the long term
as is free software. That's a fact of nature.
Incidentally, I would set my mother up with pine; she's much less
likely to screw it up than Netscape Mail...
While most companies/individuals are too narrow-minded to mix OSS
with MS products...
Why is it narrow-minded to mix free software with proprietary software?
Perhaps one has come to the realisation that the disadvantages of free
software are minor and those of proprietary software are major.
Incidentally, if mySQL is so primitive, why then can it so successfully
run a site as popular and well-visited as Slashdot with issues?
[reply]
[top]
[»]
Postgres is *OLD*
by DataMoist - Mar 16th 2002 22:32:27
You may have heard of Postgres only recently, but it's been around for
almost 20 years. A Short
History Of Postgres.
P.S. This article was shite. The whole point of Open Source is to be a
meritocracy. People who are loud but can't code should move into politics.
--
-- DataMoist -- The revolution will be packetized
[reply]
[top]
[»]
Freshmeat Made a Mistake Publishing This
by jonesy - Mar 16th 2002 21:27:02
This guy has obviously no knowledge of the database software industry, the
database consulting industry, or the vertical markets involved in the
aforementioned (like, say, the financial or insurance industries which
partially fuel the market). In addition, this person is obviously not a
very experienced writer.
First of all, the article, overall, lacks any kind of focus. There's a
thing writers call 'revisions'. We write our first drafts like the above
article: 'stream of consciousness'. It makes sense while we're writing
it, and then we walk away from it for 20 minutes, come back to it, and it
makes, of course, no more sense than a Slashdot comment. We go back
through, cut out the extraneous crap, tweak here and there, add some order
to the content.... rinse, repeat....
Second, there are glaring issues with the subject matter. Do you want to
talk about databases in any particular context? If so, it's rare that
you'll find Oracle and Access in the same article. If you want to talk
about MySQL and the OSS community, there's a reason it was embraced in
spite of the features Postgres came to the table with. Namely, a lot of
people didn't need those features, and therefore didn't want the overhead
or added administrative hassle/learning curve associated with them. MySQL
is very compact, has a small footprint, is very fast, and if you don't need
triggers/stored procedures, is fine for just about anything. If you don't
believe me, send email to Yahoo and ask them how their financial site is
doing. It runs on MySQL.
If you do need enterprise features, there are many other options you miss,
and many insinuations you make that make it obvious that you're highly
influenced by industry rags, slashdot and other things unrelated to actual
experience in the field. Have you ever heard of Sybase? Did you know that
MS SQL was sold to MS? Do you know that it was sold to them by Sybase,
and that it's essentially version 4 of Sybase's version 12.5 product?
Do you know how the market breaks down in terms of Oracle vs. Sybase? The
long and short of it is that Oracle grew to Sybase's size by feeding on the
dot com boom. They never took any significant market share from Sybase in
their core sectors, because Sybase has more history in enterprise
scenarios, has more history running on the Sun, IBM and HP platforms, and
has never been shown to be slower than Oracle in any test that I'm aware
of. In addition, Sybase ASE 12.5 is available for Linux. So is DB2
(that's an IBM product). DB2 is an insane product. I would go into their
query optimizer, but I don't suppose you know what that is.
Here's the deal. Screwdrivers are tools, but you don't use a flathead to
do a phillipshead's job. Just the same, You don't grab Oracle or Postgres
when MySQL does the job. If you grow out of MySQL (the fewest features,
but one of the smallest footprints and by far the easiest to get up and
running 'today'), there are plenty of other alternatives out there to turn
to without going to MS SQL (one of the least scalable and feature filled -
and one of the slowest databases out there).
That's all I have to say about this. If I could nail down the intended
audience or the intended direction of the article, I might say more.
[reply]
[top]
[»]
Re: Freshmeat Made a Mistake Publishing This
by ozten - Mar 20th 2002 23:58:22
I agree.
Why was this published?
It is more of a comment than an article.
--
In Soviet America, democracy chooses You!
[reply]
[top]
[»]
Re: Freshmeat Made a Mistake Publishing This
by jeff covey - Mar 21st 2002 07:32:37
> Why was this published? It is more of a comment than an article.
Then write something better for me. :)
--
vs lbh pna ernq guvf, lbh'er n trrx.
[reply]
[top]
[»]
Re: Freshmeat Made a Mistake Publishing This
by Robert Trebula - Mar 22nd 2002 09:53:40
>
> % Why was this published? It is more
> of a comment than an article.
>
> Then write something better for me.
> :)
>
Has freshmeat come to such state that *anything* is good enough to be
published?
Hey! The article isn't worth the T-shirt you gave to the author.
I think this is a general issue - the value of articles being published on
freshmeat goes down and down. And I mean this as a friendly advice, not a
flame.
Robert
[reply]
[top]
[»]
Re: Freshmeat Made a Mistake Publishing This
by jeff covey - Mar 23rd 2002 11:43:18
> the value of articles being published on freshmeat goes down and
> down.
I don't think that's true at all. Take a look at http://freshmeat.net/articles/
and compare it to what we were publishing three years ago (in the back
of the editorials section). We're covering a much broader variety of
topics now, and I think the overall quality is quite good. If we
occasionally come up with one that you think is unworthy, well...
sorry, but don't judge the rest by it. :)
--
vs lbh pna ernq guvf, lbh'er n trrx.
[reply]
[top]
[»]
Re: Freshmeat Made a Mistake Publishing This
by Randall Randall - Mar 22nd 2002 14:20:19
> Here's the deal. Screwdrivers are
> tools, but you don't use a flathead to
> do a phillipshead's job. Just the same,
> You don't grab Oracle or Postgres when
> MySQL does the job.
Recently, after using PostgreSQL for two years because of the questions
about whether MySQL had transactions, etc, I decide to begin using MySQL
more, for those applications that don't involve financial transactions. I
found that it crippled me to work with MySQL. How can you build a complex
query when you don't have subselects? The alternative is to have lots of
smaller queries and build the later ones based on the former, but this has
two problems: It's far slower than just one query, because of the overhead
involved in calling out to a database, and, you have to write extra code in
the calling language (Python, RXML, Pike, whatever) to make up for the lack
of subselects. This slows down web development considerably, in my
experience. Anyway, since the recommended solution is to do more database
queries to make up for not being able to do complex queries, I gave up and
went back to PostgreSQL, which, after all, is fast enough.
--
--
Randall.
[reply]
[top]
[»]
Re: Freshmeat Made a Mistake Publishing This
by David Ross - May 3rd 2002 14:29:58
> This guy has obviously no knowledge of
> the database software industry, the
> database consulting industry, or the
> vertical markets involved in the
> aforementioned (like, say, the financial
> or insurance industries which partially
> fuel the market). In addition, this
> person is obviously not a very
> experienced writer.
>
Keep the flames down there. I happen to agree that the author explained
things better in further postings than the original article, but I think
you'e gotten carried away. I don't see your credentials listed here
either...
> Have you ever heard of
> Sybase? Did you know that MS SQL was
> sold to MS?
> Do you know how the market breaks down
> in terms of Oracle vs. Sybase? The long
> and short of it is that Oracle grew to
> Sybase's size by feeding on the dot com
> boom. ...
<b>*mini flame on*</b>
and on and on... Geez, who cares! So you like Sybase! That's great!
Are we still in a context here, or are you just "streaming
conciousness"!
<b>*mini flame off*</b>
Sorry, but that really was ridiculous, if not verging on hypocritical.
I'm no expert, but I think you've missed Oracle's history by a long shot.
Oracle was big before dot-com was even a catch-phrase - when the Internet
was email, ftp and gopher (I was actually a user then, so I know what I'm
talking about). I know almost nothing about Sybase (perhaps this is one
of their problems - marketing?)
I happen to agree that the author's original article spent too much time
shooting down MySQL and praising PostgreSQL without much meat as to
why/when, but as I mentioned - I think that was explained in further
postings. I actually am very interested in exactly the reasons for his
feeling the way he does (and other posters facts or examples as well).
There have been subsequent posts with real life examples that have been
quite helpful. Perhaps you were trying to say this, but in a rude,
overheated, 'stuck in your own little world' sort of way?
[reply]
[top]
[»]
Sheesh, drink some coffee before you pour your brains out.
by Bobski - Mar 16th 2002 19:05:58
I mean, really. You come so close to 'stream of consciousness' I wonder if
you just dropped out of bed when you started writing.
"Software is a tool, not a religion", you say, but the overall
tone of your article is nothing but MySQL bashing and PostgreSQL praising,
sprinkled with homage to Microsoft.
Your thoughts scatter, your pointed lists are pointless.
Was there some locus that is lost in all this grandiloquent reverie?
[reply]
[top]
[»]
Equating popularity with suitability? Wrong.
by Schwern - Mar 16th 2002 18:19:14
This editorial is asking the question, "What are the database choices
for an OSS project?" And it comes to the conclusion "the
existing OSS database are unsuitable, consider MS-SQL".
This conclusion comes through a process of elimination. MySQL is
eliminated on the grounds that its generally "weak". Arguable,
but fine. SAP DB, as was pointed out, is ignored as are several others.
But I imagine they would be eliminated for the same reasons PostgreSQL
was.
PostgreSQL is eliminated. Why? Because its missing features? No.
Because it can't go toe-to-toe with commercial databases? No. The author
clearly states that it has "the features of an enterprise-class
database". It is eliminated because its not popular.
Hold on. Can't use a piece of software because it's not popular? This is
a very, very dubious way to select anything. A conveniently
self-fulfilling prophesy. There's no sign of PostgreSQL development
slowing. No worry that the group might go under for lack of interest (as
there might be for a commercial DB). Its easy to install (I installed
mine with a few keypresses from a Debian package) so that's not a problem.
SQL, as fractured as it is, is still a lingua franca, so there's not the
same problem finding DBAs for underused databases like there is for
underused programming languages.
So the editorial's conclusion is PostgreSQL should not be used because it
is not used. Like the converse of the old joke: Nobody drives in New
York City, too much traffic.
With this part of the argument chopped out PostgreSQL reenters the running
and the editorial's conclusion is bunk. When placed against the offered
commercial databases, it has the features, it has the speed, it has the
reliability and the price is certainly right. No need to invoke
religion.
[reply]
[top]
[»]
You forgot Mimer
by Jensus - Mar 16th 2002 16:02:23
If I have to choose between MsSQL and Oracle, I would choose Mimer
http://www.mimer.com/
Mimer is probably the most standards compilant database available. It is
also very easy to set up and aministrate.
Mimer is unfortunately not OSS...
[reply]
[top]
[»]
I dont necessarily agree
by RC - Mar 16th 2002 13:17:35
What does this all mean? That OSS databases are really not ready for prime
time in the way that
Apache, BSD, PHP, and other OSS tools are, and, to me, that we are way
past "well, it'll be kewl in
a few months when we [whatever]". OSS database developers -- and
especially users -- have failed
to develop/embrace good DB tools. This is a fatal flaw in OSS; it leaves
the door open to
commercial, very non-OSS products.
Says who? YOU? Your real complaint is the
lack of graphical tools isn't it? To which any decent
DB programmer/admin doesnt need such tools. You can
get your graphical tool using Tora which will talk with Oracle,
Mysql and Postgres. but even without Tora theres more
than adaquate tools available. Sorry if they are not point and click.
Thats _YOUR_ problem.
Mysql and Postgresql are more than capable databases.
Would I use them to store say 500 million records? I'd be more
inclined to choose Oracle instead. See the issue isnt one of
_maturity_ of the OSS tools, it's one of _support_. The oss databases
are _more_ than capable of doing the job. The issue is
one of_exposure_, _training_ and _support_. Period. For many who
have talented staff, this is already taken care of, for others,
they need to rely upon support services offered by others.
To Imply that OSS DB's are inadquate is just wrong.
I think as systems like Linux make more inroads
into the marketplace, Developers will get more exposure
and experience with these tools. The tools themselves
right now, today are more than adaquate for most
jobs.
.
While most companies/individuals are too narrow-minded to mix OSS with MS
products, this is
often a good solution, especially for middle-range companies (that cannot
afford Oracle).
First. its not a matter of narrow-mindedness, many simply
do not have the staff that can handle non-out-of-the-box solutions.
Thus the real issue is a lack of exposure to these tools. Again,
at lest in terms of Linux, most modern distros are bundling
Mysql and Postgresql together. So I think over time these
tools will gain more exposure, and thus more use in
different commercial projects.
Second, Oracle license is not all that expensive. It _DOES_
require someone with knowledge and experience. I can't imagine
_any_ company entrusting their valuable data to someone who was
_not_ knowledgable and who had _little_ exerience in DataBases.
Clearly you may have a valid complaint due to the fact not
a lot of companies are deploying their software to use OSS
databases. For example Oracle deploys Apache in its
IAS9i portal product. So point well made, but I think
Databases are of a different nature than Apache or Samba.
Perhaps over time we will see more vendor support of these free
databases, after all Postgres is not all that radically different from
say
Oracle in many ways. But still, I firmly believe the main problem with
OSS Databases remains one of support.
[reply]
[top]
[»]
DB2 Universal?
by Toby Haynes - Mar 16th 2002 11:44:37
Is there some pariah status accorded to DB2 Universal, or was it just a
major oversight on the part of the author? How can you omit the database
with the largest market share in an article on OSS and commercial
databases? And its cheaper than Oracle.
Other omissions are SAP DB which got GPL'd some time ago. There are the
other major database products out there like Informix and Sybase.
Now I'd quite like to see improvements in the capabilities of the open
source databases but my hands are tied - my day job is developing DB2
Universal so I really can't work on any opensource DB without a serious
conflict of interest. On the other hand, there are open source (and even
GPL'd) options out there which do the job well enough for most setups out
there. For a lot of cases, the database is doing little more than ensuring
the data's relational integrity. As people need more fully fledged
solutions, either they will turn to a commerial DB to plug into their
established SQL routines (Aren't standards wonderful things?) or will push
one of the opensource developments along by commiting resources to that
project.
Cheers,
Toby Haynes
--
These are my own opinions and not necessarily the
opinions of IBM Canada.
[reply]
[top]
[»]
Re: DB2 Universal?
by Infidel - Apr 12th 2002 03:22:18
% Other omissions are SAP DB which got
> GPL'd some time ago. There are the other
> major database products out there like
> Informix and Sybase.
I think the ommission of Informix may have been due to the fact that it is
no longer a supported product (having been bought out by IBM then
turfed).
Now that was a DB I had a lot of respect for...especially after some of
the punishment we put it through, without any down time whatsoever, over a
3 year period (other than one unmentionable occurance which resulted in a
junior DBA having his hands severly slapped).
This brings to mind a question: Why doesn't IBM release Informix to the
open source community?
It would, to say the least, earn them some major brownie points.
Andy
[reply]
[top]
[»]
Re: DB2 Universal?
by tarame - Apr 21st 2003 17:03:26
Informix is alive and quite well. IBM has continued to enhance Informix.
[reply]
[top]
[»]
SAP DB
by alinv - Mar 16th 2002 09:17:49
What about SAP DB?
It looks to me like a good candidate for the OSS
options.
[reply]
[top]
[»]
Other options
by apuma - Mar 16th 2002 07:46:01
Take a look to firebird
http://www.ibphoenix.com/ibp_act_db.html
[reply]
[top]
[»]
Re: Other options
by Thomas Hays - Mar 16th 2002 16:54:37
I also have used FireBird on several projects and it works well. It's fast,
relatively easy to set up, supported by Java (use the newer client-java
JDBC driver from CVS, not interclient), Perl, PHP, and probably others. It
is also self-tuning and is as close to a dba-less install as you can find.
One nice thing I like is that it stores the entire database in a single
file which (in my view) makes things easier to keep track of. FYI: the
official web page is at http://www.firebirdsql.org/
[reply]
[top]
[»]
good and bad vs right and wrong
by Rizen - Mar 16th 2002 01:34:26
The author makes some very valid points: Like MySQL isn't as feature-rich
as PostgreSQL or Oracle; and that M$ need not always be a dirty word.
However, I think that there are a few larger points that he's missing.
=begin rant
1) Apache existed before IIS. That gives it a competitive edge in market
dominance. PostgreSQL and MySQL are just babies in comparison to the age
of Oracle. Does Oracle have more features than the OSS dbs? Of course it
does! It's more than twice the age of the two of them.
2) All the proggies out there that are capable of using only one database
are simply poorly designed or half-hearted hacks. Why should the OSS
community necessarily adopt only OSS databases? Sure it should have them,
but that doesn't mean it should play only with them.
3) While I agree that MySQL is missing major features that PostgreSQL has
(and even more-so with MSSQL, Sybase, Oracle, etc), I'd say that it's not
necessarily playing to the same audience as the rest. MySQL is and always
has been all about the speed. If I want the features of PostgreSQL, I use
it, but if my foremost concern is speed (which on the web it usually is)
I'm gonna go with MySQL 10 out of 10 times. It's not that I have any
warm-fuzzies about MySQL over PostgreSQL, I just use the tool that's right
for the job.
4) The author said "if money and personnel are no object" you
should go with Oracle. I'd say that Oracle is overkill on all except the
very largest of projects. PostgreSQL easily has the features to take on
most of the jobs you'd want to run on an Oracle server. And it doesn't
have that $100,000 (exageration) license fee attached.
5) And finally, while PostgreSQL hasn't had quite the following that MySQL
has had, it is certainly not being ignored by the OSS community. In fact
one the the biggest OSS players in the game (sourceforge.net) runs on
PostgreSQL. If PostgreSQL was as easy to set up as MySQL, they'd be on
equal ground.
=end rant
--
Those who say it cannot be done should not interrupt those who are doing it!
[reply]
[top]
[»]
Re: good and bad vs right and wrong
by Jeremy Guthrie - Mar 16th 2002 06:58:41
% 3) While I agree that MySQL is missing
> major features that PostgreSQL has (and
> even more-so with MSSQL, Sybase, Oracle,
> etc), I'd say that it's not necessarily
> playing to the same audience as the
> rest. MySQL is and always has been all
> about the speed. If I want the features
> of PostgreSQL, I use it, but if my
> foremost concern is speed (which on the
> web it usually is) I'm gonna go with
> MySQL 10 out of 10 times. It's not that
> I have any warm-fuzzies about MySQL over
> PostgreSQL, I just use the tool that's
> right for the job.
Postgres has been MUCH faster than MySQL since 7.1. Go find independent
benchmarks, many out there show that.
> 5) And finally, while PostgreSQL
> hasn't had quite the following that
> MySQL has had, it is certainly not being
> ignored by the OSS community. In fact
> one the the biggest OSS players in the
> game (sourceforge.net) runs on
> PostgreSQL. If PostgreSQL was as easy to
> set up as MySQL, they'd be on equal
> ground.
Postgres isn't hard to setup, it's just as easy.
[reply]
[top]
[»]
Re: good and bad vs right and wrong
by Ben Reed - Mar 17th 2002 00:36:06
> If PostgreSQL was as easy to
> set up as MySQL, they'd be on equal
> ground.
I still don't understand this... I've heard it a number of times, but when
I was new to databases (and tinkered with both mysql and postgresql),
postgresql's well-documented CREATE USER and GRANT functions made a hell
of a lot more sense than the strange mixture of programs, database tables,
and other stuff it took to make new users in mysql; and initdb/createdb
seems pretty self-explanitory. No harder than "mysqladmin create
[db]".
MySQL has since added a lot of stuff to their documentation, but it used
to seem like they purposefully used big words for common things in their
manual so that searching the manual for keywords was very difficult. But
overall, postgresql never seemed any harder than mysql to me, just
different. And they were both very different from oracle (the only other
database I had worked with), so it's not even like one had the advantage
of familiarity from that...
[reply]
[top]
[»]
PostgreSQL
by Steven Scott - Mar 16th 2002 00:34:05
...is great. I started out on MySQL a couple of years ago, and that was my
introduction to SQL and RDBMSs. When I got a job in the field, working
with DB2/Sybase/Oracle/MSSQL, I realized all that was missing. So I've
begun a concentrated effort to use Postgres for everything. My instance
of (shameless plug) MÆS runs only on
postgres, now, and it's made me realize bugs I need to fix and how
terribly I'm under-utilizing postgres by adapting a mysql app to work with
it.
anyway, everybody who uses mysql should take the time to sit down and
learn postgres. the worst thing about it is the security, what usernames
and password scheme you should set up, but once you're over that hurdle
it's cool.
[reply]
[top]
[»]
Pulll-----eeease!
by Jim Nicholson - Mar 16th 2002 01:15:26
The author repeatedly claims that MySQL is somehow inadequate, but he
doesn't make his case. Why does MySQL have the market penetration that it
has? Because it's cheap, easy, and does what people need it to do.
Why have so-called "key parts" of the formal RDBMS definition been late in
coming to MySQL? Because demand for those parts was late in coming -
because people found that MySQL implemented enough of the relational
model to be useful, even if it lacked transactions (since added) or
replication (on the way?)
The fact is, in the normal course of events, even a developer working with
commercial RDBMS offerings should be worrying very little about
things like replication, transactions, foreign keys, etc.. Many of the
better development efforts I've been involved in (I've been in the field
since 1981 as a developer) have used stored procedures for virtually all
database access, so that the application code contains not one line
of SQL. Such approaches treat the database as an object, even if the
underlying language technology is not OOP; the job of working out
the details of what gets stored where and who can update what fields and
such is left to the DBAs. And DBAs as a group are remarkably under-exposed
to and under-represented in the open source world, which probably goes
further to explain why none of the OSS database offerings have all the
features of commercial products.
Sorry, I just don't buy the "open source tools are inadequate for the
task" schpiel. Open source is the one place in the software universe where
the extant code base substantially meets the requirements. That's because
the sole point of the code is to do so, unlike commercial software; any
given open source program exists because someone had a need to fill. In
the commercial world, factors like vendor profitability and
pointy-haird-boss-buzzword alter the equation, . Is Oracle a good product?
probably so. Will I ever use it? I have. Will I ever use all of it?
Nope. Probably not even touch on most of it. But I know that if I need to
build a prototype to specs given to me at 3pm for a demo tomorrow at noon,
I'll probably use MySQL. That way, I get to go home by 7pm and play with my
kids.
--
- Jim Nicholson
[reply]
[top]
[»]
Re: Pulll-----eeease!
by Stephen Ramsay - Mar 16th 2002 07:59:42
> The fact is, in the normal course of
> events, even a developer working with
> commercial RDBMS offerings should be
> worrying very little about things like
> replication, transactions, foreign keys,
> etc..
Really? A developer should be worrying very little about race conditions,
redundancy, and referential integrity? Remind me not to hire you the next
time I need a database!
I really suspect that most people out there are building flat schemas with
a couple of relations kinda sorta normalized out to first normal form.
Building a real system (not necessarily a big one, just one that takes
advantange of the relational model) requires all of the stuff you mention.
A database without foreign keys is not a relational database. You might
as well store your records in a Perl hash.
PostgreSQL wins on every count, and it's very fast. If speed were the
main concern, everyone should be using msql or Berkeley DB. I suspect
that as with all things in computing, there are lots who know how to do
it, but a significantly smaller subset who know how to do it
well.
--
Stephen Ramsay
Senior Programmer
Institute for Advanced Technology in the Humanities
University of Virginia
[reply]
[top]
[»]
Re: Pulll-----eeease!
by vidarh - Mar 20th 2002 13:40:48
> Really? A developer should be
> worrying very little about race
> conditions, redundancy, and referential
> integrity? Remind me not to hire you
> the next time I need a database!
>
> I really suspect that most people out
> there are building flat schemas with a
> couple of relations kinda sorta
> normalized out to first normal form.
> Building a real system (not necessarily
> a big one, just one that takes
> advantange of the relational model)
> requires all of the stuff you mention.
> A database without foreign keys is not a
> relational database. You might as well
> store your records in a Perl hash.
>
> PostgreSQL wins on every count, and
> it's very fast. If speed were the main
> concern, everyone should be using msql
> or Berkeley DB. I suspect that as with
> all things in computing, there are lots
> who know how to do it, but a
> significantly smaller subset who know
> how to do it well.
>
If you read the post you responded to again, perhaps you'll see the
section where he is pointing out that most of the relational DB stuff can
be placed in stored procedures and "hidden" from the application
developers. He advocated letting the DBAs worry about the database, and
letting the application developers worry about application logic.
[reply]
[top]
[»]
Re: PostgreSQL
by Grant K Rauscher - Mar 16th 2002 01:55:36
I certainly agree with Jim Nicholson's response (above), yet most projects
aren't lucky enough to have DBA teams, much less organized ones who are
able to abstract all SQL out of development! A great many projects should
not require so much focus on something outside the scope of the project...
unnecessary complexity, but what is the solution?
I'm strongly influenced by licensing restrictions, as the author of the
article appears to be, but as the article wisely states it is imperative
to choose the right tool for the job. I realize that eventually many of
us do choose software based on licensing, increasingly of late, but I
don't believe it to be the primary factor overall - yet or perhaps
ever.
object
and xml databases are a
more natural fit for most use cases than relational
ones, which are built for efficiency of execution, not development and
maintenance. RDMBSs are useful for large corporations and have
tailor-made solutions for almost every statistical analysis scenario, but
are not as aptly applied to web development, embedded
applications/appliances, distributed services or even what databases are
designed for : persistence and organization.
relational databases are basically 2-dimensional matrices with pointers...
high-class spreadsheets. object
and xml
databases are more likely to accept the architectures and data models
you're working with every day, and are more adaptable, flexible and
customizable : you'll be able to apply extreme programming principles and
add fields as you go, connect to other systems and maintain focus on your
data model and your project, not that of the database and the best
possible model that fits into that database.
before choosing to ignore this suggestion and go back to relational
databases, struggling to fit your designs into its data model, consider xml and object
databases. import/export from/to RDBMSs is straightforward, and has been
set up in real-time to truly garner the design/maintenance benefits of
OODBMSs while retaining the atomicity and existing relational tools
without sacrificing data quality and currency.
[reply]
[top]
|
