Design learning database

A learning Chorme design data

When the work was found, Chrome history stored in the file:
%AppData%\Local\Google\Chrome\User Data\Profile 1\Historyit is a SQLite database file.

visitsTables, records the history of each, as follows:

urlsTable, each url is not repeated, and only the primary key, and its visit_countfield records all visits each url.

Give me inspiration:

1. Try to write directly to each Chrome history, but it did not do it, but to each url as a unique primary key, effectively reducing wasted storage space caused by excessive url.
2. By urlsand visitsdifferent coupling mechanisms to achieve faster query.

How do is guess Chrome

Case A: When you add a history:

1. Update urlsthe table, if the primary key already exists, simply update visit_count field and last_visit_time field. If the primary key does not exist, a new record is created
2. Update vistitable, a new record, url field populated urlstable's primary key.

Case B: When a user queries the entire history:

visitsLeft link urls:

SELECT u.url, u.title, v.visit_time, u.visit_count 
FROM visits v LEFT JOIN urls u on v.url=u.id

Case C: When a user queries a specific history, such as title contains 'you know' this string:

SELECT u.url, u.title, v.visit_time, u.visit_count 
FROM visits v LEFT JOIN urls u on v.url=u.id 
WHERE u.title LIKE '%你就知道%'

There is a problem, this situation should use the sub-query faster? Case for more data, such as start urlstable to obtain the corresponding id, then based on the id to query the visitstable should avoid too many strings match.