Idee für Tabellenstruktur mit Nullwerten

Question

Hallo zusammen,

ich brauche mal einen Rat bei der Strukturierung meiner Datenbank.

Ich möchte, ähnlich wie es bei den Immobilienplattformen ist, dem Anwender die Möglichkeit für z.B. die folgenden Eigenschaften Werte zu hinterlegen:

- KaltmieteMin und KaltmieteMax

- WarmmieteMin und WarmmieteMax

Beide Datenfelder sind vom Typ Decimal?. Dadurch KANN der Benutzer, muss aber keine Werte angeben. Die Strukturfrage die sich mir jetzt stellt ist, packe ich alle solcher Eigenschaften in eine Tabelle und erweitere diese immer wenn sich eine neue Eigenschaft findet z.B. BaujahrMin und BaujahrMax, oder gliedere ich das in einer Separate Tabelle aus und speicher nur die Werte ab, die der Benutzer eingetragen hat?

Variante 2 ist natürlich sehr Erweiterungsfreundlich wenn neue Eigenschaften dazu kommen. Aber ich stelle mir die Suche sehr schwer vor, wenn man diese eingrenzen möchte, da nicht jedes Profil alle Eigenschaften verknüpft hat. 

Was die Suche angeht, halte ich die Variante 1 für gangbarer, weil dort explizit in der jeweiligen Eigenschaft gesucht werden kann (z.B. KaltmieteMin == null OR >= 300).

Was meint ihr?

Vielen Dank!

Answer 1

Hallo David,

ich würde eindeutig zu Variante 2 tendieren, und für die Suche ein View erstellen. Die View sieht dann aus wie die Tabelle aus Variante1.

Grüße

Roland

Answer 2

Dem kann ich auch nur zustimmen.
Durch die Eigenschaft-Tabelle ist diese jederzeit um beliebige Inhalte eweiterbar.
Man verringert ins besonders die Redundanz.
Was die Suche angeht so sollte man dann keine View erstellen, da diese mit jeder neuen Eigenschaft dann wieder geändert werden muss.
Man kann aber die Tabelle 2 nach beliebigen Kriterien durchsuchen und erhält dann redundant die Profil-ID's, die man dann aber per "distinct" wieder eindampfen kann.

Zur Eigenschafts-Tabelle sei noch gesagt, dass ggf. Min/Max/Fix jeweils als numerisch oder String vorhanden sein sollten um SQL-technisch eben mit "between" und auch "like" suchen zu können:

select distinct profilid from properties
where propid = 1 and max <= 300
or propid = 2 and min >= 10 and max <= 100

usw.

Das Ergebnis der ProfilId's kann dann mit der Props-Tabelle verknüpft werden um alle verfügbaren Eingeschaften dann auszugeben.

Für die Propid's selber würde ich eine 3. Tabelle "Id, Text" anlegen, so dass in der Proerties nur ProfilId, PropId und Min/Max/Fix gespeichert werden müssen.

Answer 3

Was die Suche angeht so sollte man dann keine View erstellen, da diese mit jeder neuen Eigenschaft dann wieder geändert werden muss.

.

Bei einer normalen View ist das so, für solche Konstrukte wie oben verwendetet man Kreuztabellen-Abfragen. Die kann man sogar auf einem SQL-Server über Stored Procedures dynamisch erstellen.

Grüße

Roland

Answer 4

Hallo zusammen,

danke für die Antworten! Die zweite Variante ist auch meine aktuell umgesetzte. Das mit der Kreuztabelle war ein guter Anstoß! Die Möglichkeit hatte ich bisher nicht auf dem Schirm gehabt.

Hast du nähere Informationen wie man sowas mit EF Code First umsetzten kann?

So eine Kreuztabelle wäre sicherlich auch als Stored Procedure eine bessere Lösung als die Kreuztabelle onthefly zu generieren.

Wie ich das nun mit EF CodeFirst umsetze weiß ich im Moment noch nicht :-(

Answer 5

Hier mal ein Link ->Dynamische Kreuztabelle mit dem MS-SQL-Server

Grüße

Roland