Datenbank zu einem Genehmigungsportal

[Säsch]

Danke für deine Hilfe,

ich tu mir noch schwer damit :/
Ist aber eine gute Übung für die BA.

so in etwa?

 

[Distrilec]

Ich würde in "Signatures" statt ""Foreignkey_Grouped_Subscriber" den echten "Subscriber" referenzieren. (Thema Traceability...)
Die Verknüpfung Productline <-> Subscriber brauchst du ja nur um die Dokumente zu finden die er unterschreiben darf.
(Einfaches Select über die jetzt neue Route: "Group: Productline/Subscriber" -> "Documents")
Das ganze wäre ein Inner Join...

Select d.*
From   documents d

Inner   Join productline_subscriber ps
On      ps.productline = d.foreignkey_productline

Where ps.foreignkey_subscriber = 'PERSONALNUMMER_XY' -- Oder Name... Oder was da auch drinn steht :)

Also recht simpel...

 

[Säsch]

Nur mal so rein zum Verständnis:

Könnte man weil zwischen Subscribers (s) und Productline (pl) eine beziehung von s: pl=m:1 besteht auf die Tabelle Group: productline/Subscribers verzichten und einen Fremdschlüssel der Productlines in Subscribers platzieren? Eigentlich passiert dann das gleiche oder? ob ich jetzt in einer Group-Tabelle den Subscriber mit der Productline verbinde oder direkt in der Subscriber-Tabelle ist doch eignetlich egal oder?

Oder geht es dir um, wie soll ich sagen "die reinheit der entitäten", das also in subscribers wirklich nur personen-daten oder die personal_id zu finden ist?

Ich komme nämlich von "ER-Theorie" bei der man bei einer 1:m-Beziehung einfach einen Fremdschlüssel übergibt, statt einer dritten Tabelle zu definieren, um Speicher zu sparen.

 

[Distrilec]

Nein, mir geht es darum dass ein "Subscriber" eventuell auch mal zwei "Productlines" zugewiesen bekommen kann

Wie ich schon die ganze Zeit sage... Immer darauf achten dass das Modell 100% Skalierbar ist...
Besser haben und nicht brauchen, als brauchen und nicht haben... Oder wie hieß es noch?

 

[Säsch]

Hmmm, nicht schlecht danke

 

[Säsch]

Hi, ich bins wieder.

Die Eingrenzung der zum Unterschreiben autorisierten Personen kann noch weiter eingegrenzt werden.
Und zwar ist jedes Dokument einem Kunden zugeordnet und jeder Kunde hat einen eigenen Chief Engineer.
Der Chief Eng. kann sich pro Kunde um mehrere Dokumente kümmern. Wegen 100% Skalierbarkeit gehe ich davon aus das ein Chief Eng. auch mal mehrere Kunden haben kann.

Ich ordne meinen Subscribers also 2 Gruppen zu: Entweder der Subscriber ist ein Chief Eng, der dem Kunden zugeordnet werden kann; oder der Subscriber ist eine Person, die der Produktlinie zugeordnet werden kann und kein Chief Eng ist. Außedem möchte ich mein Personendaten aus der Personen-Datenbank-Ziehen und kennzeichne das mit einer Tabelle. In der Pesonen-Datenbank ist natürlich vermerkt wer Chief ist oder nicht.

Kann man die Datenbank wie in dem .PNG aufbauen?
Wie geht man vor wenn 2 Tabellen zum selben Schlüssel führen?

Wie funktioniert mit SQL eine Abfrage: "ist subscriber Chief Eng oder nicht?"

 

[Distrilec]

Du musst nicht immer künstliche Schlüssel erstellen.
Bsp:
In der Tabelle "Chief Eng/Customer" hast du einen künstlichen Schlüssel "ID_Customer+Chief Engineer"...
Allerdings kannst du auch einfach den PK über die beiden FKs legen. Das Ergebnis blebt das gleiche (Vllt. auf die Spaltenreihenfolge achten, wegen dem implizit erstellten Index... Jenachdem aus welcher "Richtung" du selektierst wird der Index nicht verwendet...)

 

[Säsch]

Der Datenbankaufbau aber rein von der Logik her passt aber oder?

Wenn ich 2 Tabellen habe die zum gleichen Schlüssel führen, wie bei Subscribers, kann ich z.b. OR in WHERE nutzen oder um beide Zweige abzudecken stimmts?

Viele Grüße und Danke

 

[Distrilec]

Ich bin mir nicht ganz sicher ob ich diese logische Einheit "Chief Engineer" überhaupt verwenden würde... Oder ob ich nicht einfach dem Kunden direkt einen Subscriber zuordnen würde... (Damit liesen sich einige Tabellen sparen...). Damit würde ich dann auch die Personaldatenbank-Referenz mit dem eigentlichen Subscriber kombinieren. (Sollte ja sowieso eine 1:1 Beziehung bestehen).

Mit meinen unglaublichen Paint-Künsten hab ich da mal dein Bild bearbeitet.

 

[Säsch]

sehr geil xD danke
Aber zum Thema 100% Skalierbarkeit bräuchte ich schon eine Gruppierung Customer/Subscriber oder? weil einem subscriber auch mal mehrer Kunden zugeordnet sein können?

 

[Distrilec]

@Säsch Dann erklär mir mal warum hier ein Subscriber nur einem Kunden zugeordnet sein kann...
Hättest du jetzt gesagt ein Kunde kann mehrere Subscriber haben... Ja, dann bräuchtest du eine weitere Tabelle