Image of the glider from the Game of Life by John Conway
Skip to content

Managing LARGE Databases Continued

Well, I don't have much to report so far, other than OpenOffice.org still has a lot of bugs when it comes to it's Base program.  First off, before throwing the 3.4 million record Tennessee database at it, I thought I would try a much more compact database in dBase format with only a few thousand records.  Needless to say, it c...r...a...w...l...s.  If Paradox is like a cheetah running at 45 miles / hour, then SQL Server 200 is like a man lightly jogging at 11 miles / hour, while OpenOffice.org Base is a three-toed sloth taking a holiday. It is painfully slow.  And, when up and running, it constantly crashes, which means more time spent re-importing the database and starting over.  It blows!  Of course, the culprit is the Java Virtual Machine (JVM).

While the programmers at Sun Microsystems want to keep an application platform independant, deciding to base the entire OpenOffice.org infrastructure on the JVM is a poor decision.  While is runs at almost native speed when compared to Brand M Office, it has its limitations.  Base is one LARGE limitation.  Sure, I can develop robust, light and scalable database applications complete with reports, forms and queries.  Heck, it can even keep up with commercially driven database applications if you know what you are doing.  But begin to increase the size of the database anywhere past 1,000 records, and you have nothing but headache on your hands.  Which is unfortunate, as I love this application suite.

So, I won't even bother trying to import the Tennessee database using Base.  Instead, I am on to MySQL and PostgreSQL, as they are much more robust SQL applications.  Honestly though, I never expected to use OpenOffice.org Base to begin with.  I was just curious about it's speed, and boy did I find out.

{ 4 } Comments