We want to stress that we have no general recipe and our experience is only a limited one. Thus our conclusions need to be judged with this fact on mind. On the other hand we describe real projects, real failures and real successes. We really struggled with Interbase, ORACLE, WNT and Linux as described later on. Even when the corresponding companies are selling technical support the local representants in our country were not able to solve any non trivial problem we met. This also influenced our decision to use open source products wherever possible. Even with Linux not everything was nice but this system evolved that quickly so that several of our problems disappeared spontaneously as we installed newer versions.

At the very beginning we were not sure which way we had to go. We hesitated between proprietary products with declared technical support and open source products with no formal support at all. Also our customers were and still are rather conservative and often our products are the only exception to otherwise totally Microsoft Windows oriented broader context in the companies we are working for.

Any decision about the right database engine is influenced unfortunately enough by marketing as well as by not IT people. It is important to know that a database engine is only a tool and that the ideas and theory around which these engines are constructed are mostly rather trivial and well known. Moreover the notion of a relational database is an old one (about 25 years or so). Thus most of the engines are offering basically the same functionality. The bigger, broader or older the product is the more problems with backwards compatibility and the bigger is the petrifaction of old-fashioned ideas. That indicates that sometimes switching to a new leaner product could be a good idea. We found Interbase to be a rather good tool with extremely small footprint and good functionality.

Now a few words about our company. We are a rather small group creating original software in various branches - our profile can be found on our home pages. Our aim is to implement even huge and critical projects using minimum number of people. We do not believe that good project can be done reasonably when tens or hundreds of programmers are working together. Their productivity decreases rather quickly to zero as their number surpasses some constant varying from 4 to 10. That is why we concentrate ourselves to maximize productivity and re-usability of whatever we ever did. Well we are not alone thinking about what big armies of programmers are really doing in big companies. As far as we know, many important projects originated as one-man or few-man shows. Have a look at how Unix, C, troff or other important things were build-up.

Our method can be described as "distilled" abstraction and interpretation. The applications we create are strictly database engine agnostic and even the application in question agnostic. We always want that the application in question could do easily more than requested using always more abstraction that actually needed. It seems strange or even contradictory while it really is not as we explain in the sequel. Agnostic means here "knowing nothing about" or "unaware of".

First we explain the agnosticism with respect to a database engine. We try to write applications so that no particular database engine is assumed. It can be even changed transparently and the application in question will not notice. Actually we are using simultaneously Interbase, ORACLE and Paradox and except for slight differences (ORACLE does not support multiple BLOBs within one record while Interbase does) the same application can be run with any of these databases without any change. Specifically we are using a kind of abstract interface that is translating every database oriented code using sql constructs only. We will extend the list of databases supported in the future but once Interbase was released as a free product, our motivation to cover other engines decreased significantly. Thus most of our applications can be run without any relation to particular database engine. We even support the fact that one part of the system is using Interbase while another one is pumping data from ORACLE. All looks like if a unified and always the same database engine is running.

Let us turn to the more intrinsic agnosticism with respect to the application in question. The majority of jobs we are doing is using Windows based PC's as workstations while the database and other parts of the application are running under Unix or Linux on a dedicated server. Typically these are hospital laboratories, small or even huge companies - briefly the kind of their business is very variable. Having limited number of employees we decided to unify all of the applications to one "super-application" that is interpreting a particular application's specification. Thus we are using ALWAYS the same front-end binary that is fed during the start-up by the detailed specifications of what and how it will be servicing. Well that means the words like "account", "patient", "microb", "surname", "product" are NEVER mentioned in our binary. It is agnostic of any particular data model, it knows no particular working scenario beforehand. Everything including the type of database that is used is written in simple text files as a specification and the binary is interpreting or just-in-time compiling these specifications when needed. It is understood that such a program is able to do majority of the most ordinary working scenarios, it has a sophisticated statistical subsystem as well as graphics. That is browsing thru data, creating and arranging different views, scanning forms, chaining elementary actions into more sophisticated ones etc. More complicated than trivial scenarios are constructed thru a powerful scripting language. The system handles calmly any inconsistency between the current data model and the existing data and data dictionary within the application. Thus you can use not yet stable data model having different tables and items than you suppose to use in your forms. The system handles such situations doing its best. E.g. you can perform operations as "Here is a set of named values and let every table in the system takes its values as it wants and performs an insert ...". This is practical namely thru the development phase of the project in question.

