Is it bad to duplicate data in two different db tables?

[lavish pine]

I have a login system which uses the table users. Currently there are two types of users, admin, and client (from my clients package).

I am creating a package which adds the clients feature.
I wanted to add a table clients that holds extra information about the user that is only specific to the client type. But, clients require a first_name, last_name, email and then other columns. The user also has these fields. Is it okay to duplicate on client creation? So it adds the data to both the user and the client table?

I could just grab those 3 columns from the users table and then use a relationship to grab the extra client info. But, I'm trying to make this client package as decoupled as possible, so that if the users table changes it will still work on its own.

[ebon aurora]

I think the default approach should be to not duplicate data, and instead rely on a single source of truth. If you have a very good reason, it may be reasonable to duplicate it (e.g. hard performance requirements), but then you need to be careful not to make data out of sync, and realise it will affect everything you do from that point on. Even something as simple as a support person updating a DB column will risk data becoming out of sync.

I don't quite understand your last point, if you users table changes to not have a first_name column anymore, how would you client table get that data?

[lavish pine]

That's the question, and why I'm thinking I might need to duplicate the data. It's either that or the package creates the shared rows only on users table upon installation.

With a migration perhaps

[ebon aurora]

But if the users table has no first_name, there no data to duplicate ...

[lavish pine]

But it does

[ebon aurora]

You said "if the users table changes it will still work". It will not if you package requires first_name on new clients

I'm trying to make you see that duplicating the data is probably not necessary

[lavish pine]

But, I'm trying to make this client package as decoupled as possible, so that if the users table changes it will still work on its own.

I'm saying I want it to work on it's own still. Currently it would break if the users removes first_name or changes to a different user model for auth.

[ebon aurora]

You're saying that if an app that uses your package decides to remove first_name on the users table, your package will keep that data (possibly without the developers knowledge), and will not be able to accept new clients anymore (since new users don't have a first_name)?

[lavish pine]

This is why I've asked the question, because I'm trying to understand the best option to go about this. Because if an app uses the package and then removes first_name from users table, then the package wouldn't work.

[ebon aurora]

In that case I think it's reasonable to require the app to keep it, and not duplicate the data

[lavish pine]

Would it be okay to have my package write a migration that checks if the user has first_name and if not it adds the column?

[lavish pine]

Or no

[proud nexus]

No, you shouldn’t be duplicating data. If your package requires a users table then it requires a users table. So it’s up to the person installing the package to ensure it’s compatible with their app. I don’t understand why you would have a table in your package that requires a specific column, but then also requires another table to have that same column. Sounds like you need to re-think something here.