SQL模式设计和规范化

Question

I've designed tables for my projects a few different ways and I'm curious to have peoples opinion if they feel one is more correct.

The example will involve Users,Stores,Addresses, and Phone Numbers.

Example A

• user table - contains all main user data
• user address table - contains all address data
• user phone number table - contains all phone number data
• store tables mimic the above standard

Saving

once a parent entity is saved, everything else can be batch inserted/updated

Example B - address table - contains all address data - phone number table - contains all phone number data

• user table - contains all main user data
• user address table - is a linking table to the address table
• user phone number table - is a linking table to the phone number table
• store table - mirrors the above standard

Saving

I would start a transaction and loop through all addresses saving them one by one. Getting the last insert id and link them to the respective foreign entity.

This method forces the use of active record from what I can see and has no solution for doing batch insert/updates but greatly decreases the amount of "main" tables that in the database

Thoughts

As more time goes on I'm starting to believe example B is incorrect. Normalization is about not duplicating data for their respected entity, not duplicating storage areas for your entire database.

Anyways all thoughts/opinions are greatly appreciated. Thanks!

Additional thoughts

So I've been thinking about this some more and here are my thoughts

A user and store in this example would fall into the category of an aggregate root in DDD. This says that any child object should not be able to exist without the parent.

In example A if you delete a user or store there would be no way to have it deleted by foreign key, which I think screams that it breaks the aggregate root rule.

Even though phone numbers and addresses have unique id's within the database and may even have those id's referenced at times through out the db they are still in fact value objects. Users and stores would be the real entities in this situation having value objects of phone numbers and addresses ( even though they have an id )

I was also confused in Example A how to load things using the repository pattern without having repositories talk to each other. Which this new line of thinking also resolves.

Answer 1

I would suggest do the following. Create a table where duplicates or multiple records are not required.

Users : All user data including phone no,addresses ets Condition : The above should be applied when each user has a single phone number and single address.

The above could be used but for multiple phone no, and addresses you will have to use comma seperated field. To search in Comma seperated fields you will have to use FIND_IN_SET.

Users : All user data excluding phone and address
Phone : linked with users with foreign ket
Address : Linked with users with foreign key
In this Method you will have to use joins
And for insert and update you will need to use loop.

Recommendation
I would say use first method . And use second method when you really need it for example a user has many posts so create a table posts because there posts can be too many not a limited no but in the case of addresses and phone no they could be limited.