Creating an user as a sequence of operations? Why?
Imagine the ways this data can get corrupted? What if for some reason only one of the queries executes? What if somebody removes one of the rows for a user but not the other when doing support or maintenance?
The whole application, every SQL query taking input, was vulnerable to SQL injection.
For many insert operations, I'd find a pattern appearing of first inserting a row with some random value in one of the columns (`temp_key`), then performing a select based on this key to get the row back to know the primary key, and then continue to update other fields in the same row, and adding other records to other tables referencing this primary key.
Obviously, transactions was a foreign concept to the original developers. I still remember taking a deep breath once I found a code snippet that would try an insert again if the insert failed because the randomly generated `temp_key` was already used before, a problem that seemed to really start bothering them as the database grew larger...
I have seen this pattern before, it comes when somebody is sick of having to adjust their database schema every time somebody comes up with a new user attribute that they absolutely definitely need to keep audited. Now you can add whatever "columns" you like, boss!
Certain authentication methods for RADIUS require a cleartext password, sadly, which will be stored in the Cleartext-Password attribute.
It uses one table for identifiers and field tables for all data connected to the identifier. To store a user with a username, a password and an email address it uses 3 tables. One for the username (identifier), one for the password and one for the email address.
The only safe way to insert a user is by using transactions.