IDEA: Better FK constraint naming rule

[Paolo F Cantoni]

The current EA Foreign Key constraint default naming rule is:

FK_<origin_table_Name>_<destination_table_name>

Long experience has shown that is is insufficient to ensure unique constraint identity, especially in RDBMS technologies that require global uniqueness of foreign key constraint names.

A better naming rule has been shown to be:
FK_<origin_table_Name>_<origin_inversion_column_set_name>_<destination_table_name>

where <origin_inversion_column_set_name> is the name of the column-set in the origin table that forms the "Child" (or inversion) end of the relationship.

How do you derive the name of the name of the inversion column-set?  If there is only one column involved, then it's easy, just use the column name!  If there is more than one column involved in the set, then (typically) there should be a named Inversion Index created to assist in relational joins, that index name should be used.  If such an index doesn't exist, then a name can be synthesized from the names of the columns involved in the column set.

In any event, the current naming rule doesn't allow for more than one relationship between any two tables and is thus defective.

Thoughts, Votes?

Paolo

[size=0]©2007 Paolo Cantoni, -Semantica-[/size]

[sargasso]

[sigh] You are, [sigh] as usual right, (and [sigh] about 20 minutes ahead of me[/sigh]) [/sigh][/sigh].

Although,what I've been doing is just sub anotating the keyname  (manually) the name as
FK_<origin_table_name><[1..n]>...

My vote (for your proposal) +++


bruce

[mfritz]

I have to add some things:

what I miss in EA is, to set default visibility for link labels.

what does is mean: in huge db-modells, it is impossible to keep the overview, because of these multiple labels which were attached to the relationships.

what might be helpful is that you can define the visibility of these label for the whole model or diagram.

[Paolo F Cantoni]

I have to add some things:

what I miss in EA is, to set default visibility for link labels.

what does is mean: in huge db-modells, it is impossible to keep the overview, because of these multiple labels which were attached to the relationships.

what might be helpful is that you can define the visibility of these label for the whole model or diagram.

This has been asked for before.  

However, we have found it best to keep each thread to (basically) one topic.

Can you start a new thread with the topic DB Relationship label visibility?  Or even search for the previous instance.

Remember to formally report it to the Sparx support email address: [email protected], or use the support link at the top of this page.  You can reference the post in your report and then Sparx can view any additional commentary.  It would also be good if you could report any Sparx response into the Topic.

Paolo

[«Midnight»]

So, back to the original idea...

I'm in. The names would be clumsy. So what? It'll work, and that pays the bulldog.

[professorg80]

I vote for this one!!!!!

Robert

[cpelster]

Hi,

are there any news on this topic?

regards,

  Christian

[gdmile]

FK naming is surely a destination platform specific issue,  for example, a defaulting name that uses upper case prefixing is just not going to work in postgresql.  

There should be a way to specify how Enterprise Architect names any specially or automatically created item, especially if that has or could have downstream impacts.  EA should provide a destination platform specific naming convention, just like it does for platform specific attributes e.g int v integer, date v datetime, etc etc.  

I have just been caugt out on the same issue that the original poster was indicating. EA kept overwriting the 5 FK's with a single one because of this silly naming convention.  ... I only picked it because I have to go through the DDL script, all 1112 lines, every time and convert all the ' fk ' names to lower case.


I'm beginning to think this isn't all it's supposed to be.

Sandy
 

[«Midnight»]

Good point Sandy et al.

IMHO this is an area where a bit of work by Sparx could yield great benefits. They (Sparx) could enhance the Database Datatypes dialog, create an Options 'tree' for DBMS generation (much as they have for programming languages), or both.

David

PS: Perhaps there has been some movement on this for version 7.0; let's all look at the beta when it comes out.