Database Reference
In-Depth Information
scenario this may turn out to be quite expensive. However, two things need to be
noticed: first, the worst-case scenario happens only when each data row in the
database has some user-created content attached to it by a single user . Even though
a user can attach some content to many data rows at once by using a large size result
of some query, this could still be considered unlikely in a real-size database. But,
most importantly, the system proposed here is envisioned mostly to be used with
metadata , and only occasionally with data. Indeed, users are normally interested in
interpreting and understanding the results of their queries, and for this task the
metadata is of considerable help. As a second consideration, if the private data
increases significantly, standard database techniques (indices, etc.) can be used to
achieve better performance.
Finally, to attach values, we add user-created content to each data row. When
presenting the enriched result to the user, however, the full outerjoin above may generate
considerable redundancy, since, as stated earlier, a given data tuple may have several
items of user-created content attached. In particular, when the user attaches a tuple,
the normalized storage proposed creates several duplicates of the original data
tuple. Thus, alternative presentations of the information should be considered. For
instance, even though not truly a relational table, a slightly different arrangement
could attach all tags or comments to a data tuple together, without duplicating it.
When a set of rows have the same user-created content attached, this could be shown
by displaying the rows together and visually attaching the content to all of them as a
block, without repetitions. Of course, this will not avoid all repetitions (as previously
stated, the relationship between data and user-created content is many-to-many).
Nevertheless, duplication in enriched answers can be avoided to a certain degree.
This applies to structured (tuples) and unstructured (tags, comments) internal con-
tent. With respect to external content (links), there are two obvious choices: to
simply display the link itself, or to actually follow the link and display the contents of
whatever it points to. It is here that having typed links would help the system deal
with different kinds of references (i.e., URLs versus filenames).
7.5.3 Private View Sharing
Recall that the ultimate goal is to enable user-user communication. The private data
can be used to foster inter-user communication in several ways (we discuss this in
Sect. 7.6 ). However, so far all user-created content is kept private : only the user
who authored the content can see it. Thus, a user u could be given the option to
share Pv ( u ) with other users. We envision the database system supporting a share
command with a syntax along the lines of
PUBLISH DATA TO ALL| SIMILAR | UserList
where
l ALL means to all users.
l UserList is a list of users with whom we want to share the data.
Search WWH ::




Custom Search