I would like to announce the second beta of version 2.3 of KirbyBase, a small, pure-Ruby database management system that stores it's data in plain-text files.
You can download the beta here:
Windows: http://www.netpromi.com/files/KirbyBase_Ruby_2.3_beta_2.zip
Linux/Unix: http://www.netpromi.com/files/KirbyBase_Ruby_2.3_beta_2.tar.gz
Here are some of the new things you will find in the second beta:
* New column type: :YAML. If you designate a column as a :YAML type, then you can store anything that YAML can handle in this field. This opens up the possibility for now storing arrays and hashes in KirbyBase. KirbyBase takes care of calling YAML.load() and #to_yaml for you, so you can just use the field as a normal native Ruby type. One nice side effect of this is that you can even use :YAML fields in your #select queries. For example:
car_tbl.select { |r| available_colors.include?(:red) }
Many thanks to Logan Capaldo for this idea!
* Two new methods: #add_table_column and #drop_table_column.
* I have refined the select code so that, when you are doing a one-to-one or one-to-many select, if an appropriate index exists for the child table, KirbyBase automatically uses it. By the way, I have been pleasently surprised at how much indexing speeds up queries on large tables. I have one test case where I do a select against a table that contains 16,000+ records, one for each baseball player whoever played. I have the baseball player table, called master, linked in a one-to-many link to another table, called batting, that holds 85,000+ records, one for each year that each player played. Here's what my select query looks like:
master_tbl.select_by_name_first_name_last_index { |r| r.name_last == 'Ruth' }.each do |player|
puts '%s %s' % [player.name_first, player.name_last]
player.batting.each do |bat|
puts '%s %d %d %d' % [bats.year_id, bats.games, bats.at_bats, bats.hits]
end
end
Without indexes, it takes over 47 seconds to run. With indexes, under 1 second. 
* I have changed the designation for a one-to-one link from Link-> to Lookup-> after googling helped me see that this is a more correct term for what I am trying to convey with this link type.
* Bug fixes.
There are no official docs on the new features yet. The best way to learn how to use the new stuff is to look in the "examples" directory.
Here's a recap of the new features that showed up in the first beta:
* You can now define one-to-one relationships and one-to-many relationships between tables. I hesitate to call KirbyBase "relational", because I know that the term, in its pure form, is supposed to refer to whether the dbms supports relational algebra, not relations between tables. That being said, KirbyBase now supports the ability to link a field in one table to another table, so that when you perform a select, you automatically have available in that field a reference to either a single record (for one-to-one links) or multiple records (for one-to-many) links. Check out the examples in the link_test and link_many_test directories.
* You can now define calculated fields in a table. These are "virtual" fields that don't get populated with data until runtime. For example, you can create a field called "total" and specify that it's value is "quantity * price". During a #select, KirbyBase will, for each record, calculate the value of "total" by multiplying the "quantity" field by the "price" field. Check out the example in the calculated_field_test directory.
* Two new fields types are available for table fields: Memo and Blob. Check out the example in the memo_test directory.
* KirbyBase now makes available "crosstab" functionality in the result set of a #select. I am probably not using the term "crosstab" correctly, but I am having a hard time finding the right word to use. Basically, you now have available all of the values for a particular column of the result set. Probably the best way to see what this is is to take a look at the example in the crosstab_test directory.
* KirbyBase now has the ability to take advantage of indexes if you specify them when you create a table. Both single and compound indexes are supported. In some very limited testing, I have noticed a 100% improvement in query times using indexes. There is still a lot of optimization that can be done in this area, so I am hopeful of greater speed improvements. Check out the example in the indexes_test directory.
I hope you will download the beta version and check it out. Any and all feedback will be greatly appreciated.
Enjoy!
Jamey Cribbs
jcribbs@twmi.rr.com