I have a strong feeling that something is missing from this question... But I can't see what it is... So if you think this question is incomplete, please don't just downvote and leave. Instead tell me what's missing. I would appreciate it.

Better on a Coding Stack? Is it really a Workplace issue?

I had the strong feeling that it would be good here as it is not really about the data structure but the communication why it would be good to change, but maybe you are right. Now If this is better in a coding stack... Do I delete it here and reopen a question elsewhere or do I flag and ask for a migration?

@SolarMike It's not the code that needs looking at. It's communicating to the team leader

The question is about workplace interaction, rather than the specific technical details. I'd recommend replacing the technical layout with a brief description (normalised as opposed to known layout), which should help people understand the context a little better

Perhaps it is the technical nuances and benefits that will convince the team leader to accept the change...

Just as a counterpoint - I have "revision history" in my application (Rails). I use the ancestry library to keep track of what is a revision of what. All of this data is in a single table, and it works with no issue. Sometimes you don't need to change the structure if you implement this internal relationship appropriately. But this of course depends on your use case and tooling. Food for thought!

I'm voting to close this question as off-topic because it's a programming question.

He's absolutely right. It's in production, it's working, what's the problem? Does it add significant delay in the software running? Will the data structure significantly expand, requiring you to keep it clean from the beginning? Will this inhibit upgrades to the software to the future? If there is no actual harm, other than "it's not the correct way", then why should it change?

@Issel because as rath’s answer makes clear bad planning now just increases costs over years...

@Fattie It is a work related commuication question... My intention is to keep the development time short, and the complexity small

@Issel It is delaying development of another component (by a non significant amount) as I have to implement workarounds, It makes it harder to understand what's going on, Maintanance will be a pain in the ass, Every other expansion will add more significant overhead to the already big pile of code.

@solar Mike Sometimes it does, not all the time. We certainly can't determine that here. His team leader sounds pretty reasonable by telling OP if he can bring the team leader valid reasons, they would change it. Presumably his team leader isn't a drooling idiot who has never heard of "technical debt", and we shouldn't assume the team leader is automatically wrong.

@Mischa , regarding your question, it's one of the most common on here. New programmers are shocked to find data structures / etc they don't agree with. The software issue you describe can trivially be done either way, it's comically easy. As a programmer you use the architecture decided on by your architect and get on with it. (If you want a job where you are the architect, get one.)

@mischa sounds like you answered your own question? your team leader asked for valid reasons, telling him "The data structure cause my last assignment to take 3 weeks rather than 1. My future assignments will have similar delays", and if that isn't a valid reason, then no answer is going to change your team leaders mind.

@Mischa did you mean “non negligible amount” when you said “non significant amount”? Because if it is not significant it’s probably not worth arguing about...

The best way (imo) would probably be to work hard and earn the respect and trust of your team leader. It's hard to trust someone new with a big change, especially if he will be carrying all the responsibility of potential issues. Once you have proven yourself, he and everyone else will more seriously consider your suggestions.

@SolarMike no I mean no significant amount. Reasoning: Currently I can still work with this mess without missing my deadline. Thats also a reason why the "it's delaying" argument does not seem to be taken seriously. But as more and more stuff gets added it will flip over to a non negligible amount to work with it. That's why I would like to see it changed now. There is only one component currently using this table. So changes now are better than later

@Mischa you have, with the last sentence in that comment just agreed with the point I made at the beginning and with rath’s answer...

If you want help with the technical aspect. You can try writing your question in our sister site stackoverflow.com

stackoverflow is known to me and also the site I use on a very regular basis. I think I got any advice I could get here... Thanks all for that. I'll re-read every answer later that day and decide how I'll proceed with this. I think asking this question (focused on the technical aspect) on stackoverflow can't hurt.

Just as a side note: As a new team member, it's best to be even more aggressive with yourself about picking your battles than usual, until you know more context for the company, the company culture, your team lead's management style, etc., etc.

You might find the book Refactoring Databases: Evolutionary Database Design by Ambler and Sadalage helpful or inspiring. It's a cookbook of ways to change the structure of your database without disrupting users of the old structure. It might help you to think about the business implications, not just technical implications, of design choices.

Is it really a one-to-many or more like a 1-to-3? Sometime, if there's a limited amount of relationship that is possible, they combine it into the same table without any impact.

"another piece of the software already uses the table as it is in production"—Would your change to three tables require rewriting and migrating this existing table, or a compatibility layer somewhere?

The question would have benefited by including a few more technical details. Slowly changing dimension-related problems are hard, and you can't just barge in as a beginner thinking you know the answer owing to normalization considerations when there's a whole literature of research on the topic that tells a different story and practical examples of how it's done that work to support that research.

@the_lotus It is one-to-many the "one" part is fixed... There are (atm) 3 "groups" which we give and the "many" part are entries that the user (of the software I create currently) can add (every addition is either a change of an old entry, or a completely new one)

@Kevin the only already existing software uses only the lines from that table where the state is set to active, and also does only so when we as the developers start the process of it. They will then be "compiled" into files that are stored for later use until we regenerate the files. The select would change from Context.GetEntries.Where(E => E.State == "Active").FirstOrDefault() to Context.GetEntries.Where(E => E.State == "Active").FirstOrDefault().GetCurrentActiveVersion() with some fixes for accessing the values of the actual Entry... That are like 16 lines... (I already checked it)

@DenisdeBernardy I get what you want to say. The practical example is that the rework of the existing software is fairly easy... There are around 17 lines to change... These 17 lines of code are in code that gets rarely used... So reworking that should not be a big deal... The reason why a change would be good is because (my team leader already confirmed this) there is no practical reason for the current layout. It is only like this because He didn't needed more for his Proof-of-concept. But the software I currently develop would greatly benefit from a normalized structure.