apples and oranges logo The Open Source Database Benchmark
Run Rules
Building OSDB
Style Guide
Project Status

OSDB Links
-Get OSDB here!
-The CVS Repository has the latest (maybe broken) sources
-OSDB mailing lists
-Contact us

Other Links
-Linux Benchmark Suite
- Association Française des Utilisateurs d'Unix et des Systèmes Ouverts SSBA benchmark suite

OSDB has tests underway for

OSDB needs tests for

OSDB Style Guide

Structure of the code

Coding Rules and Conventions for OSDB

  1. Rule #1 -- Copy the style that you find in the module!
  2. Use the PostgreSQL tests as your template
  3. Tab stops are set at 4 character intervals

Structure of the code

The physical structure of the source tree layout mirrors the logical layout of the code.

At the top of the tree we have osdb, which provides overall direction and common services for the tests.

  • Callable SQL branch
  • The first branch of the tree under OSDB is Callable SQL. Callable SQL invokes database-specific modules at the next level down to implement tests. In this way, we can help to ensure that anything that can be called via an SQL interface, including user interface programs, will be subjected to the same tests.

  • Embedded SQL branch
  • Like the Callable SQL branch, this branch provides a common driver for embedded SQL implementations. Note that Embedded SQL tests rely on the M4 macro processor to help ensure that the right things happen.

  • Non-SQL branch
  • This is the most tenuous branch because anything tested here, by definition, speaks something other than SQL. The implementor must be especially careful to ensure that the tests here parallel the SQL tests of the other branches.

Coding Rules and Conventions for OSDB

  1. Rule #1 -- Copy the style that you find in the module!
  2. Exception: Most of the code puts opening braces "{" on a new line, such as

      if (sensible)
    On reflection, the more-standard practice is to put the opening brace on the previous line, i.e.,
      if (sensible) {
    The latter form is preferable, and all new code should be written in that style, even if the rest of the module uses the previous style.

  3. Use the PostgreSQL tests as your template
  4. When starting a new program, use the equivalent program from the PostgreSQL test set as your template. By starting from a common base, we should be able to limit the number of unintended mutations over time.

  5. Tab stops are set at 4 character intervals
  6. I prefer to translate tabs into whitespace, which helps to ensure that various print utilities, and more or less, will display the same thing as my preferred editor, vim.

OSDB is proud
to be hosted on
Get Open Source Database Benchmark at Fast, secure and Free Open Source software downloads
(As always, trademarks are owned by their owners...) Webmaster