Re: Oracle->Btrieve

From: Bill Bach <bbach_at_cncdsl.com>
Date: 20 Mar 2001 02:41:40 GMT
Message-ID: <3AB6C364.3AA45759@cncdsl.com>

This is like the question -- Which is better, a Porsche or a truck? One is certainly faster, but the other can hold many times more things in it. With Btrieve and Oracle, it is the same -- both excell in their own specialty areas.

Btrieve is a record manager -- plain & simple. Its strong points include speed & flexibility for the developer, along with scalability from the single laptop to the largest client-server systems. (My customers run the gamut from 1 to 1200 users, with a large majority in the 50-100 user range.) It sports a very simple API for programming -- too simple for some developers -- with very low overhead. Access is primarily navigational in nature for 80% of applications in the "real world" today. Pervasive.SQL 2000 includes Btrieve 7.82 (7.9 to be released soon) and a component called the SRDE, which looks to provide an ANSI-92- and ODBC-compliant relational front end. Newer app-dev tools are available to simplify relational development, but still suffer from some difficulties and limited functionality.

Oracle is a powerful relational database manager. Its strong points include a wealth of available DBA expertise, ease of application development, lots of books and other reference materials, and some pretty powerful tools, especially for large data sets and data warehousing. All database access is fully relational, as there is no navigational API set readily accessible.

Platforms are similar, with Pervasive.SQL running on Linux, Solaris, NetWare, and Windows NT. I believe (an Oracle oracle should correct me) that Oracle is good to go on Solaris, NetWare, Windows NT, and more of the higher-end platforms. Oracle will gain much more from SMP servers.

Performance numbers vary, depending on the work. I have one customer who's done a ported app from Pervasive to Oracle. They indicate that Pervasive blows the doors off of Oracle for all simple queries and direct access (even via the SQL engine). However, as the queries become more complex, Oracle shows no signs of slowing down while Pervasive gets "mired in the sludge." They also note that Oracle's hinting capabilities can provide some of the speed back for simple queries -- it just seems that Oracle has a rather unsophisticated optimizer with the simple stuff.

So, the best that I can (safely) say is that they are different. While avoiding the statement on which is better, I'll answer the questions you pose:

Ilya Kuzkin wrote:

> Hi, All!
>
> Might happen that we will choose a different client application which is
> built on Btrieve API and eventually requires a Btrieve backend. We are
> running Oracle 8.0.5 now. I've found some information about binding Btrieve
> and Oracle but couldn't really find any description of different concerns
> and possible problems. So, here I am.
>
> My own concerns are :
>
> a) is Btrieve/Pervasive able to store tables and manage indexes of the
> tables of 40-50 mln records (20-40 columns) in multi-user environment. The
> current nature of an application is as follows: several processes are
> working extensively on importing, querying, modifying and making heavy
> calculations on the data. And, yes, some of the tables are 40 mln records. I
> am not really sure about new application, but I believe, architecture will
> be the same (or similar).

The maximum single Pervasive database file size is 64GB. There are some smaller limits given certain file constructs, but it is possible to create a maximum of a 64GB file. Since Pervasive databases can contain as many files as needed, systems which require more than 64GB can always split a large table into multiple smaller tables using hashing algorithms. (This was often used to get around the Btrieve 6.x limit of 4GB and an older 2GB limit on some 5.x files.) These files are stored in multiple "physical" 2GB files for platform independence, but are all accessed transparently as a logical unit by the application. Btrieve files are identical across platforms -- so migrating from WinNT to NetWare (or even to a laptop) requires merely copying the data files & application over.

> b) Should I expect any productivity decrease under the conditions stated
> above after switching to Btrieve/Pervasive

This all depends on the application design. An app which simply is inserting records (i.e. data collection, shop floor control, accounting, etc.) is extremely fast in Btrieve, whereas Oracle must re-parse every new SQL statement for even a single record insert. However, an app running a mass-change or running reports across a large data set may be faster with Oracle.

> c) Can anybody mention any benefits (I'm aware about the price quotes
> difference).

I tried to do this above -- don't know if I did a good job or not. One which I failed to mention is administrative costs. Given a solid server platform, beyond the initial setup and a bit of tuning (which may not even be needed), there is little for someone maintaining a Pervasive database to do. Ongoing costs are almost NIL. There are some administrative training courses available (The Pervasive Service & Support courses), and I strongly recommend them, but most problems that people have are unstable server platforms or bad network design.

> d) I know it's not quite correct to compare full-flavored server database
> such as Oracle and desktop like database like Btrieve, but, I believe this
> is not completely in my power to cancel management directives.

I would take exception with the term "desktop database", but this is a common opinion in the world today. In terms of maximums that I have seen, I can provide the following stats from some of my customers:

- Largest number of users: >1200 concurrent users.
- Largest database size: 60GB+
- Most Throughput: 7000+ Btrieve Requests Per Second on a NetWare server with

load-balancing NIC's.
- Most maintenance-free system: I installed a system for a customer over 3 years ago -- and I have yet to touch it since!

> e) If you think of any info I haven't asked above but which you may think
> might be useful for me (vow!) just let me know.
>
> Thanks in advance,
> Ilya.
>
> FBC Inc.

Hope this was useful!
 Goldstar Software Inc.
 Building on Btrieve(R) for the Future(SM)  Bill Bach
 BillBach_at_compuserve.com
 www.goldstarsoftware.com

• Pervasive.SQL Service & Support Classes *** Chicago: April 9-12, 2001 - See our web site for details!

Received on Mon Mar 19 2001 - 20:41:40 CST