Wie am besten Inhalte verknüpfen?

Ich vermute, daß Dir das Modul Field Collection weiter helfen müßte:
https://drupal.org/project/field_collection
http://webwash.net/tutorials/power-site-building-field-collection
http://www.youtube.com/watch?v=1V1ofpgUw-Y
Es ist allerdings noch im Beta-Stadium.

Ich würde also einen Inhaltstyp für Computer und einen für Software anlegen.
Auf Computer eine Collection anlegen mit einem Feld, welches eine Reference auf Software ist und einem Feld für den Pfad.
Diese Collection darf dann pro Computer beliebig oft angelegt werden.
Das Feld für die Wahl der Software würde ich per autocomplete machen, um halbwegs benutzerfreundlich auf die große Anzahl zugreifen zu können.

Falls es nicht reicht den Titel für eine eindeutige Auswahl im autocomplete zu sehen, kann man ein Minimodul mit einer eigenen Funktion schreiben, die mehr Daten der Software im Feld anzeigt.

Die Hardware müßte vermutlich ähnlich gehandelt werden.
Manche der verknüpften Inhalte können vermutlich als Taxonomie abgelegt werden für eine spätere Strukturierung in Kategorien.
Die spätere Auffindbarkeit der unzähligen Daten ist ja auch ein wichtiges Thema.

Bitte bedenke, daß ich das Field-Collection-Modul noch nicht selbst getestet habe.

Hallo,

Danke für den klasse Tipp, das sieht wie ein gangbarer Plan aus Ich werde es mal testen und schauen, wie weit dass dann mit Views, Suchen, Darstellungen etc. passt.

Ein Frage hätte ich noch zu den Referenzen. Empfiehlst Du eher das Modul "References" oder "Entity reference"?

Danke,
Der Glasperlenspieler

Ich kann dir https://drupal.org/project/entityreference empfehlen, sehr flexibel und in Verbindung eventuell für dich interessant für später:
https://drupal.org/project/entityreference_prepopulate
und
https://drupal.org/project/entityform

Entityform lässt sich mit Rules (gibt auch Entity Rules zusätzlich) sehr gut für die Erfassung von Formularen nutzen, auch um Bezüge herzustellen bei der Eingabe: wie Computer A zu Software B und C zuordnen usw.

Bei deinem Vorhaben kommt ja eine gewaltige Planung dazu, kann dir nur empfehlen erstmal die Module mit einem ganz simplen Testprojekt ( 2-3 Felder pro Type) anzulegen und erstmal alles durch zu testen, sicher kommen dir dann beim Aufbau neue Ideen der Umsetzung und dann ist es nervig, wenn man (wie ich auch anfangs....) schon zig Felder und Content Types etc. angelegt hat und alles wieder über den Haufen wirft, weil man eine viel bessere Vorgehensweise beim Einarbeiten entdeckt...

Grüße Jenna

edit: Die Info zu Field Collection habe ich wieder entfernt, sorry, hatte das Modul verwechselt, Field Collection nutze ich gar nicht.

Das Field Collection (FC)-Modul verfolgt einen interessanten Ansatz, aber leider ist es je nach Anwendungsbereich noch sehr problematisch. Insbesondere zusammen mit Revisionen ist das Modul buggy. Siehe z.B. folgende Issue: https://drupal.org/node/2000690
Das Füllen von FC Items per Rules funktioniert. Aber je nachdem an welchem Event man das versucht, kann das auch auch zu Fehlern führen. Vor allem, sollte man keine FC-Items per Rules ändern, in Events die am Speichern eines übergeordneten Nodes hängen.
Mit diesen Problemen habe ich letztes Jahr sehr viel Zeit verbracht.

Wenn sich also die gewünschte Datenstruktur auch per Entityreference herstellen lässt, dann würde ich das empfehlen.

Zuerst mal vielen Dank an alle. Das FC-Modul zusammen mit den Referenzen scheint eigentlich die Lösung des Problems zu sein, aber wenn das Modul problematisch ist.... Gibt es Alternativen?

Der Glasperlenspieler

-- Removed double posting --

Guck dir mal https://drupal.org/project/paragraphs an.

Ich bin damit grad am testen, du kannst nach der Installation unter admin/structure/paragraphs
neue Bundles anlegen und im Inhalt hinzufügen dir so dein Formular zurecht bauen, das sieht sehr spannend aus.

Unter dem eigentlichen Content Type legst du ein Paragraph Field als Bezug an zum Bundle.

Grüße Jenna

