EF relationship from Foxpro migration, with composite key

Asked

Viewed 40 times

2

I’m migrating a legacy Visualfox system on . Net where the tables were made all without relationship, in ADO, without Foreign key in relationships. Just comparing a string of the name "Type" to differentiate if the record in a Table, for example: Address belongs to Correspondent, Store or Customer.

The system is very large and there are several relationships similar to this for example: Store and Correspondent have a table Contact also relating the ID and differentiating by type(string).

It is very difficult to mirror this rule in EF (if possible, because I am a beginner and I am still learning). The table looks like this:

EnderecoId - ReferenceId          - Tipo                 - Logradouro
1          - 1                    - Loja                 - Rua tal tal tal
2          - 1                    - Correspondente       - Rua tal tal tal
3          - 1                    - Correspondente       - Rua tal tal tal
4          - 1                    - Cliente              - Rua tal tal tal

Is it possible to make these rules using a Type string as a way to differentiate addresses? If it is not possible, it would be right to use Composite Key in this case?

  • What does the last sentence mean?

  • It is that he edited the previous question, but that is a completely different doubt.

  • Related: https://answall.com/questions/201008/problemas-ao-mappingco-data-entity-framework

1 answer

1


The Entity Framework natively does not have this ability to intuit the type of the related table automatically, by using a column, for example.

If I were you, I would do a job on SQL to improve this table. Remembering the approach 1, add 3 new columns to your table:

ALTER TABLE Enderecos
ADD LojaId int null,
    ClienteId int null,
    CorrespondenteId int null;

Faria 3 UPDATEs to popular these columns:

UPDATE Enderecos
SET LojaId = ReferenceId
WHERE Tipo = 'Loja' ;

UPDATE Enderecos
SET ClienteId = ReferenceId
WHERE Tipo = 'Cliente' ;

UPDATE Enderecos
SET CorrespondenteId = ReferenceId
WHERE Tipo = 'Correspondente' ;

We will therefore have:

EnderecoId + ReferenceId  + Tipo            + Logradouro      + LojaId + ClienteId + CorrespondenteId
1          | 1            | Loja            | Rua tal tal tal | 1      | null      | null
2          | 1            | Correspondente  | Rua tal tal tal | null   | 1         | null
3          | 1            | Correspondente  | Rua tal tal tal | null   | 1         | null
4          | 1            | Cliente         | Rua tal tal tal | null   | null      | 1

Only with this the Entity Framework is able to understand the relationship by approach 1 (using inheritance).

  • Oops, vlw for the Gypsy answer! So precisely why approach 1, was not accepted by the staff here by Lojaid, Clienteid and Correspondenteid to be inserted null. I thought that using Type and Referenceid, I would eliminate the problem of keys being null. But it doesn’t seem possible either, does it? Also I can’t use that approach of having Client, Clienteaddressee, Correspondent, Correspondenteendereco pq said it would have many tables. My impression is that they are trying to create something that does not exist. Ta complicated...

  • I think the team lacks knowledge. Heritage, as outlined in approach 1, creates a single table, Endereco with a column Discriminator which specifies the type of each address entity. It’s more or less what you have today with the column Tipo, only in the format that the framework works.

  • That’s right. When I did this approach with Discriminator, I also got Lojaid, Clienteid or Correspondenteid coming null. Looking at the chart you just created, mine just went without the Referenceid and Type. Only address information, Discriminator and keys that can be null. Perfectly normal right?

  • Yes. The values of Discriminator evening EnderecoCorrespondente, EnderecoLoja and EnderecoCliente. A little different, but nothing a data migration can’t fix.

  • Vlw for help again Gypsy. A hug!

Browser other questions tagged

You are not signed in. Login or sign up in order to post.