ANN: KirbyBase 2.0

[Jamey Cribbs]

I would like to announce version 2.0 of KirbyBase, a small, pure-Ruby,
database management system that stores it's data in plain-text files.

You can download it at:
http://www.netpromi.com/files/KirbyBase_Ruby_2.0.zip

You can find out more about KirbyBase for Ruby 2.0 at:
http://www.netpromi.com/kirbybase_ruby.html

Version 2.0 is a radical departure from the 1.x series. It has been
practically re-written from scratch to be much more "Ruby-ish". The
most dramatic change is in how query's are expressed. To specify a
select query, you can now use a Ruby code block, i.e. anything that can
be converted into a Proc object. For example, if you had a database
table holding data on WWII planes and you wanted to select all United
States planes that had a speed greater than 400mph, the code would look
like:

plane_tbl.select { |r| r.country =~ /US/ and r. speed > 400 }

I like doing this much more than building an SQL string.

Updates, deletes, and inserts work much the same way. A lot of effort
has been put into making the all powerful Ruby code block do a lot of
the heavy lifting.

I would like to publicly thank Hal Fulton for all of his
input/feedback/suggestions/ideas for version 2.0. Hal was a major
impetus for my getting this version done. Additionally, he was
instrumental in keeping me focused on making this version feel much more
like a part of Ruby. That said, any bugs/design flaws/code inteptitude
is solely my responsibility, not Hal's!

I hope you give this new version of KirbyBase a try. If you do, please
let me know what you think.

Thanks.

Jamey Cribbs
(e-mail address removed)

 

[Bill Guindon]

I would like to announce version 2.0 of KirbyBase, a small, pure-Ruby,
database management system that stores it's data in plain-text files.

You can download it at:
http://www.netpromi.com/files/KirbyBase_Ruby_2.0.zip

You can find out more about KirbyBase for Ruby 2.0 at:
http://www.netpromi.com/kirbybase_ruby.html

Version 2.0 is a radical departure from the 1.x series. It has been
practically re-written from scratch to be much more "Ruby-ish". The
most dramatic change is in how query's are expressed. To specify a
select query, you can now use a Ruby code block, i.e. anything that can
be converted into a Proc object. For example, if you had a database
table holding data on WWII planes and you wanted to select all United
States planes that had a speed greater than 400mph, the code would look
like:

plane_tbl.select { |r| r.country =~ /US/ and r. speed > 400 }

I like doing this much more than building an SQL string.

Updates, deletes, and inserts work much the same way. A lot of effort
has been put into making the all powerful Ruby code block do a lot of
the heavy lifting.

I would like to publicly thank Hal Fulton for all of his
input/feedback/suggestions/ideas for version 2.0. Hal was a major
impetus for my getting this version done. Additionally, he was
instrumental in keeping me focused on making this version feel much more
like a part of Ruby. That said, any bugs/design flaws/code inteptitude
is solely my responsibility, not Hal's!

I hope you give this new version of KirbyBase a try. If you do, please
let me know what you think.

Having read the docs, I love the api for it. Very cool stuff
http://www.netpromi.com/files/kirbybaserubymanual.html

Out of curiosity, can you 'declare' sorts to be ascending by using a '+'?

Can this:
result_set = plane_tbl.selectname, :country, :speed).sortcountry, -:speed)

Be written like this?:
result_set = plane_tbl.selectname, :country,
:speed).sort(+:country, -:speed)

Also out of curiosity, have you thought about adding indexing? Could
just use a different file extension, and rebuild them while 'packing'.

 

[Jamey Cribbs]

Out of curiosity, can you 'declare' sorts to be ascending by using a '+'?

Can this:
result_set = plane_tbl.selectname, :country, :speed).sortcountry, -:speed)

Be written like this?:
result_set = plane_tbl.selectname, :country,
:speed).sort(+:country, -:speed)

Currently, no. The default is ascending. However, if there is a need
to explicitly specify ascending, I could add it.

Also out of curiosity, have you thought about adding indexing? Could
just use a different file extension, and rebuild them while 'packing'.

I've thought about it, but that's about it.
If we are talking about adding it for speed purposes, right now,
KirbyBase is reasonably fast. While coding this new version, I did a
very rough benchmark on a 80,000 record table. The query did a select
on a date range and returned 23,000 records. I coded the query in both
KirbyBase and SQLite and was mildly surprised to see KirbyBase finish
about 2 seconds faster than SQLite. Granted, this test was EXTREMELY
un-scientific and I am not trying to say in any way that I think
KirbyBase can match SQLite's performance. I just wanted to point out
that, for small databases, KirbyBase feels pretty responsive, so I am
not sure if there is a need right now to increase the complexity of
KirbyBase by adding indexing solely for speed.

If there would be other good reasons for adding indexing, I'm all ears.

Jamey

 

[Bill Guindon]

Currently, no. The default is ascending. However, if there is a need
to explicitly specify ascending, I could add it.

No "need", just like to explicitly declare things when I can. I seek
symmetry

I've thought about it, but that's about it.
If we are talking about adding it for speed purposes, right now,
KirbyBase is reasonably fast. While coding this new version, I did a
very rough benchmark on a 80,000 record table. The query did a select
on a date range and returned 23,000 records. I coded the query in both
KirbyBase and SQLite and was mildly surprised to see KirbyBase finish
about 2 seconds faster than SQLite. Granted, this test was EXTREMELY
un-scientific and I am not trying to say in any way that I think
KirbyBase can match SQLite's performance. I just wanted to point out
that, for small databases, KirbyBase feels pretty responsive, so I am
not sure if there is a need right now to increase the complexity of
KirbyBase by adding indexing solely for speed.

Nice results, even if it strays a bit, still sounds good.

If there would be other good reasons for adding indexing, I'm all ears.

To combine search with sorts? If I can index on date descending, name
ascending, speed descending, etc. Seems the index would be faster
than doing the sorts. Could be wrong tho'.