Wiele kluczy obcych do tej samej tabeli

Question

Mam tabeli odniesienia ze wszystkimi rodzajami kontrolowanych danych wartość odnośników dla płci, typ adresu, rodzaju kontaktów itp Wiele tabel mają wiele kluczy obcych do tej tabeli referencyjnej

ja również mają tabele powiązań wiele-do-wielu, które mają dwa klucze obce do tej samej tabeli. Niestety, kiedy te tabele są wciągane do modelu Linq i generowany jest DBML, SQLMetal nie szuka nazw kolumn kluczy obcych lub nazw ograniczeń, ale tylko w tabeli docelowej. Więc kończę z członkami o nazwie Reference1, Reference2, ... niezbyt przyjaznymi dla obsługi. Przykład:

<Association Name="tb_reference_tb_account" Member="tb_reference" <====== 
    ThisKey="shipping_preference_type_id" OtherKey="id" Type="tb_reference" 
    IsForeignKey="true" /> 
    <Association Name="tb_reference_tb_account1" Member="tb_reference1" <====== 
    ThisKey="status_type_id" OtherKey="id" Type="tb_reference" 
    IsForeignKey="true" /> 

mogę iść do dbml i ręcznie zmienić nazwy członków, oczywiście, ale to oznaczałoby, że nie może już obie moje schematu bazy danych. Nie jest to opcja na obecnym etapie modelu, który wciąż ewoluuje. Podział tabeli odniesienia na n poszczególnych tabel również nie jest pożądany.

Mogę prawdopodobnie napisać skrypt, który działa na XML po każdym pokoleniu i zastępuje nazwę elementu czymś wyprowadzonym z ThisKey (ponieważ stosuję się do konwencji nazewnictwa dla tego typu kluczy). Czy ktoś znalazł lepsze rozwiązanie tego problemu?

Answer 1

Poszedłem więc ścieżką klas cząstkowych. Na przykład, dodałem następujące państwa do zajęcia pierwszego elementu odniesienia w moim oryginalnym przykład:

public partial class tb_account 
{ 
    public tb_reference shipping_preference_reference 
    { 
     get 
     { 
      return this._tb_reference.Entity; 
     } 
     set 
     { 
      this.tb_reference = value; 
     } 
    } 

jest to dalekie od doskonałości. Wymaga dużej ilości dodatkowego kodu w dużym modelu i zależy od kolejności atrybutów, które nie ulegną zmianie (jeśli do tabeli kont zostanie dodany inny klucz obcy do tabeli referencyjnej, ten element może rzeczywiście wskazywać na coś innego niż preferencje wysyłki). Jest też strona pozytywna. Ponieważ piszę już klasy częściowe do innych celów, dodanie tych elementów nie wymagało ponownego przebudowania aplikacji.

Answer 2

Obecne narzędzia MS dla LINQ to tylko niektóre z ograniczonych możliwości i nie wygląda na to, że nadejdzie znaczny wysiłek w stosunku do roku 2010. Możesz napisać własny generator kodu, spójrz na Damien's t4 templates lub PLINQO. Znalazłem także EDMDesigner, które mogą być warte obejrzenia.

Answer 3

Moje xml z sqlmetal miał znacznie bardziej rozsądne wartości domyślne. nie doskonały, ale lepszy. Pierwsza FK otrzymała nazwę tabeli, ale druga otrzymała nazwę pola.

<Association Name="FK_Product_DefaultOutputTypeID" Member="OutputType" 
    ThisKey="DefaultOutputTypeID" OtherKey="OutputTypeID" Type="OutputType" 
    IsForeignKey="true" /> 
    <Association Name="FK_Product_DefaultTileOutputTypeID" Member="DefaultTileOutputType" 
    ThisKey="DefaultTileOutputTypeID" OtherKey="OutputTypeID" Type="OutputType" 
    IsForeignKey="true" /> 

wersja SQLMetal:

C:\Program Files\Microsoft Visual Studio 9.0\VC>sqlmetal /? 
    Microsoft (R) Database Mapping Generator 2008 version 1.00.21022 
    for Microsoft (R) .NET Framework version 3.5 
    Copyright (C) Microsoft Corporation. All rights reserved. 
    ... 

Answer 4

W VS2010 Można rzeczywiście zmienić nazwę właściwości dla rodzica i dziecka w widoku. Jest jednak nieco ukryty.

1. W przeglądarce dbml wybierz relację, która Ci przeszkadza.
2. W siatce Właściwości zostaną wyświetlone dwa wiersze Właściwości podrzędne i podrzędne.
3. Rozwiń je tam można zmienić nazwę właściwości

Więcej szczegółów można znaleźć tutaj: http://weblogs.asp.net/scottgu/archive/2007/05/29/linq-to-sql-part-2-defining-our-data-model-classes.aspx

czyli tam, gdzie mam go od.