It is important to stress that the binary in question is generally the only (except for web presentation) front-end visible to our customers. Generally we supply our products as rather autonomous sub-systems aimed to some specialized job. Typically we supply:

Totally database engine and application agnostic front-end written in Delphi.
Totally particular hence totally gnostic application specification.
Adequate database model and configured database server - the database in question is generated thru the above front-end as it translates specifications into the particular back-end database in question even for create clauses.
General and again rather agnostic web based presentation interface.
Two-way Java and Interclient based interface to and from our system / database.
Adequately configured hardware and operating system with automated administering cron jobs.

Our approach is always a compromise. It replaces coding in a programming language by another kind of coding in a specification language. The difference is that the specification language is very powerful provided the requested application is coherent with the general model we accepted. In such a case the "code" of the application is extremely compact and short. Some of the strong points of this method are:

The binary in question is a very stable one generating nearly never run-time errors. We change it rather seldom only when new inner functions are needed or some hard bugs are discovered. To give you an idea: one of our customers is running 3 years 24h/24h the program in question on many PC's across whole of the country. There are various versions of the binary running including the oldest ones. During this time the data model was totally changed, many new features were implemented and even the database changed from ORACLE to Interbase. The users did not notice. Only some of those that were using the oldest version of the binary were complaining about the fact that they could not invoke some newly implemented features...
We are having equally in our hands "hardware" (the binary) and the "software" (the application in question). Thus potential bugs in the binary can be worked around in the scripting language and conversely a repeatedly requested and complicated function can be "hardwired" within the binary. This is to some extent similar approach Transmeta is using in its new Crusoe chips. Continuing in this analogy our binary is a kind of morphing software that is translating the application into a native code and executing it then.
Because of the fact that the basic style of the work with the system is always the same the expenses for documentation and training are reduced. In hospitals where we are implementing various particular applications the personnel can easily migrate from one department to another. Basically they are all using the same software that is tuned for even extremely different purposes (micro biology thru neural surgery).
Even rather complicated applications can be build quickly. Construction of a fully functional first iteration of a non trivial system can be question of one or two weeks. The system is improved then step by step but is ROCK-SOLID FROM THE VERY BEGINNING. This is important for those customers that are experiencing frequent changes of their needs or for those that are simply unable to give their needs specification. With technology evolving this is very often the case as you will see later on when some of our applications will be described in details. Actually there are many applications that cannot be defined - they simply change faster than anyone can compile a good definition. Thus they can be defined only by themselves using self-reference. This way is our approach most suitable for.
Technical support of such software is particularly easy and can be done by persons having no training in programming or computer science. This is a very important point because of the fact that many customers need to do slight changes of their software without hiring programmers.

Let us mention also some weak points:

The binary in question is always the same. Even if it is highly configurable it cannot cover all types of applications. Our experience is that about 90 % of the cases can be handled by our approach with good results while the other 10 % of the cases cannot be handled regardless to effort we apply. These 10 % are simply "hardwired" that is to say coded separately in C, Java, Delphi or whatever appropriate environment. It can result in an a totally independent application or in an external plug-in to our binary.
Some customers are having very strict ideas of how their future software will behave, what kind of colored buttons they will press ... Many of them want to reinvent wheel and it is a very difficult job to smash their prejudices out. Building an application always from scratch is wasting of time but the customers sometimes are requesting exactly this approach. What is worse, they are able to accept some limitations provided they are caused by say ORACLE or other company's development tools but they do not accept that easily that we, too, are having some limitations from the very beginning.
On some old machines the interpretation approach can be slow resulting in bad performance. This argument is now very marginal - most of even mediocre PC's are INCREDIBLY fast and the size of the binary in question is only about 2MB.
Practically all customers are not very happy having a similar system to their neighbor's ... They are unable to understand that a system is important because it offers some functions and not because of how exactly the functions are offered. Understood that the implicit way of offering of the functionality is generally acceptable ... here paradoxically it helps the fact that the neighbor also was able to accept a similar system.