如何组织和管理数据库中的“嵌套”表？

Question

I've just started exploring SQL databases, but I've run into an issue with how I store 'compound' structures in an existing table (if that's even the right way to go about it). For example, let's say that I have a database table with rows of users , where each user has a Unique ID , a hashed password , an email address , a phone number , etc.

Simple enough. But, then I want to allow each user to create and store an array of posts . Each post would have a post id , content , date , and various other metadata. If this was C++, I would probably have an array/vector of Posts as a member of the User class, and than I'd store an array/vector of User objects somewhere. Is it possible to store a table within a table in SQL, so that each user has access to their own individual table of posts?

Or, would it be better to create two separate tables (a users table, and a posts table), using some common element (like user ID or user name) to retrieve user-specific data from the posts table, and vice-versa?

I'm trying to understand how to implement a complex database that might be able to manage a large number of users, with user-specific sets of data like posts, messages, etc. So what might be a good approach to take going forward?

Answer 1

As you already mentioned, in relational data model, you can define two tables like below:

table 1 : Users

user_id      user_name
-----------  ------------------
1            'Tom'
2            'John'

table 2 : Posts

post_id    user_id       content                post_date          
--------   ----------    -------------------    ---------------------
1          1             'Hello, I am Tom.'     2014-04-02 14:14
2          1             'good bye'             2014-04-02 20:10
3          2             'I am John'            2014-04-02 22:22

You can read an introductory article here:

Relational_model: http://en.wikipedia.org/wiki/Relational_model

Hope this helps.

Answer 2

You don't store table within table. You can store data in multiple tables and assign primary key for one table and foreign key for another table.
Read about Primary key, Foreign key and Relational Model.
Once your these concepts are cleared read about Database Normalization

Answer 3

You don't store tables within tables. As your third paragraph suggests, the strategy is to use some common key to "relate" table rows to each other.

The "unique ID" you describe is usually called a "primary key". You might have a table of users with a primary key that auto-increments each time you add a record. A function would be available to you so that after inserting, you could determine what the primary key is of the record you just added, so that you can add records to other tables that refer to the primary key of the users table.

You should probably read about Database normalization ant the relational model , specifically about the differences between Normal Forms .

With regard to selection of a field to relate posts to users, I suggest you don't use the username, and instead use some internal reference that isn't visible to the users. While your application might not allow it now, if you wanted to offer users the opportunity to change their username, tying internal database structure to something based on user input would only cause problems in the future.