Re: How to store/manage tags?

From: Lew Pitcher <lew.pitcher_at_digitalfreehold.ca>
Date: Sat, 13 Jul 2019 16:54:10 -0400
Message-ID: <qgdgdj$486$1_at_dont-email.me>


^Bart wrote:

>> Here, in restaruanttags, you don't need the id_restauranttag. As there
>> should only be one combination of FK_id_restaurant, FK_id_tag per row
>> (that is to say that no restaurant will have two or more identical tags),
>> the

> 
> Yes it's true, a restaurant could have just one time "sea view" and
> "romantic" but other restaurant could have same tags for this reason I
> created a tags table and I'll enable a search engine to filter them!

No, I haven't made myself clear...

You would hardly describe "Restaurant Bart" as "Romantic" and "Romantic", so the restauranttags table would only have /one/ entry consisting of   id_restaurant == "Restaurant Bart", and   id_tag == "Romantic".

Of course, "Restaurant Lew" (a different restaurant) could also be "Romantic", so the restauranttags table would also contain a single, unique, entry consisting of
  id_restaurant == "Restaurant Lew", and   id_tag == "Romantic".

That combination, ["Restaurant Lew", "Romantic"] is unique, and does not intrude on any other tag for "Restaurant Lew", nor on any other restaurant that has a "Romantic" tag. The same goes for ["Restaurant Bart","Romantic"].

For our two restaurants, the restauranttag table might look like...

  "Restaurant Bart","Romantic"
  "Restaurant Bart","Sea view"
  "Restaurant Bart","Seafood"
  "Restaurant Lew","Romantic"
  "Restaurant Lew","Rustic"
  "Restaurant Lew","Wildlife"

Thus, the /combination/ of id_restaurant and id_tag results in a unique key. And, so, you do not need an additional id_restauranttag to provide a key to row unqueness.

FWIW, this works. I've used the same layout, for the same purpose, in a successful recipe program.

>> FK_id_restaurant,FK_id_tag combination is sufficient to uniquely identify
>> the row, thus
>>
>> CREATE TABLE restauranttag (
>> id_restaurant ...,
>> id_tag ...,
>> FOREIGN KEY (id_restaurant) REFERENCES restaurants(id_restaurant),
>> FOREIGN KEY (id_tag) REFERENCES tags(id_tag),
>> PRIMARY KEY (id_restaurant,id_tag)
>> ) ;
>> should be sufficient.

> 
> It means three tables, like what I wrote in my original post, are needed
> but you removed id_restauranttag
> 

>> FWIW, if you add "ON DELETE CASCADE" to those two foreign keys, then
>> mysql will delete the corresponding restauanttag row if you delete either
>> the id_restaurant from the restaurants table (say, on a restaurant
>> out-of- business), or the id_tag from the tags table (say, an obsolete
>> tag). This makes maintenance of the restauranttag table easier, as it
>> will have no "hanging" FK references.
> 
> Good idea! :)
> 
> Regards.
> ^Bart


-- 
Lew Pitcher
"In Skills, We Trust"
Received on Sat Jul 13 2019 - 22:54:10 CEST

Original text of this message