Re: How to store/manage tags?

From: Lew Pitcher <lew.pitcher_at_digitalfreehold.ca>
Date: Sat, 13 Jul 2019 17:18:26 -0400
Message-ID: <qgdhr3$c3c$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!

See my other post wrt this observation.

>> 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

Yes

> but you removed id_restauranttag

Yes, as I explained, it wasn't necessary.

>> 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! :)

Thanks

-- 
Lew Pitcher
"In Skills, We Trust"
Received on Sat Jul 13 2019 - 23:18:26 CEST

Original text of this message