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.shread_records.claims.shdb_backup.sh
InterfaceClaims_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.
PlanningTestingProtocol
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
