2009-08-08 10 views
2

Ich muss eine Anwendung entwickeln, wo es 4 Arten von Benutzereinheiten (Administratoren, Partner, Firmen und Kunden) gibt, jeder Benutzertyp hat seine eigene Reihe von Details und sie sollten alle in der Lage sein um allgemeine Operationen wie Senden von Nachrichten, Zahlungen usw. auszuführen. Diese Operationen sollten in einer einzigen Tabelle gespeichert werden, sie müssen jedoch trotz ihres Typs auf den genauen Benutzer verweisen.DB-Design für mehrere Arten von Entitäten

Welches Datenbankdesign wäre besser geeignet?

+0

hat jeder Typ von Benutzerentity eigene Felder? (dh hat ein Partner, aber kein Benutzer, eine Sternbewertung?) –

+0

"jeder Benutzertyp hat seinen eigenen Satz von Details" - ja, es gibt mehrere verschiedene Felder für jeden Benutzertyp. –

+0

mögliches Duplikat von [MySQL Question - Wie man mit mehreren Benutzertypen umgeht - eine Tabelle oder mehrere?] (Http://stackoverflow.com/q/1054068/90527) – outis

Antwort

2

"Ich möchte nur noch eine Sache hinzufügen, Sie schlagen vor, ich habe eine Tabelle für jeden Benutzertyp ... Ich bevorzuge diesen Ansatz aber wie würde ich ein Schema entwerfen, wo ich diese Benutzer-ID 7 (admin) sagen kann eine Nachricht an die Benutzer-ID 537 (Client) gesendet? Oder dass eine Zahlung von der Benutzer-ID 70 (Firma) empfangen wurde? "

Es gibt nichts, was Sie daran hindern könnte. Habe eine Tabelle {Absender-Empfänger-Nachricht (-id)} mit Primärschlüssel alle drei Attribute und zwei FK {Absender} und {Empfänger}. Die FK beziehen sich auf den Primärschlüssel der Tabelle, der die COMMON-Attribute aller Benutzer enthält.

Nun könnte Ihre nächste Frage sein, "aber ich will eine Regel zu sagen, dass kein Benutzer des Typs X direkt eine Nachricht an einen Benutzer des Typs Y senden kann".

Das ist der Punkt, an dem jeder aktuelle (relationale) DBMS seine Schwächen zeigt. Selbst Oracle oder DB2 kann das nicht deklarativ tun. Es gibt einfach zu viel, um über dieses Thema zu sagen, um in diese Antwort zu passen.

BTW Sie schienen sich trotz aller Downvotes für meine Antwort interessiert zu haben. Schätze das wirklich.

+0

Wenn Sie wirklich eine solche Regel in der Datenbank erzwingen wollten, könnten Sie die Tabelle SENDER_RECIPIENTS denormalisieren, um SENDER_TYPE und RECIPIENT_TYPE einzuschließen. Es scheint mir, dass diese Regel eine Geschäftsregel ist, die sowieso nicht in der Datenbank durchgesetzt werden sollte. Schließlich könnte die Regel lauten: "Wenn wir uns in der stillen Phase befinden, kann kein Benutzer vom Typ X Nachrichten an Benutzer vom Typ Y oder Z senden, aber ansonsten ist es in Ordnung". Das wäre sehr unordentlich, um durch deklarative Einschränkungen zu erzwingen. Deshalb gab uns die Natur Rule Engines. – APC

+0

Danke, das ist nicht der Fall, aber diese Frage machte mir klar, wie wichtig es ist, fundierte Kenntnisse über die Funktionsweise von FKs zu haben. Sie scheinen sehr gut informiert zu sein und Ihre Lösung scheint der richtige Weg zu sein, danke. –

-2
user 
================ 
id 
user_type_id 
name 
etc 

user_type 
================ 
id 
name (admin, partner...) 
etc 

user_detail 
================ 
id 
user_id 
user_detail_type_id 
value 

user_detail_type 
================ 
id 
name 

user_type_to_user_detail_type 
================ 
id 
user_type_id 
user_detail_type_id 
(maps which user types have which detail types) 
+1

-1: Entschuldigung, aber dieses Design kann nicht empfohlen werden. –

5

Ich würde sagen, das ist ein perfekter Fall für inheritance. Fügen Sie die allgemeinen Attribute in eine Tabelle ein und erben Sie, um benutzerdefinierte Attribute für Ihre verschiedenen Benutzertypen hinzuzufügen.

Chaos Antwort scheint mir ein bisschen chaotisch, obwohl es nützlich wäre, wenn Sie nicht im Voraus wissen, welche Eigenschaften Sie speichern müssen.

+0

Wie kann dies an MySQL angepasst werden? –

+2

http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server gibt ein Beispiel, wie dies ohne Unterstützung in der db implementiert werden kann. –

+0

+1, Danke, ich werde es untersuchen! –

2

Werfen Sie einen Blick auf die drei Möglichkeiten, dass in den Patterns of Enterprise Application Architecture zu tun:

http://martinfowler.com/eaaCatalog/singleTableInheritance.html

http://martinfowler.com/eaaCatalog/classTableInheritance.html

http://martinfowler.com/eaaCatalog/concreteTableInheritance.html

Die Wahl, wie viele hängt Eigenschaften, die die 4 Arten von Benutzereinheiten teilen, und auch die Anwendungsfälle, die Ihr System benötigt.

+0

Die Betontischvererbung scheint für mich die richtige zu sein, aber mein Problem bleibt bestehen, wie kann ich jeden Datensatz in jeder Tabelle global verfügbare, nicht wiederholte Benutzer-ID zuordnen? Zum Beispiel, wie würde ich das Schema so gestalten, dass ein Fußballer eine Nachricht an einen Bowler senden kann? Oder um Zahlungen zu erhalten, sollte ich für jeden Benutzertyp eine Tabellenzahlung haben? Wie kann ich einen payments_players anstelle von payments_footballers, payments_bowlers und payments_cricketers haben? –

+0

Wenn Sie GUIDs oder eine Sequenz verwenden (die 4 Entitäten haben alle unterschiedliche und eindeutige IDs), dann ist es möglich. Andernfalls könnte Ihr Messaging-System generischer sein (und unabhängig von der Vererbungs-Mapping-Strategie). Sie benötigen also eine Nachrichtentabelle mit der ID from_id, from_class, to_id, to_class, message. – cherouvim

Verwandte Themen