Eure Meinung - Taxonomy oder Entity Reference

am 07.10.2014 - 09:51 Uhr in
Hi,
ich überlege die ganze zeit, was die sinnvollste Umsetzung für eine Produktsuche ist.
Beispiel anhand von Mobile.de/Autoscout.de:
Ich habe die Felder Hersteller, Modell, Baujahr, etc.
Normalerweise würde ich das mit Taxonomie lösen, allerdings bin ich auf immer mehr threads gestoßen, wo es heißt, dass es besser wäre, mit entity reference zu arbeiten.
Mein Ansatz wäre dann:
1. Entity = Hersteller
2. Entity = Modell
3. Entity = Fahrzeug (hier dann die reference auf Hersteller und Modell und weitere Felder (Baujahr, km, etc).
Wenn in Zukunft dann auch noch weitere Features wie Händlerseiten, Bewertungen etc dazukommen, ist es ausschlaggebend, welche Lösung verwendet wird?
Ist es Überhaupt möglich, mit entity reference Hierarchien zu bauen? (Wenn zum Beispiel Hersteller Ford ausgewählt wird, dürfen natürlich auch nur Modelle von Ford angezeigt werden...
Tagging auch mit entity reference möglich?
Was meint ihr? Was ist der bessere Weg?
Ich freue mich auf Eure Antworten,
Viele Grüße
- Anmelden oder Registrieren um Kommentare zu schreiben
Letzlich ist die Taxonomy
am 07.10.2014 - 12:28 Uhr
Letztlich ist die Taxonomy auch nur eine Referenz auf einen Taxonomy-term, der wiederum ein Entity ist. Also hast Du mir Entity-Referenz den umfaßendsten Ansatz, der sich in jeder Richtung erweitern läßt. Views kann mit Referenzen umgehen (Vorwärts- und Rückwärts-Referenzen!). Du mußt dafür nur die entsprechenden Beziehungen aufsetzen.
wie gesagt, normalerweise
am 07.10.2014 - 12:38 Uhr
wie gesagt, normalerweise würde ich sowas auch mit taxonomie lösen, allerdings haben mich die threads (bsp: http://www.digett.com/blog/04/04/2012/rip-taxonomy-module-drupal-7) zum nachdenken gebracht...
Gibt es denn eine Möglichkeit, Hierarchical Select auf die Referenz zu legen?
Sprich, ich habe die beiden Entitäten "Hersteller" und "Modell". Wenn ich jetzt z.B. Ford auswähle, sollen nur Fordmodelle zur Auswahl stellen.
Ich habe das Modul : https://www.drupal.org/project/hser gefunden, allerdings DEV status. Allerdings steht hier: http://webwash.net/tutorials/using-simple-hierarchical-select-module-dru..., das es wohl auch mit simple hierarchical select funktioneren soll....
Mit Taxonomie würde ich simple h. s. nehmen,, allerdings kenne ich keine Möglichkeit / Modul, um es bei entity reference anzuwenden..
Mögliche Vorteile von
am 07.10.2014 - 13:25 Uhr
Mögliche Vorteile von Taxonomien:
Die Liste ließe sich wahrscheinlich (fast) beliebig verlängern.
Vermutlich lässt sich die o.g. Funktionalität auch irgendwie basierend auf Entity References abbilden. Hier ist dann aber mit einem deutlichem Mehraufwand zu rechnen, weil schlicht an einigen Stellen keine (fertigen) Module zur Verfügung stehen.
Hallo, Grundlegend pflichte
am 08.10.2014 - 10:30 Uhr
Hallo,
Grundlegend pflichte ich dem bisher gesagten bei.
Ich würde zunächst aber einen komplett abstrakten (objektorientierten) Ansatz sehen:
- Inhaltstyp = Objekt
- Feld im Inhaltstyp = konkrete Eigenschaft
- Taxonomie = abstrakte Eigenschaft
Damit wird deutlich, dass ein Eintrag in einer Taxonomie für sich allein betrachtet nichts aussagt, er erlangt Sinn, wenn er einem Objekt zugeschrieben wird.
Ein Objekt kann aber sinnvoll für sich alleine stehen.
Im obigen Beispiel ist ein "Modell" einfach eine "Nummer", eine Kategorie, das"Fahrzeug" aber ist ein Objekt, das mit der Modellbezeichnung genauer definiert wird.
Ein Hersteller ist so gesehen nur eine "Person" mit bestimmten Eigenschaften.
Anders gesagt: Gibt es in der realen Welt für etwas eine konkrete Entsprechung, ist das für mich ein Inhaltstyp. Wenn es aber nur eine abstrakte Eigenschaft ist, dann ist es eine Taxonomie (auch hierarchisch).
Relationen/References/Beziehungen finden also nur zwischen Inhaltstypen statt, so es in der realen Welt ebenfalls eine 1:1, 1:n, n:n Beziehung geben kann.
Manche Leute halten Objekte für konkrete Eigenschaften eines anderen Objekts:
Wenn man bei einem Inhaltstyp "Hersteller" die Adresse direkt als Felder definiert, dann ist das genaugenommen nicht ideal. Eine Adresse ist ein realer Ort, der mehreren Leuten zugeschrieben werden kann.
Damit sollte man einen Inhaltstyp "Adresse" machen und dann eine Reference vom Hersteller aus da drauf.
Man könnte auch annehmen, dass ein Hersteller nur eine spezialisierte Adresse ist, damit reicht ein Inhaltstyp "Adresse" und über eine Taxonomie die Eigenschaft "Hersteller"...
Mir ist klar, dass es Graubereiche gibt, wo die Unterscheidung nicht so einfach ist. Typisches Beispiel ist die Postleitzahl: Das ist eine eigentlich endliche Liste von Eigenschaften, die einem Ort zugeschrieben werden könnte, und damit ein Fall für die Taxonomie. Da man aber solche PLZ-Stämme kaufen kann, kann man das als eigenständig betrachten und ist damit ein Inhaltstyp, die Adresse referenziert da drauf.
Wie man nun genau die Inhaltstypen und Taxonomien aufbaut, hängt letztlich auch davon ab
- In welcher zeitlichen Reihenfolge im praktischen Betrieb die Daten erfasst werden
- Wozu man die Daten braucht
- Und ganz wichtig: wie man die Daten darstellen und auswerten will (!).
Der letzte Punkt zwingt einen, ein Projekt wirklich durchzuplanen, und nicht einfach drauflos zu definieren.Man sollte sich zuerst über das Ziel im klaren sein.
erst einmal Danke für die Guten und vielen Antworten..
am 08.10.2014 - 11:03 Uhr
Plan wäre folgender:
##Hersteller## (eigener Nodetype/Entität)
-BMW
--320 (##Modell## eigener Nodetype/Entität)
--520 (##Modell## eigener Nodetype/Entität)
-Mercedes
--c klasse (##Modell## eigener Nodetype/Entität)
--e klasse (##Modell## eigener Nodetype/Entität)
##Fahrzeug## (eigener Nodetype/Entität)
Reference - ##Modell##
Reference - ##Hersteller##
Baujahr (Textfeld oder Taxonomie?)
etc..
Zu der Aussage "Und ganz wichtig: wie man die Daten darstellen und auswerten will (!)."
Genau das ist der Grund, warum ich überhaupt überlege, ob ich es mit Taxonomie oder Entitäten lösen kann/werde.
Es soll hinterher eine Suche mit zig Filtern möglich sein (bsp. wieder Mobile.de). Dropdowns (Hersteller, Modell (daher auch die frage bzgl. Hierachien),
Baujahr von bis, Preise von bis, etc.
Daher suche ich nach der "Sinnvollsten" Lösung..
Vorteil wäre ja, wenn Hersteller und Modell jeweils eine eigene Entität wäre und ich dann ca. 500 Hersteller/Modelle angelegt habe, ich für jeden Eintrag eine eigene Seite hab/hätte.
Diese könnte man dann spezifisch aufbereiten (Informationen über diesen Hersteller/dieses Modell, Affiliate, etc.).
Mit Taxonomie könnte ich das natürlich ebenfalls, allerdings kann ich so jeder Entität weitere Felder hinzufügen,,
oder habe ich grade einen mega-Denkfehler?
Hmmm, es fängt ja schon damit
am 08.10.2014 - 12:42 Uhr
Hmmm, es fängt ja schon damit an, dass "BMW" in meinen Augen nicht wirklich ein Hersteller ist, sondern eine Marke oder eine Produktlinie.
Ich weiss, ich bin da spitzfindig, aber wenn man ein Datenmodell voll abstrahiert, kommen ganz viele Stufen dazu.
Will sagen, letzten Endes können wir Dir hier kaum die Datenstruktur vorschlagen - es kommt auf Deine persönliche Vorstellung an, auch auf die Inhalte, die Du da anbieten willst.
Am besten, Du machst Dir ein Testsystem mit simplen Inhaltstypen und Taxonomien und spielst damit alles bis und mit Views etc. durch, was damit möglich ist, und welche Zusatzmodule Du allenfalls
brauchst. Wenn Du dann die Werkzeuge beisammen hast, kannst Du Dich den Daten widmen:
1. Welche Daten müssen gepeichert werden
2. Wovon gibt es wieviele Ausprägungen
3. Welche Redundanzen müssen vermieden werden
Wenn Du pro Modell/Hersteller 1 Seite (View?) haben willst, dann brauchst Du wohl nur 1 Inhaltstyp Fahrzeug und 1 Taxonomie mit hierarchisch Hersteller->Modell, auf das das Fahrzeug dann zeigt.
Das wäre dann aber wohl ganz simpel...
nein, das verlange ich auch
am 09.10.2014 - 10:42 Uhr
nein, das verlange ich auch gar nicht, das wäre auch etwas "unfreundlich", wenn ich arbeiten auf andere abwälzen würde!
Ich denk ich werde es einfach mal so probieren,, dass ich 2 installationen vornehmen werde und einmal nur mit taxonomie und einmal mit entitäten arbeiten werde..
Werde das Ergebnis dann hier erneut beschreiben und auf Eure Meinung gespannt.
Vielen Dank erst einmal!!!!
Zitat: nein, das verlange ich
am 09.10.2014 - 11:04 Uhr
nein, das verlange ich auch gar nicht, das wäre auch etwas "unfreundlich", wenn ich arbeiten auf andere abwälzen würde!
Ui, so hab ichs nicht gemeint. Es gibt in Drupal halt so viele Möglichkeiten, ein Modell zu erstellen, dass das Resultat letzten Endes Geschmacksache ist.
Es gibt wahrscheinlich nicht DAS richtige Modell.
nein, so habe ich es auch
am 09.10.2014 - 11:57 Uhr
nein, so habe ich es auch nicht aufgefasst :o)
"Es gibt wahrscheinlich nicht DAS richtige Modell." Das ist ja eigentlich auch das schöne an Drupal!! ;o)
Was mich ursprünglich zu dieser Frage gebracht hat war ja der Grund, dass ich viele Threads gefunden hab, wo steht, dass taxonomie nicht mehr wirklch gebraucht wird und
das es in Drupal 8 evtl. gar keine Verwendung mehr findet..
Daher hab ich gedacht, ich frage mal die Runde hier, was sie dazu meint,, da ich ja auch gerne weiterhin "Zukunftssichere" Anwendungen/Seiten erstellen möchte und
bei einem upgrade von 7 auf 8 (ich weis, das wird noch dauern) könnte es ja dann eintreten, dass ich die komplette Struktur neu aufbauen müsste,, vorhandene Daten anpassen, etc,,
daher die Überlegung, die Taxonomie (welche ich bisher immer eingesetzt habe! ,o) ) mal aussen vor zu lassen....