> I would, so if you wanted to add extra info about the user down the road that data will be abstracted.
That’s a developers perk. Solve problems that don’t even exist yet :) You can add a date column as well, so you know when you’ve read/watched something.
Go with `utf8_unicode_ci`, because we are using `utf8` almost everywhere already anyway it makes sense to store data as `utf8`. There is something on stackoverflow about `utf8_unicode_ci` vs `utf8_general_ci`, comes down to that `unicode` is more precise. `ci` just means case insensitive.
Is every URL you store going to be unique? If not, then will every URL+title combination be unique?
What I’m getting at is that, while every table should have an index, that index doesn’t _need_ to be artificial. “Natural” indexes are preferable, in fact, while also bringing the performance benefits @CrocoDillon mentioned.
**If** every URL+title combination will be unique, do `PRIMARY KEY( url,title )` and drop the `id` column.
You _might_ want to index the `title` column (separately) also, if you ever plan on searching by title without the URL.
Otherwise, **if** every URL will be unique, do `PRIMARY KEY( url )` and drop the `id` column.
You _might_ want to index the `title` column also, if you ever plan on searching by title.
Every `URL` and `Title` will be unique. The only way that they wouldn’t be is if I read the same article (title) from the same website (url) continuously. But Readability does not allow duplicate articles so that would be impossible.
I don’t ever plan on using any of the data to be searched. I only plan to list it as shown here.
I “plateaued” for a long time with SQL. Like, _five years_ of mediocre SELECT statements and not much else. It’s only in the last six months, really, that I’ve had an explosion of understanding… and I still have a long ways to go.