I've the next tables:

______________         ___________      ___________
Persons       |        Enquiries  |     Products   |
______________|        ___________|     ___________|
PersonID      |        EnID       |     ProductID  |
FirstName     |        EnDate     |     Product    |
LastName      |        Enquiry    |     Price      |
Email         |        ___________|     ___________|
Etc.          |

I am will make single:D relationship between Persons and Inquiries. Additionally, there are an explicit M:N relationship between Inquiries and Items. However, You shouldn't have for that business folks to record whether an enquiry is all about a specific product or otherwise.

My question: From the logical design perspective, will i still have to record the connection around the ER diagram and implement it inside my RDMBS even when I am not will make any utilization of it?

Thank you, zan

I suppose you are able to eliminate the connection knowing it should never be used. This can keep your design simpler and much more workable. Or merge the 2 organizations in to the Inquiries one.

Relationship between tables are produced just for reasons. If you're the developer and also you will not be developing something which uses the connection between product and inquiries table, then why create it.

RDBMS does not promote or restrict the development of relationship. Create them if needed, else leave them.

From the experience, if you are even asking this, you will want to create the table.

In the sounds of the question, you've feelings there might be a use for mapping the data between Enquiries and Products, either now or later on.

Many-to-Many tables, when implemented in this way:

P_ID       FK, int
E_ID       FK, int

Are extremely small tables, take under 5 minutes to setup, and may be overlooked with little consequence. However, as soon as it makes its way into someone's mind that "hey, we ought to have the ability to tell which items individuals are asking about", the action of creating these kinds of tables, in addition to applying the DML in to the application logic turns into a discomfort.

Plus, all you want do is write your SELECTs to obtain the complete report on specifics of the subject obtainable in the machine, rather than waiting until there is an accumulation of records within the table to reply to the question.