Home/ Questions/Q 7835665
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T13:44:08+00:00

This is a simple question, but I think I always used the wrong way.

  • 0

This is a simple question, but I think I always used the wrong way.

I have three tables called Page -> Tag -> Attribute. The Tag table receives the Page_Id (foreign key) and the Attribute table receives the Tag_Id (foreign key).

The Attribute table must receive the Page_Id too?

I never did this, but I saw a database SQL generator that does this, and so, I realized that this turns all the work easier, but this is the right way too?

Edit with details of the tables: The Page table contains HTML pages and some attributes like the content, the title, doctype and all other single elements of a html page.

The Tag table contains the HTML tags of a html page with informations like the tag (a, p, br, h1, title, etc.) and the entire tag.

The Attribute table contains all the attributes of a tag and is like a Map with key and value where each entry is an attribute and a value.

Page contains multiple tags (1:N) and tag contains multiple attributes (1:N). Each table contains a unique identification.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is one of those “it depends” situations – you don’t, logically need the value to be stored in Attribute, since you can derive this information by joining to Tag.

    But, in some circumstances, it may be useful for you to be able to “jump” from Attribute to Page without having to join to Tag. In such a situation, you can include Page_Id in Attribute, but you should add additional constraints to ensure that it isn’t inconsistent with the value stored in Tag.

    You would enforce this consistency by having two keys declared in Tag – the usual key you define (e.g. Tag_Id), and also a superkey on Tag_Id and Page_Id. You would then declare a foreign key constraint in Attribute that includes both columns, and references this superkey. Whether you do that instead of the foreign key constraint on just Tag_Id, or in addition to it, can also be a matter of preference/style.

    If it’s likely that Tags will change Pages, then you would normally declare the foreign key to the superkey as the one on which an UPDATE CASCADE occurs – in this way, if the Page_Id changes in the Tag table, that change will be automatically applied in the Attribute table.

    • 0