Loading ...
Sorry, an error occurred while loading the content.

51158Re: OT: OO data design and search performance

Expand Messages
  • Martin Moss
    Apr 11, 2003
      
      Here's my forpence:-
       
      Why Have database Tables Defining which Attributes belong to a Class.
      Why not Have the attribuites existing in a config section of your class.
       
       
      e.g here's part of a baseclass.
       
      package My::BaseClass;
       
      sub _table_name
      {
        # this accessor is calling-package-relative
        my $obclass = shift;
        my $class   = ref($obclass) || $obclass;
        my $varname = $class . "::_table_name";
        no strict "refs";   # to access package data symbolically
        return $$varname;
      }
       
      sub _table_id
      {
        # this accessor is calling-package-relative
        my $obclass = shift;
        my $class   = ref($obclass) || $obclass;
        my $varname = $class . "::_table_id";
        no strict "refs";   # to access package data symbolically
        return $$varname;
      }
       
      sub _delete
      {
        my $self = shift;
       
        my $table    = $self->_table_name;
        my $table_id = $self->_table_id;
       
        my $stm = qq{DELETE FROM $table WHERE $table_id = ?};
       
        if ($self->{dbh}->do($stm, undef, $self->id))
        {
          return 1;
        }
        else
        {
          return undef;
        }
      }
       
       
      Then create instance classes which use My::BaseClass as a base but define their own configs and
      e.g.:-
      package My::Restaurant
       
      use base (My::BaseClass);
       
      @fields =qw(
                      RestaurantID
                      Name
                      Description
                      vegetarian
                    );
       
      %Required = (
               Name                 => 'Name',
               Description          => 'Description',
               Vegetarian             => 'Is Vegetarian',
              );
       
      $_table_name    = 'Restaurants';
      $_table_id = 'RestaurantID';
       
       
       
      ___END___
       
      This would mean that you have seperate backend tables for each instance class. This would save on database Lookups, and give you the ability to override in the instance classes certain functions in the Base class. Indeed it would allow you to create specific SQL commands in an instance class which could do complex things like JOINS.  Ultimately JOINING tables in SQL is going to be more efficient than Joining data in perl.
       
       
       
      ----- Original Message -----
      Sent: Friday, April 11, 2003 12:55 PM
      Subject: Re: OT: OO data design and search performance

      On Fri, 2003-04-11 at 13:22, Nick Tonkin wrote:
      As another poster has remarked, why not have your attributes in a separate
      table? So long as the ID linking them to the main object is not the primary
      key you should be fine.
      
      Objects:
      ID			Name
      1			foo
      2			bar
      
      Attributes:
      Object_ID	Attribute
      1			blue
      1			squishy
      1			expensive
      2			red
      2			cheap
      
      
      etc. Then to add a new attribute you just add a value to the table rather than
      a new column named after the attribute and yes/no values.
      
      Thanks Nick

      That's pretty much what I've got - a table of objects, a table specifying which attributes each object type has, and a series of tables for attributes of different types (eg lists, text, more complicated structures like address, images etc)

      The only reason I was thinking about denormalising was for performance reasons, but Aaron's reassurances have placated me.

      Clint
    • Show all 12 messages in this topic