Database Reference
In-Depth Information
So, we need to store many videos for a unique user. You already know that we
decided not to store the video itself, for purely technical reasons. There are other
reasons also, which we have mentioned here:
• The video is not a part of the videos table because its entry in the table might
be ready when the video is not.
• Your performance profiling and debugging will be messed up if you combine
the big and small data pieces.
• Anyway, it is usually stored in a content delivery network ( CDN ) because
it is a better and more practical way of video delivery. (You can read more
about CDN at http://en.wikipedia.org/wiki/Content_delivery_
network . )
With this, here's my table description in terms of SQL, as enabled by Phoenix:
// Entity table that will store many videos for a unique user
CREATE TABLE videos (
videoid uuid,
videoname varchar,
username varchar,
description varchar,
location map<varchar,varchar>,
tags set<varchar>,
upload_date timestamp,
PRIMARY KEY (videoid)
);
Here are specific points to note about this code:
videoid uuid : We already mentioned that UUID is a first-class citizen in
the NoSQL world. The video's name cannot be considered as a natural ID.
We cannot, and should not, use sequence keys for a video ID, but using
UUID on the other hand is OK.
username varchar : The username belongs to one user, and it is already
found in our user table. However, note that we duplicated the username
here, rather than creating a column to join the user and video tables. That,
of course, is the NoSQL design pattern to avoid joins. The username is what
we will need when we query the table, so we will put it here. On queries,
we will obtain both the video and the user information in one go. Had we
needed more user information, we would likely put it in our video table
also. It is true that we will need to maintain this information in both the
tables, but that is exactly the point.
 
Search WWH ::




Custom Search