What type of database system/design is best suited for people/identity
tracking of a population?

Can the design also allow for quick searching of record based on some
personal details such as by name, date of birth or others?

How to establish relationship amongst people in the database?

On Nov 2, 2:01 pm, Luke C <l... (AT) webesse (DOT) com> wrote:
Well the one best suited to your application, of course. No seriously,
a better description of your application would allow us to better
answer your question.
Just about any modern DBMS allows quick searches for key and indexed
columns. You identify the keys and the database does the indexing.
Or do you mean quick as in easy to create and run ad hoc queries? That
is somewhat dependent on the front end tools available and the type of
"quick" queries you want.

Start by doing a DESIGN.

One method for doing database modelling is to create an ERD Entity-
Relationship Diagram. You might also want to consult with a database
modeller(sp?) (note this is NOT a DBA nor a programmer).

HTH,
Ed

Thanks for the response Ed. I realize my question was to general in
natural and was an attempt to brainstorm to see what others may come
up with. I wanted to see what other solutions may be out there other
then a RDBMS.

Yes you are right on the money that a good design is the way to start.
ERD would be a good modelling for a RDBMS and I am familiar with this
approach. This modeling has been much overlook in recently years,
especially with OO programmer relaying on Object-relationship mapping
tools.

Have you much experience in using hashkey in data for searching?

Luke

"Luke C" <luke (AT) webesse (DOT) com> wrote

discussing the requirements, but isn't a database design as such. The
first design step, once you have an ERD is logical modeling. It's not hard
to convert an ERD to an equivalent relational model. This model reflects
the way the data is going to be seen in the app. Finally, a physical data
model adds in features that are DBMS specific and generally not seen by the
app. At that point you are ready to build.

Luke, you probably already know all this. But whenever anyone mentions ERD
in the context of database design, it's worth reminding the audience that
ERD is useful for analysis, not design.

On 2 Nov., 20:01, Luke C <l... (AT) webesse (DOT) com> wrote:
Building logical model for people is quite nasty task. Person is such
a beast that hasn't any reliable attribute, names, surnames may
change, sex, birth date, parents, nationality, citizenship, may
change, probably some biological attributes like blood group is
permanent forever.
Marriage is quite vague term at least looking from multi-national
perspective, some countries allow many spouses, some countries allow
(yeahhh, unfortunately!) marriage for the same sex etc.
Adoption is a legal act that completely may change person's identity
at one go including parents, names, birth date etc.
People come and people go in your country and yesterday's John Smith
from London with a wife Mary might be the same today's single
Cristofer Robin. Do you need to track these changes? How'd you clarify
that he IS the same person (probably that's the problem of immigration
department however, not your app)?
So depending on your requirements how much you'd like to track history
of these data, how many attributes you'd like to collect, whether you
need to search also in historical data or just actual data, whether
you need to collect complete info or can manage just with a subset of
all info you have firstly create your logical data model and then
start to do design.

Gints Plivna
http://www.gplivna.eu

On Nov 3, 6:40 am, Luke C <l... (AT) webesse (DOT) com> wrote:
Okay you are familiar with these issues. good. So you'll also
understand Dave Cressey's advice.

Sounds like you are past the design and looking at implementation. No
I have'n really used hash key for searching. I may be looking at it
for a customer lookup situation we have, which would be similar to
your name look up needs. So you are ahead of me on that.

One thing I learned from previous experience and from some research is
to make sure you store the raw input data. That advice originally came
from this book:
The Math, Myth, magic of Name Search
It's free and a valuable resource.

Just search the web for
math, myth, magic of name search
and you'll find links to the book.

HTH,
Ed