Our group has been developing a webapp to take it live in the future. We got stuck at normalizing a few tables, as it could involve redundancy.

We have some tables that I describe as follows:

  1. shipping table: the address attributes and ID being the primary key.
  2. order table: few attributes along with address attributes and oID being the primary key.
  3. payment/card table: few attributes along with address attributes and pID being the primary key.

Is this in normalized state or do we have redundancy here?

  • You may want to check out Marc Rettig's 5 Rules of Data Normalization to clarify what you need to be doing when normalizing your data. – LowlyDBA - John M Oct 16 '17 at 15:43
  • Review my answer to this question on Stack Overflow. The short answer is that no, you should not worry about redundancy here. These different entities have addresses, that is just a coincidence. They aren't the same data points (at least as far as your system is concerned). Unless you mean to actually manage locations as it's own thing in your system, there's no advantage to splitting addresses away from these tables. – Joel Brown Oct 17 '17 at 10:34

So you have several tables each of which holds an address. You're wondering if these common address-related columns should be in their own table.

The typical answer is "yes" - a separate would be a good idea. There are any number of posts on this subject on this site.

If you do make a common address table will you compare user input to existing rows so you can re-use an existing address_id in one of your tables? If the answer is "no", or you don't have a plan to handle small variations in how the user spells or formats the address, then why bother?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.