Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] technical details, plan, re: synthesis

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] technical details, plan, re: synthesis
  • Date: Wed, 04 Aug 2004 10:16:42 +0100

Chad Knepp wrote:
Rich wrote:
> I'm fairly agnostic as to zope, I'm happy to go with it,
> but there are many other systems which could do it as well.
> For instance perl has objects good DB connectivity and
> a vast library.

I'm mostly zope agnostic (yet), but I'm definitely pro python. Perl
objects are an abomination and an assorted set of other unutterable
curses. Java has a great OO methodology but has really weak system
level access.

Not sure about this, there alot of stuff about J2EE (enterprise edition) which I haven't really looked into, but it seems to have
lots of stuff for DB conectivity, and stuff at the server end.
The Java database which has just been made open source by IBM
(mentioned in slashdots developers section yesterday) pitiqued
my interest for a few minuites.

> If you like and know Java, you practically already know
python. You really gotta look into it... it should be a snap for ya.

Indeed I must. Current problem is how to get python (&zope etc)
running on my home system Win98 box with personal webserver.


> I've also developed a proof of concept database system on ibiblio
> at
> http://www.ibiblio.org/pfaf/pcplantdb/index.php
> it look terible and does not have google type search but it does
> illustrate many of the features we need:
> Allows additions of information to db
> Extensible, very easy to add a new field.
> Handles other objects as well as plants.
> Beginings of support for users with varying
> levels of permision.
> Allows a strong atribution model. Footnotes are used
> to indicate who wrote what. Contributions can be woven into the
> different sections in the main text.
> XML output.
> Fairly well documented code and table structure. Uses a javadoc type > system to make the tables self documenting.

Wow, you sure have been busy! Actually your *keywords* are a simple
controlled vocabulary, and the ability to do common name, latin name,
and keywords makes it pretty darn effective and very google-like.

I think there a lot to be said for a controlled vocabulary....

Allowing collaboration puts it past Eden. If you are going to
continue development you might want to limit output of queries. I
searched for 'moist' and got a page over 1 Meg long.

As said it's currently proof of concept stage at moment,
basics needed to get a system working. Fancy features, like
limiting output were all ommitted.
Its really the fancy feature which take the time and
make a polished system.

> I think we need to have a clear idea about the object/data structure so > that we can ensure that the platform we choose can suport our needs.
> > Do we need
> sub-classing of objects?
> encapsulation - tying methods and data together?
> extensible objects?
> > I'm not 100% convinced that objects are essential.
> A RDBM scheme can handle most of our needs.
> Its fairly straightforward to go from an database record to an object.

I'm willing to talk about this more for a variety of reasons. Very
high on my list is that ZODB does not have an effective query
methodology. From a slashdot user:

The main practical difference between ODBMS and RDBMS is that ODBMS
is good for object persistence, not for querying. Despite indexing,
arbitrary queries (ad-hoc, based on partially know structured
context) in Zope are very weak (and they will be always weak until
ZODB will become a real DBMS project). To make power queries I need
some algebra (like relational). Object model doesn't have
such.
I had suspected something like this. I've been running a few though experiments through my head as to how object db's might cope with the "give me the latin names of all plants which are less than 1m tall".
Don't know enough to really comment on this.

One of our primary functions will be data queries. An RDBMS is
currently more of the right tool for that job. There are all sorts of
tradeoffs and kludges though when you mix good OO and an RDBMS.
Anyway, I disagree with some of your arguments, but not with the
outcome. I don't feel set on a particular platform yet and I/we need
to make a CONCRETE decision by this weekend. I will continue learing
the Zope platform and be prepared to go either direction by next week
but I would like to re-open the discussion.

BTW. Zcatalog and it's Catalog package is the way to have some sort
of easier querying, not IndexedCatalog. IndexedCatalog is basically a
project that died a year ago in beta. Catalog should do everything we
need. Before I started to look more closely at Zcatalog I had pretty
much schemed up a plan to re-implement what Catalog actually
does... whew.

ZCatalog is sounding interesting.

Housemate hasseling me to tidy so must dash
--
Plants for a Future: 7000 useful plants
Web: http://www.pfaf.org/ same as http://www.comp.leeds.ac.uk/pfaf/
Post: 1 Lerryn View, Lerryn, Lostwithiel, Cornwall, PL22 0QJ
Tel: 01208 872 963 / 0845 458 4719
Email: webmaster@pfaf.org
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf







Archive powered by MHonArc 2.6.24.

Top of Page