.NET DataSource vincolante per legacy DB SQL Server con relazioni non definite

3

Sto progettando un programma di utilità che caricherà i dati in un database SQL Server legacy.

Ho cercato di prendere in giro una semplice utility WinForms con C # usando i connettori DataSource (Ho provato un approccio diretto per ORM Entity Framework, ma avevo problemi in quanto il db segue alcune convenzioni).

Sto riscontrando particolari difficoltà nello stabilire relazioni parent / child e visualizzarle con le griglie di dati (cioè, fare clic su questa riga e la griglia figlio viene filtrata).

Alcuni esempi di sfide del database:

  • Nessuna chiave esterna con vincoli referenziali. Quello che normalmente sarebbe una chiave esterna viene visualizzato come parte della chiave composita primaria nella tabella "figlio". A volte con diversi tipi di dati (ad esempio, doppio anziché lungo)

  • A volte una chiave composta viene usata su una tabella genitrice per definire l'entità, ma solo uno di quei campi compositi compare in una tabella "figlio". {dbo.Parent Key = [ParentID, ParentGroupID, OtherField], dbo.Child Key = [ChildID, ParentID]}

  • Le convenzioni di denominazione sono inesistenti.

Cose come questa rendono difficile legare i set di dati alle griglie di dati padre / figlio e utilizzare alcune delle altre funzionalità che .NET offre.

Come affrontare le sfide precedenti?

Ho provato a guardare alcune vecchie esercitazioni su ADO.Net ma a volte i metodi sono cambiati o non sono più disponibili ...

    
posta wesmantooth 02.05.2014 - 21:52
fonte

1 risposta

-1

Il tutorial suggerito da wesmantooth sembra andare bene, ma sto pensando a qualcosa di più contorto. Se hai il tempo disponibile e questa applicazione vivrà almeno per qualche anno, puoi provare quanto segue (almeno in parte):

  • per ogni tabella legacy definisci una nuova tabella (posizionala in un nuovo schema) che contiene le stesse informazioni, ma ha nomi di colonne decenti e tutti i vincoli appropriati
  • le nuove tabelle possono avere tutte le chiavi esterne appropriate per garantire l'integrità e ottenere anche le proprietà di navigazione (EF)
  • ogni volta che si persistono alcuni dati, è possibile salvare facilmente nelle nuove tabelle e chiama una stored procedure per aggiornare i dati nella vecchia struttura - Penso che MERGE è il tuo migliore amico qui.

I vantaggi principali sono: lavori con strutture dati decenti nel tuo codice .NET, recuperi dati più semplici e la logica persistente dei dati e apri la prospettiva di liberarti di una brutta struttura di dati legacy in futuro.

Il principale svantaggio è il grande sforzo per farlo. Vorrei iniziare con quelle tabelle che sono meno utilizzate nei report, ETL ecc.

    
risposta data 11.12.2015 - 22:33
fonte

Leggi altre domande sui tag