父子表MySQL

Question

I was trying to figure out the difference (if any) between two mutually exclusive ways to design a DB.

Suppose we have a table of users consisting of userID 's, what would be considered 'best practice' in terms of storing user data?

Our Table:

userID PK. 

I've seen both of the following being used and it feels that the last one is less useful:

meta data stored:
Method 1:

meta_id(pk), userID(fk), attribute1, attribute 2 ... attribute n  

Method 2:

meta_id(pk), userID(fk),attribute_name,attribute_value  

So instead of having one single meta row for each user, we end up with multiple ones. This is the design WordPress uses.

My Questions:

1. Is one method slower than the other performing queries?
2. Are both of them considered industry standards, and if so, what are the use cases for each method?

Answer 1

Well both of the question does not have a sharp answer. Both are different techniques, both are different designs, both needs different query styles.

For use case, i think pretty simple for this question.

• If your attribute types and number of attrs. are constant (or close to constant) method1 should be used. More specifically, If you can set a logical limit to the number of attrs. then you have an "n" in method1. (since field names are not flex. attr names should be same between objects that you store just like html)

• If you have a random number of attr. & random number of attr. names. Then method 2 should be used. Cause it can adjust to any permutation of (#ATRname , $ATRvalue and #ATRS).

If the correct design used for a DB. performance will not be a problem.

Some more disgusting examples

1. XML objects stored in db.

   • metod1
     • all xml objects can not have more then n number of attributes.
     • unused attrs. means unnecessary storage space and slow quering.
     • inner value will require another fk which points another row in the same table.not a professional method.
     • If this table is small, queries will work much faster. However when it comes to industrial usage. This table literally can not return any values because of its size.
     • Simple 100kb xml file can need thousands of rows.
     • very flexible. one table can store one/more files or/and one/more objects in one table.
   • metod2
     • xml objects can have any number of attributes and attribute names.
     • unused attrs. will not enlarge DB.
     • all tables and rows can be showed in file. Pro stuff.
     • If this db is small, queries will slower because of the number of relations. However when it comes to industrial usage. DB is possible to use
     • Simple 100kb xml file can need tens of rows * tens of tables.
     • all tables need to have a specific purpose about what to store.

2. HTML1.0 objects stored in db.

   • metod1
     • n is the #attributes that is suppoerted by html1.0 .
     • unused attrs. means unnecessary storage space and slow quering because of row size&number (not that much compared to other).
     • If this table is small, queries will work much faster. However when it comes to industrial usage, thanks to html hierarchy tables/files can be divided easily.
     • number of html = number of rows. Delicious
     • not flexible however html hierarchy is not flex. too. one table can store one/more files or/and one/more objects in one table.Over usage of tables and rel.s
   • metod2
     • html objects can have any number of attributes and attribute names. But there is specific number of attrs. that html obj. can have. = Lots of unnecessary tables relations etc.
     • unused attrs. will not enlarge DB.
     • all tables and rows can be showed in file. = no null cells
     • If this db is small, queries will slower because of the number of relations. However when it comes to industrial usage (assuming the complexity& randomness of an html obj and an xml obj, as it is ;) ) table
     • Simple 100kb html file can need hundreds of tables.

Yes both are former designs for industrial DBs. for different purposes.

I assumed that xml objects has random number of subobject with random attr. names . Unlike html. It just have limited number of attrs. in real-life example (because of html is an code representation of visual boxes) it is not be used for complex structures.

In addition

• The most professional design use both of them combined. For example. 2.table looks like a MANY TO MANY REL. between TABLE1.1xTABLE1.2...xTABLE1.N.

• another thing is. i do not feel like meta-id and former-id used together. one is fk and one is pk. which is weird because pk means it can be used for relations. fk means, it should be unique (pro stuff not necessarily) === another mutant pk. It probably helps to backend operations or updates , merging etc.

I hope it helped.