[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian sarge Mysql 4.1 (Too many connections)




On Wed, 9 Aug 2006, Roberto C. Sanchez wrote:

On Wed, Aug 09, 2006 at 08:13:58AM -0400, C. Jon Larsen wrote:

On Tue, 8 Aug 2006, Roberto C. Sanchez wrote:
I guess I was being a bit flippant.  Sorry for that.  However, I stand
by what I said earlier that there is no good reason to develop web apps
which are not portable across databases.

Hmm, you must like writing lots of extra application code, and doing lots
of work outside your database engine where (can be) much less efficient.
Portability is nice no doubt, especially for simple or trivial apps as you
want your customers to be able to run their db engine of choice.

I am not a fan of writing extra code.  However, I am willing to do some
work to get portability when it is possible.

But ...

You must counter balance that with the fact that for more advanced
applications where stored procedures, triggers, views, transactions, and
other custom features your RDBMS engine can provide (that are NOT
standard across all engines) that might make your app far more efficient
would go unused as you re-implement the wheel (almost always with more
verbose code that runs far slower and makes far more round trips between
the app and the db).

You make a good point about advanced applications, but wouldn't you
rather use a database that didn't take 10 years of being criticized to
implement those features (which are arguably staples of any RDBMS)?


Who said I use mysql :)

Check out Firebird RDBMS :)

Seriously, MySQL5 has a lot of the features now where its almost on par with postgres. Any one of Firebird, Postgres, or MySQL5 would make a good choice.

When your data sets that your app is manipulating get large, they probably need to be normalized. When you normalize, you're going to want views, SPs, triggers, FKs, transactions, etc. At that point you dont think about your "base of data" as "database agnostic" in many cases because to get good performance you're probably using bells and whistles specific to the engine.

Thats o.k. as long as everyone knows that up-front.


I'm not saying portability is not a good goal. It is, but its not always
the most important consideration. And as your apps get bigger I'd say it
decreases in importance.

Portability may decrease in importance as the size of the project grows,
but I would argue that it should *increase* in importance.  My rationale
is this: small projects can be easily ported to another platform, but as
the project grows bigger it becomes more difficult to port after the
fact.  I know that many people are scared about Oracle's acquisition of
Innobase and Sleepycat and what that means for the future of MySQL.
Now, I don't think that this will end up making MySQL non-free tomorrow,
but I would hate to be stuck in a situation like that if it were to
occur.

Look at how many people would like to move to anything other than
Windows, but they are tied down by non-portable proprietary software.
I'm just saying that we know better and yet we still conciously make bad
choices.  I know that you pointed out that complex apps may benefit
greatly from making use of custom features or features in one particular
database.  However, I think that those are by far the exception.

Just my 2 cents.

I'll see your 2 cents and raise you 2 cents.

Regards,

-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto




Reply to: