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

51164Re: OT: OO data design and search performance

Expand Messages
  • Martin Moss
    Apr 11, 2003
    • 0 Attachment
      Don't sweat it, in my humble opinion the point of perl is to make life easy for oneself. I guess though that in my experience it's allways better to do it right first time, coz in 4 months time something usually crops up which results in a 'oh $&$%&&&**'.  Like if somebody says right thats it, we're no longer going to support mysql, we're gonna use oracle instead:-) (always a favourite!)
      One point of note, if all objects are so simillar, then surely, you can put your perl hat on to write a script which 'creates' all the code modules you need, you just feed it a Dummy Module template and a conf file containing the class specific stuff.
      Anyway The OO approach would slow down the speed of things, and I guess it all depends on a balance between speed and efficiency against futureproofing and manageability.
      Break a leg mate!
      ----- Original Message -----
      Sent: Friday, April 11, 2003 3:11 PM
      Subject: Re: OT: OO data design and search performance

      On Fri, 2003-04-11 at 14:28, Martin Moss wrote:
      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.


      This was my original plan, but with very few exceptions, the objects are exactly the same (bar the list of attributes associated with them).

      I wanted to do :
      http://website.com/browse?object_id=123. I suppose I could have loaded the object type from the database, and then blessed that object into the relevant sub-class, but it's been easier to maintain everything through a single table.

      Having said that, there has been the odd "if type==6" lines...

      <OO tail firmly between legs>


    • Show all 12 messages in this topic