Wie multinationale Datenbanktabellen mit SQL Server entwerfen

Question

ich ASP.NET MVC-Core mit Entity Framework-Core bin mit Code-first (für eine SQL Server-Datenbank), eine Anwendung als Lernübung zu entwickeln. Aus dem Offset möchte ich die Datenbank & Anwendungsdesign in der Lage, multinationale Szenarien zu handhaben.

Um dies einfach zu halten, nehmen wir an, ich habe eine Tabelle & eine EmployeeDetails Tabelle. Wie würden Sie die Datenbank so gestalten, dass die EmployeeDetails je nach Land unterschiedlich sind?

Zum Beispiel in Großbritannien haben wir eine Sozialversicherungsnummer, wo, wie diese Datenspalte an einen Mitarbeiter nicht in einem anderen Land gelten würden.

1. Würdest du 1 Tabelle mit allen möglichen Datenspalten haben, aber sie in der UI gegebenenfalls deaktivieren? Dies würde jedoch verhindern, dass Sie Spalten als erforderlich markieren (nicht NULL-fähig).

2. Müsste Sie mehrere EmployeeDetails Tabellen, eine für jedes Land? Dies würde bedeuten, dass der Datenabrufcode verzweigen müsste. Darüber hinaus müssten Sie mehrere Tabellen verwalten und möglicherweise eine Spaltenreplikation durchführen.

3. Hätten Sie eine gemeinsame EmployeeDetails Tabelle und haben Sie davon abhängige Tabellen mit Datenfeldern, die für ein Land spezifisch sind? d (EmployeeDetails > ED_UK) & (EmployeeDetails > ED_France) & (EmployeeDetails > ED_US)

dynamische Daten Spalten bedeutet auch eine dynamische HTML UI fähig machen nur die zutreffenden Spalten bauen zu müssen. Ich kann mir nicht vorstellen, dass man mehrere UIs für jedes Land erstellen möchte, um die gleiche Aufgabe zu erfüllen.

Ich begrüße es sehr, alle Rückmeldungen und Ratschläge.

Answer 1

Kommt drauf an.

In diesem speziellen Beispiel haben die meisten Länder eine Art Identifikationsnummer, die verwendet wird, um die Mitarbeiter an den Steuereintreiber zu identifizieren. Das Vereinigte Königreich kann es die Sozialversicherungsnummer nennen, die USA können es die Sozialversicherungsnummer nennen, andere Länder werden andere Namen dafür haben, aber es ist begrifflich dasselbe über Länder hinweg. In diesem Fall würde ich eine einzige Spalte hat die Steueridentifikationsnummer zu speichern, aber das Etikett in der Benutzeroberfläche, so dass die amerikanische Version sagt: „Social Security Number“ zu lokalisieren, sagt die UK-Version „National Insurance Nummer“ usw.

Wenn Sie ein vollwertiges Gehaltsabrechnungssystem einrichten, das eine Reihe landesspezifischer Steuer- und Zurückbehaltungsattribute benötigt, dann werden Sie wahrscheinlich getrennte Tabellen betrachten. Jedes Land wird eine einigermaßen einzigartige Einrichtung mit sehr spezifischen Gesetzen und Vorschriften haben, die codiert werden müssen, so dass es sinnvoll wäre, eine Reihe von Tabellen für die Informationen zu haben, die die IRS in den USA benötigt, eine separate Tabelle für die Informationen, die die HMRC im Vereinigten Königreich usw. benötigt. Einzelne Mitarbeiter würden in einer oder mehreren Steuerregimen eingerichtet (vermutlich würden die meisten in nur einer sein) und der Code, der mit diesen Tabellen interagiert, wäre wahrscheinlich sehr spezialisiert. Wahrscheinlich würden Sie das Modul für die Steuerbehörde eines bestimmten Landes von Grund auf schreiben und eine Art Plug-in-Framework für die Hauptanwendung verwenden, anstatt zu versuchen, eine generische Benutzeroberfläche zu schreiben, die sich dynamisch neu konfigurieren könnte die IRS will gegen die Informationen, die die HMRC will, sowie die für diese Steuerbehörden spezifischen Regeln umsetzen.

Answer 2

Dies ist eine hübsche breite Frage, da ich glaube nicht, dass es eine definitive Antwort gibt. Allerdings, wenn Sie so etwas wie in dieser Art und Weise beschreiben ..

diese einfach zu halten, nehmen wir an, ich habe eine Tabelle Employee & eine EmployeeDetails Tabelle. Wie würden Sie die Datenbank so gestalten, dass die EmployeeDetails je nach Land unterschiedlich sind?

Das klingt nach Vererbung könnte hilfreich sein, das Problem zu lösen. So um die Datenspeicherung für eine Minute zu ignorieren, könnten Sie Domain-Entitäten haben, die wie folgt aussehen:

// abstract maybe... 
public class EmployeeBase 
{ 
    public string FirstName { get; set; } 
    // etc... 
} 

// UKEmployee or EmployeeUK whatever.. 
public class UKEmployee : EmployeeBase 
{ 
    // Uk Specific Properties 
} 

Ich mag immer zu sehen, ob die Präsentationsebene Probleme mit einer Architektur hat, bevor auf SQL suchen. Da Sie MVC erwähnt (würde ich AutoMapper zur Karte verwenden Modelle zur Ansicht) für jetzt würde ich ähnliche Modelle abbilden sie nur ...

public class EmployeeBaseVM { ... }  
public class UKEmployeeVM : EmployeeBaseVM { ... } 

Und ich würde die einfache Art und Weise vorstellen, so etwas wie wäre ..

// Encapsulating class for and index method on a controller 
public class IndexVM 
{ 
    public UKEmployeeVM { get; set; } 
} 

würde ich zwei Display-Vorlagen machen (bisher):

UKEmployeeVM.cshtml

@model UKEmployeeVM 

@* display shared properties *@ 
@Html.DisplayFor(m => m, "EmployeeBaseVM") 

@* display specific properties *@ 
@Html.DisplayFor(m => m.SomeProperty) 

EmployeeBaseVM.cshtml

@model EmployeeBaseVM 

@* I hope you get where this is going *@ 

So ist die Präsentationsebene scheint ziemlich einfach, so können Arbeiten an der Datenspeicherung. Da Sie EF verwenden, würde ich vorschlagen, Table per Type Inheritance zu verwenden. Keine Notwendigkeit, in die Details zu gehen, diese Seite erklärt es gut.

Allerdings geht es nicht ins Detail über SQL-Struktur. Es scheint, Sie pseudo-unbegrenzte Länder haben so statt ..

[dbo].[EmployeeBase] 
[dbo].[UKEmployee] 

, die wie es scheint, unhandlich bekommen könnte, würde ich zu Schemen für Ihre Segmentierungen empfiehlt wechseln.

Der Nachteil ist, dass neue Länder oder Funktionen neue Schemas, EF, Domain, Viewmodels erfordern. Ich glaube, dass es einfacher ist, Code zu schreiben, der genau das Modell kennt, um dann einen dynamischen Code zu schreiben, der versucht, einen Catch-All für die Zukunft zu machen.