Es gibt so viele Methoden und Möglichkeiten, in Drupal eine Datenstruktur aufzubauen...
manchmal ist das Ausspucken von Daten aber anspruchsvoller, als das Erfassen!

Mich würde interessieren, was Du dann mit den Daten zu tun gedenkst, z.B. wie soll der
zukünftige Output aussehen, wer soll Zugriff auf welche Daten haben, wie soll allenfalls danach gesucht werden. Diese Überlegungen solltest Du dann bei Deinen Tests und Entscheidungen einbeziehen.

Also ich bin mir nicht ganz sicher ob ich es zu 100% verstanden habe, aber wenn ja dann wäre das eigentlich genau das was das Relation Modul macht. Im Gegensatz zum Entity Reference Modul erstellt das Relation Modul für jede Verknüpfung einen eigenen Entity. In diesem Entity sind eben die beiden zu referenzierenden Objekte angegeben. So und das beste daran ist das du bei dem Relation Entity selbst auch noch Felder erstellen kannst. Ein Video Tuturial Serie gibt es hier http://nodeone.se/sv/node/31.

Hallo zusammen,

zuerst noch vielen Dank an alle, die geholfen haben.
Hier also einige Details, wofür ich das Ganze brauche. Ich führe beruflich Audits durch, wobei es dann (extrem vereinfacht) darum geht, wer ein Dokument gehabt hat bzw. wer eine Software genutzt hat. Und ab einer gewissen Komplexität wird das echt unübersichtlich und einfache Tabellen reichen nicht. Ich kann die Informationen recht einfach in einer eigenen Datenbank ablegen (mache ich bei großen Untersuchungen) aber da leidet der Komfort erheblich. Meine Überlegung war jetzt, dass viele Anforderungen, die ich an ein vernünftiges System habe, eigentlich von einem CMS, also Drupal, abgedeckt werden (Berechtigungen, Workflows, Reports/Views, Logging, etc.) . Das einzige was mir noch fehlt, ist die Verknüpfung der Objekte.

Nehmen wir an, wir haben drei Content Types mit entsprechenden Feldern:

Computer

• Eindeutiger Name
• Standort

Software

• Eindeutige Kennung
• Besondere Merkmale

Dokument

• Eindeutige Kennung
• Datum

So, jetzt möchte ich folgende Informationshäppchen darstellen können:

1. Dokument XYZ wurde am 1.1.2000 auf Computer ABC benutzt
2. Programm RST liegt auf Computer ABC im Pfad /user/daten/temp
3. Programm QRS liegt auf Computer ABC im Pfad /user/daten/temp
4. Programm QRS liegt auf Computer KLM im Pfad /windows/system32

Wenn ich mir dann Computer ABC ansehe, will ich sehen, dass da ein Dokument und zwei Software dranhängt. Und wenn ich mir Programm QRS anzeigen lasse, will ich sehen, dass die auf den Rechnern ABC und KLM (in den entsprechenden Pfaden) liegt. Die Krönung wäre natürlich zu wissen, welche Dokumente an welchen Standorten (folgt aus den entsprechenden Computern) anzutreffen waren, bzw. wann ein Dokument wo war. Aber hier ein wenig mit PHP oder der DB selbst zu spielen macht dann auch nichts.

In Wirklichkeit rechne ich mit mindestens 10 bis 20 verschiedenen Content Types, wobei nicht jeder Content Type an jedem anderen hängen kann. Und da jede Untersuchung anders ist, muss dans Ganze erweiterbar bleiben. D.h. alles hart ind PHP zu kodieren wird keinen Spass machen.

Danke an alle, die sich hier Gedanken machen,
Der Glasperlenspieler

Nun, da fehlt Dir eigentlich nur ein weiterer Inhaltstyp "Informationshäppchen".
Alle anderen Inhaltstypen sind statisch, d.h. sind Stammdaten. Die Häppchen sind hier die einzigen Bewegungsdaten.
In diesem Inhaltstyp fügst Du für jeden möglichen Stammdatentyp ein Referenzfeld (ich verwende das Modul Entity Reference) ein, wenn mal was weiteres dazukommt, gibts halt dann ein weiteres Feld.
Dann kannst Du jedes "Häppchen" erfassen und referenzierst, was auch immer in dem Moment dazu bekannt ist.
Mit Views kannst Du das elegant in jede Richtung filtern.

Ja, so wie Leda würde ich das auch machen.
Bei den Stammdaten würde ich überlegen, welche davon später als Kategorien und evt. Unterkategorien für die strukturierte Darstellung der Daten verwendet werden sollen.
Diese würde ich als Taxonmie anlegen.