Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] PIW Relationships Modelling

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] PIW Relationships Modelling
  • Date: Wed, 20 Jul 2005 01:03:53 +0100

Chad Knepp wrote:
My use of denormalization was talking over my head. I didn't even
know someone had created theories behind it. Looks like I have some
reading to do.

For the PFAF dataset. I'd say normilisation issues are a real headache from a database admin point of view. Theres some terible problems with the same data being represented in two or more tables and only one of which is updated.


> > IIRC, Bear suggested a two/three column schema with a primary key
> > and then an attribute and followe by data of the attribute.
> > Something like:
> > > > id | attribute | data
> > ---------------------
> > 34 height/feet 20
> > > > As I said earlier this doesn't scale well in an RDBMS.

This system would fit well with and RDF style triples. Basically
you have
source | atribute | object
where atribute could be any sort of relationship.

It could lead to a simple database structure, most everything could be encoded in three tables.

> > This represents data entry optimized designing. It scales very
> well with RDMS tools, but not if you don't use the data that way.
> This is a schema discussion, not about the tool to implement it.

Not sure I follow this. Bear was suggesting this because we were
having trouble deciding what [plant] attributes where important and
which weren't (a schema discussion correct?). His suggestion would
disolve most of the need to figure out what was important ahead of
time and essentially make a row out of each column of several tables.
I love the idea from an ease of implementation standpoint, but I'm not
sold on the extra select to reassemble the plant row and lack of
contraints (anything could be NULL). OTOH, this is really close to
the loose tagging way of data organization I'm currently in love
with.
Waddya think? I would really love to be convinced that this is a good
idea. I'm going to read some ralphkimball.com stuff -n- relax.

I'm very much in favor of loose tagging and keeping the type of atributes open. This could future proof the system so that if someone wants to come along and add some new atribute it would be possible.

<tangent>
I've been pondering the whole tagging concept. Basically its a move to a set theoretic concept. Rather than have trees or anything like that you can define things purely in terms of sets.

In principal it would be posible to create a file system based around a set/tagging concept. Rather that define a directory structure it would be posible to allow each file to be a member of a number of sets.
To locate a file you just type in the the names of the different sets it belongs to and it would dispaly the intersection of the sets.

So rather than have a directory
/work/projects/pcplantdb/datastructures
I have a number of sets: work, projects, pcplantdb, datastructures.
A file in the above directory would be a member of each set.

To find files I could just enter "pcplantdb" or "datastructures".
If thats too many I could enter "pcplantdb datastructures" which displays files in both sets.

Conceptually you can view a tree structure as a specific type of set structure where there is strict inclusion. I.e. all elements in
projects are also elements of work.
</tangent>

So thats confused everybody. Time for bed.

Rich




Archive powered by MHonArc 2.6.24.

Top of Page