Overview

Overview

OODB (object-oriented database) has been developed for the following use cases:

• Client-server enterprise software written in C#.
• Mobile applications written in C# (Xamarin) that must either read/write data in remote database or keep a local database on device.
• Interactive work and scripting.

Both in "file" and in "listening service" modes the database is accessed either from source code (C#) or via PowerShell.
Code sample for C#:

int16List = new List<Int16>();
int16List.Add(Int16.MinValue);
...
int16List.Add(Int16.MaxValue); 
dbi = new OODBI.OODBI(dbServerIp);  
dbi.putList(int16List, myList);

Code sample for PShell:

[Int16[]]$int16arr = @(1, 2, 3)
$dbi = (new-object OODBI.OODBI($dbServerIp))
$dbi.putArray($int16arr, [string]"myArr")

OODB supports data structures and nested objects. A user who has some experience in PowerShell, Matlab or any object-oriented language should find OODB easy to work with. OODB can be either used merely as file or as "listening" service (a.k.a. database management system). Check the supported data types here: [Data types]

Below the main parts/modules of OODB are shown:

• OODB is the database "as file".
• OODBC (object-oriented database control) is the listening service (server) which parses requests and sends responses to database users. It takes care of thread safety, defragmentation, creation of back-ups and user access groups.
• OODBI (object-oriented database interface) is the client side.
  

Examples of use cases

Enterprise software in C#
Suppose there is a custom SCADA software collecting and visulalizing industrial process data. Today such software will be likely developed in Java or C#. The data from PLC registers can have a structure like this:

plc1.pressure
plc1.temperature
...
plc5.pressure
plc5.temperature

Since we're in C# code and dealing with simple yet nested data structures, choosing OODB for data accumulation will be natural.

Mobile (Xamarin) app
Suppose it's a mobile client for company's inventory software. The specialist using the app must check some of the company's assets (equipment, cars, etc.). Nested data structures and their lists come into play such as:

car.id
car.model
car.engine
...
car.engine.volume
car.engine.power
...

These data not only have to be read/written from/to the company's database but probably a local copy of the data must be kept as well. There can hardly be any other software that can make things easier than OODB.