J
Jamey Cribbs
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
(e-mail address removed)
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
(e-mail address removed)