Abfrage (Filter) bei einer n:m Relation

[Sharky]

Hai ihr,

irgendwie habe ich eine Blockade :oops:

Ich erstelle eben ein Programm für Immobilienmakler. Mit diesem möchten sie ihre Immobilien verwalten (überraschung).
Von den Anwendern kann eine Liste mit "Eigenschaften" erstellt werden.
z.B.:

• ETW
• EFH
• MFH
• Balkon

Bei jeder Immobilie kann nun (mit Checkboxen) angegeben werden welche der Eigenschaften auf diese zutrifft. So weit ja kein Problem. Ich benutze dafür einfach drei Tabellen.

Code:

TB_Immo
ID : Integer (PK)
name : string

TB_Eigenschaf
ID : Integer (PK)
name : string

TB_Immo_Eigenschaft
Immo_ID : FK -> TB_Immo.ID
Eigenschaft_ID : FD -> TB_Eingeschaft.ID

Aber wie suche ich jetzt z.B alle Immobilien heraus bei dennen ETW = True und Balkon = True ist?

Irgendwie sehe ich den Wald vor lauter Bäumen mal wieder nicht :wall:

Oder sollte ich das ganze mit einem anderen Ansatz lösen?

[marabu]

Hi Sharky,

von der E/R-Modellierung her sollte da eine Gen-Spec-Beziehung rauskommen. ETW und MFH sind keine Eigenschaften, wie z.B. Balkon, sondern Spezialisierungen von Immobolie. Die allgemeinen Eigenschaften sehe ich als direkte Attribute, aber du willst dem Kunden durch deine Eigenschaftstabelle sicher eine Erweiterung der Attributmenge ermöglichen. Das dadurch variable Statement musst du dann zur Laufzeit erzeugen:

SQL-Code:

SELECT * FROM tb_immo 
WHERE EXISTS (SELECT * FROM tb_immo_eigenschaft WHERE immo_id = id AND eigenschaft_id = :prop1)
AND EXISTS (SELECT * FROM tb_immo_eigenschaft WHERE immo_id = id AND eigenschaft_id = :prop2)
/* AND EXISTS (SELECT * FROM tb_immo_eigenschaft WHERE immo_id = id AND eigenschaft_id = :prop3) */
...

Grüße vom marabu

[Sharky]

Hai marabu,

Zitat:

Zitat von marabu

...ETW und MFH sind keine Eigenschaften, wie z.B. Balkon, sondern Spezialisierungen von Immobolie.

Du weisst das, ich weiss das ... aber versuche das mal jemandem klar zu machen der dies bis jetzt mit den "Kategorien" von Outlook gemacht hat :shock:

Ich versuche schon seit Tagen den Kunden zu überzeugen das es eigentlich so ist das es

• Spezialisierungen gibt (welche sich gegenseitig ausschliessen)
• Eingeschaften die zusätzlich vorhanden sind

Aber das nur am Rande.

Zitat:

.. sicher eine Erweiterung der Attributmenge ermöglichen.

Jup. So soll es sein.

Zitat:

Das dadurch variable Statement musst du dann zur Laufzeit erzeugen:

Mist, ich habe es befürchtet

Ich könnte jetzt natürlich anstelle der n:m-Tabelle (TB_Immo_Eigenschaft) die "Eigenschaften" in einem Feld der Immobilien speichern. Aber irgendwie geht mir das gegen den Strich.

[Jelly]

Alternativ könntest du eine bitweise Verknüpfung deiner Attribute setzen. Da es sich ja nur um Checkboxen handelt, gibt es dazu nur 2 Zustände, gesetzt oder nicht gesetzt, rsp. 1 oder 0.

Wenn du als Spaltentyp "int" wählst, so sind dies immerhin 4 byte, also 32 bit. Damit kannst du also 32 Zustände in einem Wert speichern. Zum bequemen Suchen nachher in der DB kannst du dir noch eine schön Funktion im MSSQL schreiben, und die Sache ist geritzt. Und du bleibst, bis zu einem gewissen Grade, flexibel, wenn es darum geht, weitere Attribute aufzunehmen.

[Sharky]

Hai Jelly,

das wäre eine Überlegung wert. Ich könnte ja in der Tabelle 4 Integer-Felder für diesen Zweck bereitstellen. Damit wäre halt die Anzahl der "Attribute" auf 128 beschränkt. Aber damit kann der Kunde bestimmt leben.
Der Vorteil wäre auch das ich unabhängiger von einem bestimmten DB-System bin. In diesem Fall muss es "nur noch" Bitoperationen in der WHRE-Abfrage können.

[Jelly]

Statt Integer, kannst du ja auch ein varchar nehmen, von beliebiger Länge. Da hast du dann noch mehr Möglichkeiten wie 4x32

[Jelly]

Zitat:

Zitat von Sharky

In diesem Fall muss es "nur noch" Bitoperationen in der WHRE-Abfrage können.

Noch ein Nachtrag...

Die Bitoperationen kannst du ja in einer UDF selbst erledigen.

[ibp]

Zitat:

Zitat von Sharky

...Ich versuche schon seit Tagen den Kunden zu überzeugen das es eigentlich so ist das es

• Spezialisierungen gibt (welche sich gegenseitig ausschliessen)
• Eingeschaften die zusätzlich vorhanden sind

Aber das nur am Rande.

nur mal so nebenbei wegen dem gegenseitigem Ausschluss, eine ETW ist eine Untermenege eines MFH, daher können diese "Eigenschaften" sich nicht ausschliessen!

[marabu]

Zitat:

Zitat von jelly

Da es sich ja nur um Checkboxen handelt, gibt es dazu nur 2 Zustände, gesetzt oder nicht gesetzt, rsp. 1 oder 0.

Ein Bitvektor ist eine feine Sache, aber "Bäder=2" wäre eine geläufige Ausnahme von der Regel und ich bin nicht sicher, ob ich ohne Not mehrere Lösungsansätze im gleichen Programm mischen würde.

Zitat:

Zitat von ibp

eine ETW ist eine Untermenge eines MFH

Vorsicht - das gilt nicht in diesem Kontext. Es geht hier um Immobilienobjekte. Die ETW kann ein Objekt im Portfolio des Maklers sein, das enthaltende MFH steht da noch nicht zur Debatte.

marabu

[Sharky]

Zitat:

Zitat von marabu

... Ein Bitvektor ist eine feine Sache, aber "Bäder=2" wäre eine geläufige Ausnahme von der Regel und ich bin nicht sicher, ob ich ohne Not mehrere Lösungsansätze im gleichen Programm mischen würde....

In diesem Fall ist das mit der "Anzahl" nicht wichtig. Diese Information ist fest bei der Immobilie hinterlegt. Dafür gibt es feste Felder in der Tabelle (genauso wie: Balkon, Fläche, usw).

Es geht nur um die "Eigenschaften" einer Immobilie die nicht Standardmässig vorhanden sind und darum vom Anwender selber angelegt werden können. 80% bis 90% aller Informationen sind ja vorgegeben.

Darum denke ich das ich mit diesem "Bitvektor" *g* arbeiten kann.


BTW: Wie marabu richtig erkannte ist eine Immobilie entweder eine ETW oder ein MFH. Das die ETW in einem MFH sein kann ist in diesem Fall nicht entscheidend ;-)