ClaimsDB: 0.1b

This content was originally published on benscomputer.no-ip.org

Claims DB is a simple flat file database engine written in BASH. It supports the addition, deletion and basic querying of records.  All it's components are released under the GNU GPL.

All written Documentation is released under the Creative Commons Attribution-NonCommercial-ShareAlike2.5 License.

For those wanting to skip the background of why this program was created, and a few other things. Click Here to skip to Getting Claims_DB


Why write it in BASH?

To see if I could. It's as simple as that


Why such limited functionality?

Currently, the engine only supports the querying of one column, any further querying has to take place within the client. However, more advanced querying should be implemented in later releases.


How do I use it?

This release comes with a basic CLI client. At the moment, adding a new database does require some manual work, especially if you want to add Queries, Reports and Forms. However there are a couple of example databases within the client, so that you can see how to create Queries, Forms and Reports. The procedure is a little more complex than I would like, but I am intending to simplify it with either a GUI or a Web based GUI.


How does the system reference Queries, Forms and Reports?

Rather than having the system check the Queries folder for all Queries in there, the system has its own built in database, which contains details of all Queries, Forms, Reports, Tables and even all columns within each Table. This means that you can effectively hide Tables and Queries from the end user. So if a query is written specifically for a report, and is otherwise useless, you don't need to have it listed under the queries option.

Although the system does keep a list of Column names for each table, this functionality isn't really used yet. It is however a useful resource to keep up to date, as when you create a Form/Report/Query it's useful to have a print to remind you which Column is which.


How is the Data stored?

The tables used are simply CSV files. You can take the straight from the database into OpenOffice, Excel or whatever. It also means you can also export data from these programs to the database (though there is still some manual fingerwork to do at this point)


Why Implement this when there are so many other DBMS solutions around?

Pretty much for the same reason I wrote it in BASH, for a challenge. It also means I should be able to get the system to do exactly what I want it to. For example, I want my data stored in CSV format for easy reference, but most DBMS Programs won't let you create Relationships between tables in this format. There's a very good reason for it, and this system is not truly relational. BUT, I can make it act as though it is. For example, if you load the Bike_Parts Example Database, and try to add an item to stock using the form, it will ask you for the primary key of the part you want to add. It then queries the other table to retrieve the details for you.

Not impossible to do in other systems, but combined with the other planned benefits, for my current needs this system should hopefully be best.


You Mentioned a GUI/Web Based GUI, Whats planned for this?

Obviously the basic features such as adding Data, Retrieving data whether through Query or otherwise, reports and forms. Eventually, the GUI/WGUI should be a far more full DBMS than the CLI could ever really be. The CLI is intended for basic transactions, but there is probably only so far it can go. The idea however is to be able to port code between each interface, for example the basic requests such as Querying should be able to be copied across almost verbatim.

For those functions, it is largely a case of adapting how the Interface reads input, and how it displays output.

That said, the GUI/WGUI will eventually have a query builder. I'm not quite sure how I am going to implement it yet, but the intention is to allow the user to specify (and hopefully save) the columns and criteria.


So the system is going to get harder to use?

No, quite the contrary really. The idea is that it will get easier to use, I'm eventually aiming for a reasonably simple user experience. Aside from the install, I don't want the user to have to open a text editor at any stage, but that's some way off as I'm currently more interested in implementing the basic functionality before I look too much at simplifying it.

You also have to expect that in the reasonable future at least, anyone that uses the system is likely to be a cut above Joe Average. The system runs on an OS that not all that many people use. Once Microsoft drive more of their users away, this could change very quickly, but by that point the experience should be a bit easier.


Getting Claims_DB


The system is available from this Gzipped Tar file.


311a62c959051c4d52351d081decf395 Claims_DB.tar.gz

For those who just want to browse the code, you can also look at the main components here. None of the System Database tables are included here though, so you may want to grab the tar file so you can see what is being referenced.


Database Engine

insert_record_claims.sh
read_records.claims.sh
db_backup.sh



Interface

Claims_DB_CLI.sh



Development Documentation

This is the documentation that I created as I wrote the system. It is not a lot of use for teaching you how use the CLI, but the Protocol Documentation will show you how calls to the Database Engine are made.

Planning
Testing
Protocol Documentation (slightly out of date, doesn't include the -query-line call)



Config Files

An example /etc/claims_db.conf
config for the Database Engine
Config for the CLI