Hi Aaron,

What you have makes sense.  There are other ways to accomplish the same
thing but assuming that you want to stay with your schema then notice that
your pointer table is really a collection of relationship objects.
Considering that your mapping is relatively simple, to map this object you
could certainly do it by hand (Mapping the resulting strings to values in a
relationship object).

Then you can model your behavior so that it creates the appropriate objects
from your relationship objects and data values.  Writing a parser to create
objects should be relatively straight forward.  

The only problem that I see is partial data reads.  This is not a problem if
you are reading back values in an ordered structure, and if you read all
values.  This can really become a problem if you have a large object model,
because you will quickly find out that retrieving one object means you need
to instantiate the entire database.  You should consider adding a proxy
construct to represent relationships that have not been connected up yet.
Then you can add the object linking behavior and/or data value lookup to the
proxy objects. 

Also consider that much of the benefit of the DBMS is lost by your value
table.  It is possible to create views into your table that allow for
indexing, and I assume that you left out an id that ties your values into a
single object, but I would think that much is lost and indexing multiple
views in a single table has a major performance implications which will not
scale.  You do gain some flexibility but that flexibility comes at a pretty
big cost.  There are better solutions to schema management.  Regular Object
Relational mapping would probably be better.  Check out Glorp.

I'm using 3.9 but I wouldn't assume that the code will not work in earlier
versions.  Try it and see.  Hopefully if you load all the pieces it will
work in any image.  It is Smalltalk!

Happy coding!!

Ron Teitelbaum
 

> -----Original Message-----
> From: Aaron Reichow 
> 
> Ron,
> 
> Thanks for the reply!
> 
> That sounds pretty handy, so I'll give it a try. Another
> consideration is that I am currently using Squeak 3.4. However, there
> is no need to use that per se, so if you have any recommendations as
> to which image version you think would be the best, I'm curious about
> that as well.  No big reason to use 3.4 (as I do with my PDA/tablet
> work), I just have some images handy so I started working with that.
> 
> OK, the following is long, but I describe it because I'm trying to
> find a way to take what is in the database and make objects out of
> it. I figured I would have to write up my own ORM setup, but I don't
> think that will be too hard. I hadn't thought of using Glorp, or
> something like it, and if what I describe below could be used with
> Glorp, please let me know!
> 
> I won't be using Glorp, unfortunately.  I assume that I can't use it
> with our database schema. That said, I really don't know that much
> about Glorp or similar systems, and I certainly wouldn't mind a
> little input on this either.  The system I work on has this structure
> I've never used- sort of a simulated OODB.  I imagine that this
> database design has been used before but it's the first time I've
> seen it. In short:
> 
> TABLE RELATIONSHIP:
> id: integer = Unique ID for this row.
> compositeid: integer = The ID of the object pointing to the object
> represented in the row.
> componentid: integer= The ID of the object represented in the row.
> ikeywords: short string = The type/class of the item represented in
> the row.
> 
> TABLE VALUE:
> id: integer = For certain ikeywords, the componentid of a row is here.
> value: string = The associated string value.
> 
> Basically, the RELATIONSHIP table is nothing but pointers, along with
> the type/class information so our software knows what to do with it.
> It's pretty cool actually- it's a ton more flexible than most
> systems, it allows us to change our data model just like if we had an
> OODB.  For instance, if we added a "nickname" field to our "person"
> object, we don't have to touch the database schema. As an example,
> this is what would be in the two tables to create a simple person:
> 
> RELATIONSHIP:
> id		compositeid	componentid	ikeywords
> --------	---------------	----------------	----------------
> 99000	20000		30001		toperson [1]
> 99001	30001		30002		firstname
> 99002	30001		30003		lastname
> 99003	30001		30004		homenumber
> 99004	30004		30005		areacode
> 99005	30004		30006		phonenumber
> 
> VALUE:
> id		value
> --------	-------------
> 30002	"Aaron"
> 30003	"Reichow"
> 30005	"612"
> 30006	"555-1212"
> 
> Which could easily convert to a hash or object like so, all s-expy:
> 
> (Person (Firstname, Lastname, Homenumber (AreaCode, PhoneNumber))))
> 
> [1] The root of our tree is 20000, so when you compositeid= 20000,
> you've connected the row/object to the root.
> 
> Anyway, just in case anyone is bored and wondering about such things! :D
> 
> Regards,
> Aaron
> 
> On Apr 18, 2007, at 7:19 PM, Ron Teitelbaum wrote:
> 
> > Hi Aaron,
> >
> > I'm using the second one.  The PostgreV2.  I did have to fix something
> > http://bugs.squeak.org/view.php?id=3834 to use it with Glorp.  If
> > you are
> > looking for simple and you don't mind throwing your own SQL it
> > couldn't be
> > easier.  All you do is connect and then send aConn execute:
> > aSQLStatement.
> > If you do use Glorp then it does all the mapping for you.
> >
> > You do need to load MD5 from the cryptography package.  See
> > www.squeaksource.com/Cryptography.html .
> >
> > Ron Teitelbaum
> > Squeak Cryptography Team Leader
> >
> >> -----Original Message-----
> >> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-
> >> dev-
> >> bounces at lists.squeakfoundation.org] On Behalf Of Aaron Reichow
> >> Sent: Wednesday, April 18, 2007 7:50 PM
> >> To: The general-purpose Squeak developers list
> >> Subject: Which PostgreSQL client?
> >>
> >> Hola!
> >>
> >> Just curious- what PostgreSQL client do you folks here on the list
> >> recommend?  There seem to be two implementations:
> >>
> >>
> >> http://www.io.com/~jimm/projects/squeak_postgresql/
> >>
> >> and
> >>
> >> http://ca.geocities.com/zazu@rogers.com/pgsqueak/
> >> (though a newer version is on SM here: http://map.squeak.org/package/
> >> a8d3ca99-f5f4-45e0-9aa7-100a77b64f45/autoversion/3)
> >>
> >> Any thoughts on which might be better?
> >>
> >> I'm going to use it for writing reports, drawing from info we have in
> >> a PG db. I had to write a couple in Python, but I've gotten the go
> >> ahead to do my new ones in Squeak.  I've been using the pg module for
> >> Python, and for writing reports I appreciate the simplicity, compared
> >> to the full-blown PyGreSQL package.  I'm not using this for a web app
> >> or anything too hardcore- my co-worker or I run them periodically.
> >>
> >> I mention how I'll be using it because the usual considerations for a
> >> decision like this- speed, SSL support, etc- take a back-seat to how
> >> easy to use the API is.
> >>
> >> Thanks in advance!
> >>
> >> Regards,
> >> Aaron
> >>
> >
> >
> >
>