2017-12-07 3 views
0

Ich habe drei Projekte und alle drei Projekte haben bestimmte Informationen, die geteilt werden. Sagen wir zum Beispiel eine Tabelle mit Fahrzeugen (Basisinfo: Jahr, Marke, Modell) und eine Tabelle mit Fahrzeugbesitzern (wieder Basisinformationen: Name, Adresse, Alter). Die Fahrzeug- und Eigentümerinformationen müssen für die drei Projekte zugänglich sein. Was sind die Vor- und Nachteile der Erstellung einer separaten Datenbank für einen einzelnen Zugriffspunkt (insgesamt 2 Tabellen) im Vergleich zur Erstellung einer Fahrzeug- und Besitzertabelle für die jeweiligen Datenbanken für die drei Projekte (insgesamt 6 Tabellen)? Gibt es dafür eine Best Practice?Gemeinsame Daten zwischen Projekten .. Erstellen Sie eine gemeinsame Datenbank?

Danke!

+2

Mit einem zentralen Repository für gemeinsame Informationen (aka - eine Datenbank) ist genau das, was Sie tun sollten. Es sei denn, ich verstehe die Frage nicht. – Yuck

+0

Wenn Sie Codebeispiele wünschen, müssen Sie sich auf einen Hersteller beschränken (mysql oder sql-server). Es gibt zu viele Syntaxunterschiede. –

Antwort

2

Die beste Vorgehensweise besteht darin, alle zugehörigen Daten in einer Datenbank zu speichern. Sie können die referenzielle Integrität in Datenbanken nur durch komplexe Methoden wie Trigger erzwingen. Innerhalb einer Datenbank können Sie problemlos Fremdschlüssel verwenden, um die referenzielle Integrität zu erzwingen.

Eine bewährte Methode seit 2005 ist es, auch die Trennung von Benutzern und Schemata zu erzwingen, sodass Sie nicht alles in [dbo] setzen, sondern für jede Gruppe von Objekten ein relevantes Schema haben. Diese Klassifizierung von Objekten macht es realistisch, Tausende von Tabellen oder Prozeduren in einer einzigen Datenbank zu haben.

In einer modernen Datenbank wie SQL 2005 und höher ist es nicht erforderlich, Objekte über Datenbanken hinweg zu trennen. Sie verfügen über Tools wie Dateigruppen, Partitionierung, Benutzer-/Schematrennung usw., mit denen Sie problemlos in einer Datenbank arbeiten und effizienter arbeiten können.

Als ein Beispiel dafür, warum die Verwendung einer einzelnen Datenbank und das Trennen von Objekten nach Schemas ein bevorzugter Ansatz ist, sollten Sie die Portabilität der Anwendung in Betracht ziehen. In dem Fall, in dem Sie Code von Entwicklung zu Test zu qa dann Produktion verschieben möchten oder wenn Sie Code von Client zu Kunde verschieben möchten, wenn Sie Datenbank-Namen in Ihrem Code eingebettet haben, wird das schwierig.

Möglicherweise haben Sie einen monatlichen Umsatzbericht, der von der Buchhaltung verwendet wird, um Aggregate zu erhalten. Wenn es sich in derselben Datenbank befindet, wird der Verkaufsbericht als []. [] Aufgerufen, und Sie können von [_dev] nach [_prod] wechseln und der Anruf ist derselbe. Wenn Sie andere Datenbanken verwenden, lautet der Aufruf des Verkaufsberichts beispielsweise [Verkauf]. [Dbo]. [Get_monthly_report] (z. B.). Um nun zu einem anderen Satz von Datenbanken mit unterschiedlichen Namen zu wechseln, müssen Sie sich auf einer komplett separaten Instanz befinden, wobei die Datenbanken genau gleich aufgebaut sind. In einigen Fällen, z. B. wenn Sie Code auf eine Client-Site verschieben, kann dies sehr schwierig sein.

Wenn Sie den gesamten Code in einer Datenbank haben, können Sie den Datenbanknamen NICHT in Aufrufen von Tabellen, Ansichten, Prozeduren usw. verwenden, und Ihr Code ist viel portabler und flexibler.

+1

Stimme völlig damit überein. Setzen Sie gemeinsam genutzte Daten in ein freigegebenes Schema, möglicherweise dbo, und erstellen Sie separate Schemas für projektspezifische Daten, wenn Sicherheit ein Problem darstellt. Beachten Sie, dass einige Datenbanksysteme bei der Erzwingung von Fremdschlüsseln zwischen Schemata besser sind als andere, und sich nicht sicher sind, ob MySQL oder frühere Versionen von sql-server verwendet werden. –

+1

Es war SQL 2005, die mit Benutzer/Schema-Trennung kam. Zu dieser Zeit gab es einen Artikel, in dem MS ausdrücklich sagte, es sei "best practice", Benutzer/Schema-Trennung zu verwenden. Das wurde durch eins für Version 2008R2 (das letzte Mal, als ich schaute) ersetzt, aber es wurde seit 2005 Best Practice genannt. Das ist ziemlich nah an zwei Jahrzehnten, und ich werde immer noch lächerlich gemacht, wenn ich dies auf der Website eines Kunden vorschlage! Normalerweise verwende ich etwas Beschreibendes für allgemeine Daten wie [Dienstprogramm], [Wörterbuch] usw. und vermeide einfach die Verwendung von [dbo]. –

Verwandte Themen