balancing act
Jul. 24th, 2002 03:21 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nollyor, what to do when it wasn't done right the first time
Users of our system do not have a single unique identifier. Instead, the combination of userID and clientID is unique. I don't know why the system was designed this way; at this point, it doesn't really matter.
We need to handle users (students) who move from one client (school/school district) to another. If Johnny starts third grade in Boulder, then moves to Denver, then to Colorado Springs, then back to Boulder, they want to track his test scores over the whole year. If the system were well-designed in the first place, users would have a unique ID, and this would be trivial. Since they don't, we're seeing two options.
1) Create a new unique ID; modify te DB and the code to use it. Lots of dev effort here.
2) Create a lookup table associating subsequent identities with the original ID. More load on the DB, but far easier to implement.
What I'd like to know, but don't, is how many migratory students we're talking about here, and how often they move.
Any other ideas, or pointers to factors I haven't considered, would be appreciated.
(I find it amusing the the LJ spell checker doesn't have "LJ" in its dictionary.)
Users of our system do not have a single unique identifier. Instead, the combination of userID and clientID is unique. I don't know why the system was designed this way; at this point, it doesn't really matter.
We need to handle users (students) who move from one client (school/school district) to another. If Johnny starts third grade in Boulder, then moves to Denver, then to Colorado Springs, then back to Boulder, they want to track his test scores over the whole year. If the system were well-designed in the first place, users would have a unique ID, and this would be trivial. Since they don't, we're seeing two options.
1) Create a new unique ID; modify te DB and the code to use it. Lots of dev effort here.
2) Create a lookup table associating subsequent identities with the original ID. More load on the DB, but far easier to implement.
What I'd like to know, but don't, is how many migratory students we're talking about here, and how often they move.
Any other ideas, or pointers to factors I haven't considered, would be appreciated.
(I find it amusing the the LJ spell checker doesn't have "LJ" in its dictionary.)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2002-07-24 04:57 pm (UTC)Does it change as the person moves from client zone to client zone?
If yes and no, could things be written to ignore the ClientID portion?
no subject
Date: 2002-07-24 05:18 pm (UTC)Only within a client -- Boulder/Johnny and Denver/Johnny are not necessarily the same person. See also "no unique user ID". I don't know yet how many duplicate userIDs we have; I should be able to get that number tomorrow.
Does it change as the person moves from client zone to client zone?
Potentially, yes; definitely if the new client already has a user with the old userID.