User talk:Mak77: Difference between revisions

Jump to navigation Jump to search
Line 55: Line 55:
Why this and not a classic (id, tag)+(id, item_id) approach?
Why this and not a classic (id, tag)+(id, item_id) approach?
Thinking to the merge case, doing UPDATE moz_tags SET tag = "X" where item_id = "Y" would automatically merge or split tags at no cost.
Thinking to the merge case, doing UPDATE moz_tags SET tag = "X" where item_id = "Y" would automatically merge or split tags at no cost.
The primary key for such a table would be a compound one (tag, item_id), but we will most likely also need single indexes on both columns
The primary key for such a table would be a compound one (tag, item_id), but we will most likely also need single indexes on both columns.
 
Tags should be case-insensitive, so always saved as LOWERCASE in the db


=== keywords ids out of bookmarks table ===
=== keywords ids out of bookmarks table ===
Confirmed users
595

edits

Navigation menu