Re: Autoupdate field with number of related registers
- From: leon.obers@xxxxxx
- Date: Fri, 6 Mar 2009 16:21:42 -0800 (PST)
On 5 mrt, 10:21, "Ursus" <ursus.k...@xxxxxxxx> wrote:
Well that may be true, but a student ID is not a primary key. Like I said: I
primary key (pk) holds no relevant information.....
.....A pk is never used for active searching, since it has no meaning.
In my setup, as long as a school is not giving a student ID by
themselves, I give an ID that has no meaning too. From start, it is
just the record number + 100 (use the ID for barcode, that needs at
least 3 digits). Just with a tiny change of the setup of the database,
it can run in the same way as I set this number as the matching
relation (tried already more early). Good if the database you are
working is the only real table that is always used.
But I run into troubles if after a year, the school is giving me an
update of *their* database that I have to import in my database. There
is no match of my used ID numbers to their pupils data, because they
don't use my ID numbers. I have to match full names, because addresses
could be changed too in meanwhile. If there is a change of the name
itself (e.g. a previous written name was misspelled and is corrected),
**a new record is made**, so also a new ID that has no relation to the
previous data of **the same person** in other connected tables. So
using primary keys, in this situation is giving the same troubles as
using an ID that do have a meaning. So no reason to use a meaningless
primary key.
In practice school data contain many faulty information or some pupils
are not in the database at all. So I need a quick update of this data
and a workaround that doesn’t slow down the actual work -taking school
pictures- So for practical reasons I give more weight to the only real
connection -a full name- spelled right or misspelled.
There always shall be possibilities for errors, independent which
system is choosing.
That’s practice.
For myself I always maintain my database in an abstracted
way. Works for me but this might not work you.
That is the difference. You are thinking in an abstracted way (with
all respect to your choice), but keep in mind that it can be more
troubled by real life practical way. ;-)
Each database setup has their own merits and has to be seen in their
own practice. That is that there is a possibility that in a first
glance not always logical choices are made, but more deeply seen in
practice this could be the better choice.
--
Keep well / Hou je goed
Kijk een Nederlander.
Best regards, Leon Obers
.
- Follow-Ups:
- References:
- Autoupdate field with number of related registers
- From: JJ de la Vega
- Re: Autoupdate field with number of related registers
- From: Ursus
- Re: Autoupdate field with number of related registers
- From: leon . obers
- Re: Autoupdate field with number of related registers
- From: Ursus
- Autoupdate field with number of related registers
- Prev by Date: Re: FMP icons
- Next by Date: Re: serial numbers in tables
- Previous by thread: Re: Autoupdate field with number of related registers
- Next by thread: Re: Autoupdate field with number of related registers
- Index(es):
Relevant Pages
|
Loading