consider alternate data base record layout for person

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

consider alternate data base record layout for person

Joe Daugherty

I think this layout might improve performance and make development much simpler

I think it should make import and export fairly easy as well

What do you think

 

CREATE TABLE nperson (handle VARCHAR(50) PRIMARY KEY NOT NULL,

given_name TEXT,

surname TEXT, blob_data BLOB,

gramps_id TEXT, gender INTEGER,

generation INTEGER,  -- start with 2000

mother TEXT,    -- id

father TEXT,

birth TEXT,     -- date

older_sibling TEXT,

last_spouse TEXT,

marriage TEXT,  -- date

last_child TEXT,

death TEXT,

flag TEXT, -- adopted family or prev marriage

alternate_self TEXT,

last_event TEXT,

change INTEGER, private INTEGER);

 



_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: consider alternate data base record layout for person

GRAMPS - Dev mailing list
Joe,

We use the database as an object store, so duplicating data in the blob doesn't really gain us much.  The database API retrieves blobs, unpickles and unserialises them into hierarchies of python objects.  Bear in mind that Gramps allows for different database backends.

There is scope for filter optimisation which is handled in python at the moment.

The generation, flag and alternate_self fields need more explanation.  All the other fields are already contained in the blobs.


Nick.


On 05/12/2019 04:31, Joe Daugherty wrote:

I think this layout might improve performance and make development much simpler

I think it should make import and export fairly easy as well

What do you think

 

CREATE TABLE nperson (handle VARCHAR(50) PRIMARY KEY NOT NULL,

given_name TEXT,

surname TEXT, blob_data BLOB,

gramps_id TEXT, gender INTEGER,

generation INTEGER,  -- start with 2000

mother TEXT,    -- id

father TEXT,

birth TEXT,     -- date

older_sibling TEXT,

last_spouse TEXT,

marriage TEXT,  -- date

last_child TEXT,

death TEXT,

flag TEXT, -- adopted family or prev marriage

alternate_self TEXT,

last_event TEXT,

change INTEGER, private INTEGER);




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: consider alternate data base record layout for person

GRAMPS - Dev mailing list
In reply to this post by Joe Daugherty
On 05/12/2019 13:56, Joe Daugherty wrote:

generation

            would be 1 number bigger than the generation of the parents, if the parents were not in the same generation then the children are 1 number higher than the larger number. 

I was doing some genealogy on the bible so Adam could be generation 1.  That was 5780 years ago or about 3000 generations, so starting with a present generation of 3000 (or somewhere between 2000 and 5000)

We derive generation numbering relative to the centre person specified in a report.  This can obviously change for each report.

It would be possible to store a generation number relative to the home person in the database.  The values would have to be recalculated if the home person was changed.  We would also have to define what generation to assign children born to parents of different generations, and to unrelated people in the tree.

This has been discussed briefly before.


flag  

            if a child is adopted he has birth parents and adopted parents so he has 2 families.   The alternate_self would be the id for the person in the adopted family with alternate parent and older siblings.  More commonly a person can have additional people that they have children with, which can overlap so this would hold the additional “spouse” and last child which would make generation of each of the family sheets rapid.  Alternate_self  could link in a circle.  Last child would make finding the other children by going up the older sib line easy. 

 


We actually store a list of parent families in the person object.  Each family contains a list of child references which define the relationship between the child and its mother and father.  By default the relationship can be either None, Birth, Adopted, Stepchild, Sponsored, Foster or Unknown.  Custom relationships can also be defined.


Could you point me to the blob documentation.


There is a data model here:

https://gramps-project.org/wiki/index.php/Gramps_Data_Model

It needs updating for v5.1, but the only change is the addition of time-dependent place names.  Everything else should be accurate.

You can also look at the serialize method in the object source code.  For example, for the person object:

https://github.com/gramps-project/gramps/blob/master/gramps/gen/lib/person.py#L117

There is also a JSON schema in the source code.  We are considering storing the objects as JSON in the future rather than pickled blobs.

We also have online documentation:

https://www.gramps-project.org/docs/gen/gen_lib.html#primary-objects

Let us know if you need any more information.

Regards,


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel