On Thursday 15 December 2005 02:01, Don Allingham wrote:
> However, a nice thing that BSDDB gives us is the ability to store lists
> as the data of a key. This is something that relational databases don't
> have that is trivial in BSDDB.
> The problem that concerns me with the multiple table option is that it
> just seems to explode. We would need:
> Source -> Person
> Source -> Family
> Source -> Event
> Source -> Media
> Source -> Place
> Source -> Source (yes, this can actually occur)
> Place -> Family
> Place -> Person
> Place -> Event
> Media -> Person
> Media -> Family
> Media -> Event
> Media -> Source
> Media -> Place
> Event -> Person
> Event -> Family
I'm not sure I understand, the above seems wrong way. Why person etc. tables
cannot contain a "pointer" to correct source table entry, or have a separate
link table between them?
> We have a common source of information, for this example, it is a book
> called "All about John Smith". We get a lot of information about "John
> Smith" from this book. For example, it has information recording the
> person's full name on page 100. It also indicates on page 300 that this
> same "John Smith" sometimes spelled his name as "Jon Smith".
> In this case, the person's primary name would be "John Smith", and we
> would attach a source reference to this source (the book) to this name.
> In this source reference, we would indicate in the source reference that
> we found the information on 100. We would also add the name of "Jon
> Smith", create a link to the same source (after all, it is the same
> book), and indicate on this source reference that we found the
> information on page 300.
> While the sourceref point to the same source, they are not identical.
> So, kind of in a nutshell, multiple source references in an object
> referring to the same source is something that we need to support, and
> is something that many users are using right now.
Person -> Name(John Smith) -> Sourceref(p. 100) -> Source(All about...)
-> Name(John Smith) -> Sourceref(p. 300) -> Source(All about...)
Btw. Is there a data domain diagram of the current stuff in Gramps; what are
the consepts included in the data: person, name, source, place etc, and
especially how they (should) relate to each other, whether the relations are
one-to-one, one-to-many or many-to-many?
That would help in constructing and discussing the database tables a lot.
> In projects that I have worked on (both software and hardware), the
> subject comes up that "we may need to do this in the future". In almost
> every case where we have "planned" features for the future, we ended up
> getting a large, complex, and bloated infrastructure that everyone had
> to deal with. And 9 times out of 10, the thing what we may have wanted
> to do for the future never came up, and when it did, we found that the
> implementation wasn't what we originally thought it might need to be. In
> fact, in many cases these "prepare for the future" enhancements
> prevented us from doing what we really need to do in the future.
Agree, easily maintainable test suite and plan for re-factoring is many
times better than "future proof" code. You never get the requirements
"right" before the implementation and sometimes not even until long time
after the implementation is "done".
Database compatibility and upgrading might be a pain.
Maybe there should be a separate utility for this? Or require that user
dumps the data as XML from old Gramps and imports it into new Gramps.
(New Gramps could ask user to do that if it encounters old/incompatible