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. _______________________________________________ epiphany-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/epiphany-list
