In one of my databases class, we had to use Perl (cursed language) and B-trees to implement a database from scratch. We tried building a "universal relation" system where any table could join with any other table, which Graham's paper proved was NP-complete.
# Join paths multiply exponentially when Sales department exists in multiple buildings
%employee = ('1' => { name => 'Alice', dept => 'Sales', building => 'West', project => 'Alpha' });
# Each B-tree indexes one specific relationship: employee_id → dept_id → building_id
sub get_employee_location {
my ($emp_id) = @_;
return $building{$department{$employee{$emp_id}{dept_id}}{building_id}}{name};
}
The normalized approach means each B-tree has a clear purpose and lookups follow a defined path. The "Universal relation" seems intuitive, but it's definitely computationally expensive.
In one of my databases class, we had to use Perl (cursed language) and B-trees to implement a database from scratch. We tried building a "universal relation" system where any table could join with any other table, which Graham's paper proved was NP-complete.
# Join paths multiply exponentially when Sales department exists in multiple buildings
%employee = ('1' => { name => 'Alice', dept => 'Sales', building => 'West', project => 'Alpha' });
# Each B-tree indexes one specific relationship: employee_id → dept_id → building_id
%employee = ('1' => { name => 'Alice', dept_id => '1' });
%department = ('1' => { name => 'Sales', building_id => '1' });
%building = ('1' => { name => 'West' });
sub get_employee_location { my ($emp_id) = @_; return $building{$department{$employee{$emp_id}{dept_id}}{building_id}}{name}; }
The normalized approach means each B-tree has a clear purpose and lookups follow a defined path. The "Universal relation" seems intuitive, but it's definitely computationally expensive.