Database structure advice

[Teach]

Hello!

I'm after some advice please.

I have a user database, which doesn't use User ID's or ID's. Instead, it just uses accounts and then all their credentials.

The original reasoning for this is that we use a custom ticketing system, that when a staff reply is made to a ticket, in the reply database of that particular ticket it inserts the name. This was for the ideaology if a staff member left our organisation, we wouldn't get an unknown user ID on the reply, instead their name.

This is currently working fine, but I'm forseeing some future problems, such as:

When a member of staff leaves, someone can easily join with that same name, and take over as if it was that person before. We record logins in a logins database which contains 'name' inserted like that, so that user would see the previous person's login as it just selects that name from the database (hope this is making sense)

Would you suggest using UserID's, and if so, how would I combat the above? Or do you think my current system is okay (although to most standards not ideal)?

What I don't understand is these sites that use User ID's, when an account is deleted how does it link up to a certain person is that ID is no longer known?

The one thing that would be good about using user id's is the ability to rename accounts...

Any help is greatly appreciated.

[laserlight]

Instead of removing the account, mark the account as deleted. That way you preserve all the data for auditing, yet the account cannot be used.

[Teach]

Ah, excellent idea, yes. Then when I select * from user, I could append a 'where deleted=0'

If I use this method, would you suggest using user id's instead, or would it not really matter?

[laserlight]

I tend to prefer using auto incremented ids as the primary key, and then make things like username columns unique. It probably does not really matter.

[Teach]

Thank you for your help

I'll begin work on it now to do the ID's, it's probably worth it in the long run with being able to rename