On Sat, Feb 23, 2013 at 04:47:55PM +0000, Ian Goddard wrote: >Martin Steer wrote: >> On Fri, Feb 22, 2013 at 10:33:38AM -0000, Tony Proctor wrote: >>> >>> A simple off-the-cuff example, with an arbitrary syntax, just to >>> illustrate >>> the difference Janis. This bit of script wants to look at all the >>> events in >>> my timeline, then look at all the people sharing those name events, and >>> select the ones whose name has the element "Jesson". >>> >>> >>> Person me = New Person("Tony Proctor"); >>> for (Event e: me.AllEvents()) { >>> for (Person other: e.AllPersons()) { >>> if (other.name().contains("Jesson")) { >>> ...do something with this other person... >>> } >>> } >>> } >> >> As for sql, this kind of thing can be done fairly easily inside a >> database which allows so-called 'stored procedures'.[1] I use Postgresql >> with its native procedural language, but perl, python, etc, procedures >> could be used instead. >> >> I don't see the need here for an object oriented approach. >Unfortunately, neither did the designers of GEDCOM. But take a fairly >basic element of genealogy, the personal name. I didn't mention gedcom. I was responding to the following remark: "I'm thinking of more complex genealogical entities that have to be compiled into 'objects' before they can be manipulated. SQL (even the versions with procedural extensions) is similarly too low-level" That sql is too low level is a matter of opinion; that it cannot efficiently isolate a subset (of a subset (of a ... etc)) is false. It was designed for set manipulation. [snip] >We don't know but if we were looking at some query such as Tony >suggested we'd want this event to come up irrespective of whether the >name contained Jessop, Wareing or even Waring. In any sensible database, each Jessop would have a unique identifier which is independent of his or her names. That's a given. We look for Tony's events using his identifier: table: individuals (ind_id, etc) table: events (event_id, etc) table: roles (ind_id, event_id, etc) query: select event_id from roles where ind_id = <tony id>; This has nothing to do with objects. [snip] >And the mention of January 1662-3 above should be a hint that dates are >another can of worms better dealt with by an OO approach Given that dates are just data, I don't get this. You'll have to tell me why this is so. M.