Relational database design: One-to-many connection - Is storing a customer ID as part of an order ID too redundant?

Question

I am new to relational database design. At the moment I try to setup a one-to-many relationship as clean as possible.

I have two tables: Customers & Orders. Every customer gets a public ID assigned which looks like this: ABC. Every order gets a public ID assigned which looks like this: ABC-123. So you see, the first part of the order number is the customer number.

One rule I've learned is that every piece of data should only be stored once. Storing the order number like ABC-123 would introduce a bit of redundancy because ABC is already stored & every order is connected with the customer using a unique foreign key.

So actually, it could make sense to only store 123 as order number and build the public ID (ABC-123) dynamically if an output in an application is needed.

Is this right or am I too strict regarding redundancy?

Answer 1

Every order gets a public ID assigned which looks like this: ABC-123. So you see, the first part of the order number is the customer number.

By storing customer ID as part of another field, you are actually violating the principle of atomicity, and therefore the 1NF.

So actually, it could make sense to only store 123 as order number and build the public ID (ABC-123) dynamically if an output in an application is needed.

Yes, that's what you should do. You could even construct the "public ID" in a VIEW if multiple clients need it.

As a general rule of thumb: database is for storing data, not formatting it. So you should store the data in a way that makes most sense at the logical level, and leave presentation to other layers of code...