Relationships in Servoy - PK and FK use

Classic Servoy
1

When creating a one-to-many relationship I thought that standard practice was that you join up the PK in the parent table with the FK in the child table.

However, in Servoy I am seeing instances where the FK in a table is being described as the PK and is then linked to another table’s PK , but which is being described as the FK.

For example, in the demo CRM application I see a relationship that has been created called “contacts_to_addresses”. The Define Relationship dialogue shows that the PK of the contacts table is “address_id” and the FK of the Addresses table is “Addressesid”. However, in the tables “address_id” is actually only the FK in the contacts table while “Addressesid” is the PK of the Addresses table.

This has got me a little confused and I don’t quite understand the ramifications. Can anybody shed some light on this. Many thanks

MerMer

2

Relationship dialogue shows that the PK of the contacts table is “address_id” and the FK of the Addresses table is “Addressesid”.

Actually the PK of contacts is contact_id.

Indeed this might be confusing, but keep in mind that relationships can be used in order to show/edit all kinds of related data.

So basically there are 2 types of relationships

  1. pk>fk based on physical datamodel (creation/deletion etc.)
  2. “freely” build relations used for filtering, searches, valuelists etc. based on your logic rules.
3

Marteen,

I appreciate that the PK of contacts is contact_id. My point is in the relationship dialogue box it is shown as the FK, unlike in the table. That’s where I was confused.

Your points that there are 2 types of relationships is a help. It might help (at least for the novices like me) to eventually seperate these out in Servoy, so it is clear.

Many thanks.

MerMer

4

hmmm… I have to agree that the terms Primary Key and Foreign Key here are at a minimum misleading, and in some cases just wrong.

Let’s stick with relations based upon a solution’s data model. When creating a relation from a parent to a child table these terms are appropriate. But this relation does not provide the child table access to the parent. That requires the creation of another relation that is fk>pk. In this case the labels are just wrong, and confusing. Really a relation starts at a source table, and ends at a destination table, and have no bearing on primary keys and foreign keys.

From a teaching point of view this can be VERY confusing to new users, particularly those that have plenty of experience in db modeling.

I’d vote for some sort of wording change here, as it leads one to think they may be doing something wrong.

Cheers,

Rich

5

Hello Rich and all others

coulombre:
hmmm… I have to agree that the terms Primary Key and Foreign Key here are at a minimum misleading, and in some cases just wrong.

I agree completly here, it’s misleading.

coulombre:
Let’s stick with relations based upon a solution’s data model. When creating a relation from a parent to a child table these terms are appropriate. But this relation does not provide the child table access to the parent. That requires the creation of another relation that is fk>pk. In this case the labels are just wrong, and confusing. Really a relation starts at a source table, and ends at a destination table, and have no bearing on primary keys and foreign keys.

I also agree here. Please do NOT introduce a special notion, the ER-Model as invented by Peter Chen in 1974/75 has already named the terms and the literature uses them as well and it’s taught like that in universities, so if we use them in another way we gain nothing but everything is more complicated, not the least talking and explaning here in the forum something.

coulombre:
From a teaching point of view this can be VERY confusing to new users, particularly those that have plenty of experience in db modeling.

Yes, again I agree, I already have problems explaining something to collegues because they ask why is it like this and it get’s confusing.

coulombre:
I’d vote for some sort of wording change here, as it leads one to think they may be doing something wrong.

Cheers,

Rich

Yes please! Label the Column in another way but if the column title says PK and in fact the content is a foreign key, it makes no sense at all except confusion everybody. And this is not the way Serrvoy should differentiate itself from other products .-)

Best regards and hoping very strong for a correction, Robert