Re: Proposal for bookmarks/history database



Table layout, attempt 3.

On irc chpe mentioned that history items should use a url-id to avoid
keeping the same url thousands of times. There's also some other minor
tweaks...

-------------------

Just remember, every 'node' of data is given a unique id. All these
tables do is record different types of information on that node. There
is *no* global list of all nodes.

# parent-child relationships between nodes
table 'children'
  int id
  int child

# data of high-level nodes that are used to organise the other nodes
table 'globals'
  int id
  string name

# data related to page visits, refers to a url node
table 'visits'
  int id
  int url
  date visited

# data for visited urls
table 'urls'
  int id
  string url
  string title
  string icon

# data for bookmarks
table 'bookmarks'
  int id
  string url
  string title
  string icon

# data related to user-specified topics
table 'topics'
  int id
  string name

-----------------------

Q. Why have urls and bookmarks separate? It's the same data, right?
A. Entries in the 'urls' table are static. The 'bookmarks' table is not.
   eg When you visit a page you will want to record that you visited it.
   That will involve a quick search of the 'urls' table for a matching
   url,title,icon triple. If found, your new entry in the 'visits' table
   will refer to that. If not, you will make a new one. If a *bookmark*
   was in the urls table, and you referred to that, then your history
   would be updated when the bookmark was edited by the user. Not nice.
   We *could* just add a boolean 'static' flag to the urls table. That
   would solve it. Please register your votes. :)

Q. Can I store searches here?
A. Yes. Just store it as a url with a special marker (I like newline)
   in the middle, and make it a child of the node which is called
   'searches' according to the globals table.

Q. How do I store a bookmark?
A. Create a node (unique number) and add an entry to the bookmarks
   table. Then take the node called 'bookmarks' in the globals table
   and make your new node node a child of that node.

Q. Why not just have one table per attribute? Name, icon, url, etc?
A. I'm not a database expert, but I would *assume* that would make 
   queries horribly slow as you'd need to correlate data from multiple
   tables simultaneously. I've tried to ensure we correlate no more
   than three tables at once for most things.

Regards,
Peter.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]