Tutorial/Beispiel für Struct? Bzw. viele Grundlagenfragen zu Struct

da_user

2019-01-26, 20:03 #1

Member since Oct 2018 · 27 posts
Group memberships: Members

Show profile ·

Link to this post

Subject: Tutorial/Beispiel für Struct? Bzw. viele Grundlagenfragen zu Struct

Hallöchen,

ich versuche gerade in das Struct-PlugIn einzusteigen, und irgendwie finde ich den Einstieg vorne und hinten nicht. Auch die Doku auf der PlugIn-Homepage finde ich im Moment etwas schwierig. So verstehe ich auch den unterschied zwischen einer "Page Schema" und einer "Lookup Schema" nicht.
Wenn man googelt kommt man irgendwie nur auf die PlugIn-Homepage oder auf ein Tutorial für das data-PlugIn.

Ich versuche das was ich vorhabe an meinem aktuellen Projekt zu erklären, evtl. kann mir da schonmal jemand den einen oder anderen Tipp geben:
Ich habe hier einen ganzen Schwung sogenannter Lastmesssysteme (LMS), die in verschiedenen Antrieben verbaut sind, gerne mal kaputt gehen (durch)getauscht und repariert werden. Da fällt es manchmal schwer den Überblick zu behalten, insbesondere da zu jedem dieser LMS eine CAN-Bus-Karte gehört, die auch gerne kaputt geht, aber separat getauscht und repariert werden kann. Somit brauche ich eigentlich einen Überblick, welches LMS gerade in welchen Antrieb verbaut wurde, was mit dem schon passiert ist, welche CAN-Bus-Karte da drinnensteckt und was mit der schon passiert ist.

Prinzipielles Datenbank Schema stellt sich für mich damit relativ einfach vor, und ich hoffe ich kann das so einigermaßen verständlich abtippen:

Tabelle Lastmesssysteme
*ID|eingebaut in Antrieb|Verweis auf *ID_LMS-Events

Tabelle LMS-Events
*ID|Datum|Text

Tabelle LMS-CAN-Bus-Cards
*ID|Verweis auf *ID_LMS - eingebaut in|Verweis auf *ID_LMS-CAN-BUS-CARDS-Events

Tabelle LMS-CAN-BUS-CARDS-Events
*ID|Datum|Text
___________________________________________

Wenn ich das richtig verstanden habe, muss ich diese Tabellen als Lookup-Schema einstellen und habe da oben drüber ein Page-Schema welches die Daten dann quasi als "View" zusammenführt so dass ich diese auf einer Page anzeigen kann?

Ich habe jetzt auch schon versucht ein Lookup-Schema für die Tabelle Lastmesssysteme zu erstellen, scheitere dann aber total beim "Struct Schema Editor":
Was will er von mir dem Feld "Sort"? Feldname ist klar, und auch dass ich den mit label in mit was menschenleserlichen beschriften kann. Multi-Imput dürfte dann für ein Feld sein, dass mehre IDs aufnehmen kann, also damit für die Verweise auf LMS-Events. Aber was für einen Type gebe ich den einer ID?
Gut, durch probieren habe ich jetzt herausgefunden, dass ich ein neues Feld anlegen kann, indem ich das aktuelle speichere. Immerhin schon mal ein Fortschritt ;-)

VG
da_user

pop (Moderator) 2019-01-26, 21:11 #2

Member since Nov 2016 · 213 posts · Location: near Basel. Switzerland
Group memberships: Global Moderators, Members

Show profile ·

Link to this post

Hallo

Die volle Dokumentation zum Plugin ist hier: https://www.dokuwiki.org/plugin:struct

Du kannst zwei Arten von Tabellen anlegen:
- Beim Page-Schema ist zwangsläufig jede Zeile der Tabelle mit einer Seite im Wiki verbunden. Wenn Du die Seite löschst, verschwindet die zugehörende Zeile aus der Tabelle. Wenn Du eine neue Seite beginnst, erscheint eine Eingabemaske mit einem Feld für jede Spalte in der Tabelle. Die Angaben in der Zeile der Tabelle werden in der zugehörenden Seite des Wiki angezeigt. Ich denke, sie können dort auch geändert werden, aber das müsste ich nochmals nachsehen.

- Beim Lookup-Schema existieren die Zeilen der Tabelle unabhängig von jeder Wiki-Seite. Zur Eingabe von Werten und zur Ausgabe von Auszügen aus der Tabelle hinterlegst Du auf frei wählbaren Wiki-Seiten die entsprechenden Abfragen (Lookups).

Unabhängig davon, wie der Struct-Plugin funktioniert und wie Du dessen Fähigkeiten für Deine Anwendung verwendest, erlaube ich mir den Kommentar, dass Dein Datenbank-Schema noch nicht wirklich zu Ende gedacht ist. Zusätzlich ist meine private Meinung, dass für die Darstellung von Datenbeständen mit mehreren Beziehungen ein Wiki (insbesondere DokuWiki mit struct) nicht das optimale Tool ist.

da_user

2019-01-26, 23:31 #3

Member since Oct 2018 · 27 posts
Group memberships: Members

Show profile ·

Link to this post

Die volle Dokumentation zum Plugin ist hier: https://www.dokuwiki.org/plugin:struct

Die kenne ich, wie bereits erwähnt, wenn auch wohl nicht so verständlich, auch. Die erklärt sicherlich auch die ganzen Funktionen ganz gut und so, hilft mir aber ehrlich gesagt überhaupt nicht für die ersten Schritte.

Danke für die Erklärung der beiden Schema, ich glaube das habe ich verstanden.

Unabhängig davon, wie der Struct-Plugin funktioniert und wie Du dessen Fähigkeiten für Deine Anwendung verwendest, erlaube ich mir den Kommentar, dass Dein Datenbank-Schema noch nicht wirklich zu Ende gedacht ist.

Besser wäre natürlich noch, auch für die Antriebe eine Tabelle anzulegen. Ansonsten bin ich da natürlich für Verbesserungen offen, allzuviel habe ich noch nicht mit Datenbanken arbeiten müssen.

Zusätzlich ist meine private Meinung, dass für die Darstellung von Datenbeständen mit mehreren Beziehungen ein Wiki (insbesondere DokuWiki mit struct) nicht das optimale Tool ist.

Ganz deiner Meinung. Normalerweise würde ich hier auf MS Access oder LibreOffice Base setzen. Allerdings haben wir ersteres nicht in der "Firma" und Zweiteres bekomme ich kaum auf jeden Rechner installiert. Auf direkt mit SQL (struct basiert ja darauf) und PHP (kann ja der Apache der "DokuWikiOnAStick"-Version) habe ich dann echt so was von überhaupt keine Lust.
Längerfristig plane ich mir da ein .NET-Programm zu schreiben, dass dann aber viel mehr können soll.

cziehr 2019-01-27, 01:05 #4

Member since Jan 2011 · 634 posts · Location: 10119 Berlin
Group memberships: Members

Show profile ·

Link to this post

Ich habe mich auch mal mit dem struct-plugin versucht, aber bin ebenfalls da nicht so richtig durchgestiegen.

Auch wenn das data-plugin der Vorgänger des struct-plugins sein soll, so finde ich die Benutzung des data-plugins sehr viel einfacher, und es hat grundsätzlich den gleichen Anwendungsfall. Vielleicht wäre das ja auch für Dich was?

Viele Grüße,
Christoph

pop (Moderator) 2019-01-27, 10:21 #5

Member since Nov 2016 · 213 posts · Location: near Basel. Switzerland
Group memberships: Global Moderators, Members

Show profile ·

Link to this post

In reply to post #3

Quote by da_user:
...Ansonsten bin ich da natürlich für Verbesserungen offen, allzuviel habe ich noch nicht mit Datenbanken arbeiten müssen....

Einen richtigen Datenbankdesign kann ich aufgrund der vorliegenden Angaben nicht liefern, aber vielleicht helfen die nachstehenden Anregungen weiter:

Wir haben folgende Gegenstände oder Sachverhalte:
- Antrieb
- LMS
- Buskarte
- Event zu LMS
- Event zu Buskarte

Die Beziehungen zwischen diesen Elementen sind mir noch nicht ganz klar. In einer ersten Lesung würde ich diese wie folgt skizzieren:

Antrieb
←→ LMS: in jedem Antrieb ist kein oder ein LMS eingebaut; jedes LMS ist in keinem oder einem Antrieb eingebaut
←→ Buskarte: in jedem Antrieb ist keine oder eine Buskarte eingebaut; jede Buskarte ist in keinem oder einem Antrieb eingebaut.

LMS
←→ Antrieb (siehe oben bei Antrieb)
←↠ Event zu LMS: Zu jedem LMS kann kein, ein oder auch mehrere Events vorliegen; Jeder Event kann nur genau ein LMS betreffen

Buskarte
←→ Antrieb (siehe oben bei Antrieb)
←↠ Event zu Buskarte: Zu jeder Buskarte kann kein, ein oder auch mehrere Events vorliegen; jeder Event kann nur genau eine Buskarte betreffen

Unklar sind:
- Kann ich grundsätzlich jedes LMS mit jeder Buskarte kombinieren, oder kann eine Buskarte nur mit einem LMS verwendet werden?
- Kann ich grundsätzlich jedes LMS und jede Buskarte in jedem Antrieb einbauen?
- Muss ich rekonstruieren können, wann welches LMS oder welche Buskarte in welchem Antrieb verbaut war, oder reicht die Angabe, wo sie jetzt gerade sind?

Ebenso sollten zu diesem Zeitpunkt auch weitere Angaben bekannt sein, de zu den oben genannten Gegenständen oder Sachverhalten gespeichert werden sollen, also die Spalten der Tabellen.

Du fragst im ersten Beitrag nach den ID-Feldern. Um die Frage zu beantworten, solltest Du folgendes überlegen:
Wenn Du ein LMS auf der Werkbank liegen hast und eine handgeschriebene Liste aller Deiner LMS, woran erkennst Du, welcher Eintrag in der Liste zum LMS auf der Werkbank gehört? Dieselbe Frage ist natürlich für die Buskarten und die Antriebe zu beantworten. Als Laie würde ich annehmen, dass die Dinger Seriennummern haben.

da_user

2019-01-27, 12:14 #6

Member since Oct 2018 · 27 posts
Group memberships: Members

Show profile ·

Link to this post

Ziemlich gut zutreffend, allerdings:

←→ Buskarte: in jedem Antrieb ist keine oder eine Buskarte eingebaut; jede Buskarte ist in keinem oder einem Antrieb eingebaut.

Die Buskarte ist im LMS verbaut. Somit kann die Buskarte auch in einem LMS verbaut sein, welches nicht in einen Antrieb verbaut ist.

- Kann ich grundsätzlich jedes LMS mit jeder Buskarte kombinieren, oder kann eine Buskarte nur mit einem LMS verwendet werden?
- Kann ich grundsätzlich jedes LMS und jede Buskarte in jedem Antrieb einbauen?
- Muss ich rekonstruieren können, wann welches LMS oder welche Buskarte in welchem Antrieb verbaut war, oder reicht die Angabe, wo sie jetzt gerade sind?

- ja
- ja
- ja, dieses hätte ich allerdings über die Event abgefangen, da ich natürlich auch dokumentieren will, warum die jeweillen Elemente aus-/eingebaut wurden. Ich hätte es mir hier also zumindest für die ersten Schritte einfacher gemacht.

Du fragst im ersten Beitrag nach den ID-Feldern. Um die Frage zu beantworten, solltest Du folgendes überlegen:

Gerade schnell gegoogelt: mit ID war das gemeint, was SQL anscheinend unter "Primary Key" versteht, also eine ID die für jeden Eintrag eindeutig ist und somit die Zuordnung ermöglicht.
Für die Identifizierung auf der Werkbank würde ich mir noch ein Feld mit einer "Human-Readable-ID" hinzufügen und wahrscheinlich noch eines für die Seriennummer mit zig Stellen.

pop (Moderator) 2019-01-27, 13:03 #7

Member since Nov 2016 · 213 posts · Location: near Basel. Switzerland
Group memberships: Global Moderators, Members

Show profile ·

Link to this post

Quote by da_user:
Gerade schnell gegoogelt: mit ID war das gemeint, was SQL anscheinend unter "Primary Key" versteht, also eine ID die für jeden Eintrag eindeutig ist und somit die Zuordnung ermöglicht.
Für die Identifizierung auf der Werkbank würde ich mir noch ein Feld mit einer "Human-Readable-ID" hinzufügen und wahrscheinlich noch eines für die Seriennummer mit zig Stellen.

Das hast Du rückwärts dargestellt. Zuerst findest Du ein Merkmal, welches im richtigen Leben einen Gegenstand ein-eindeutig identifizieren kann. Die Human Readable ID ("HRI") wäre so etwas, wenn sie unzerstörbar mit der Baugruppe verbunden werden kann, also vielleicht mit einem unablösbaren Inventarkleber. Unter gewissen Bedingungen wäre auch die volle Seriennummer nicht schlecht, nämlich wenn sich diese schon in den ersten Stellen unterschieden.

Dieses Merkmal würde von Datenbankleuten als "Primär-Attribut" bezeichnet und wäre der beste Kandidat für ein Schlüsselfeld, welches dann in der relationalen Datenbank als "Primärschlüssel" definiert wird.

Unter den oben beschriebenen Voraussetzungen (mit Deiner Ergänzung betreffend die Kombination der Baugruppen) liesse sich ein Design wie folgt vorstellen:

Tabelle "Antrieb" mit Feldern: **AntriebId**, LMSId, KarteID, Marke, Typ, Kaufdatum, Kaufpreis, Farbe, Inbetriebnahme, Ausserbetriebsetzung (als Beispiele)
Tabelle "LMS" mit Feldern: **LMSId**, Marke, Kaufdatum, Kaufpreis, Inbetriebnahme,Ausserbetriebsetzung (als Beispiele)
Tabelle "Buskarte" mit Feldern: **KarteId** ,Marke, Kaufdatum, Kaufpreis, Inbetriebnahme, Ausserbetriebsetzung (als Beispiele)

Felder zwischen ** sind die ID-Felder der jeweiligen Tabelle.

Diese drei Tabellen definierst Du als Page-Schema. Die Felder LMSId und KarteID in der Tabelle Antrieb beziehen sich auf Seiten im WIKI. Somit "weiss" ein Antrieb immer, welches LMS und welche Buskarte dort installiert sind. Die Anordnung lässt sich auch umdrehen, so dass ein LMS immer weiss, in welchem Antrieb es verbaut ist und welche Karte es enthält. Du solltest dich aber entscheiden, ob diese Zuordnung bei Antrieb, LMS oder gar Buskarte dargestellt werden soll. Wenn sie in mehr als einer Tabelle festgehalten ist, werden sich die Einträge früher oder später widersprechen (eher früher).

Du brauchst dann drei Namensräume, je einen für Antriebe, LMS und Buskarten. Die Namen der Seiten für Antriebe, LMS und Karten sind die IDs dieser Gegenstände, also die HRI oder die Seriennummer. Jeder Antrieb, LMS und Karte muss dann eine eigene Seite in seinem Namensraum haben. Diese Seite kann dann jeweils als einfache Wiki-Tabelle oder gar als Unordered List die Events darstellen, sofern die Events nicht nach irgendwelchen Attributen durchsucht werden müssen.

Haar in der Suppe: die Seite eines Antriebs, LMS oder Karte kann nicht leer sein, da sie sonst vom Wiki gelöscht wird und damit auch der Eintrag in der Datenbank.

Weiteres Haar in der Suppe: wenn bei einem LMS oder einer Karte gleich sichtbar sein soll, wo es verbaut ist, muss jede Seite eine Abfrage (ein Lookup) enthalten. Das lässt sich m.W. nicht automatisieren. Es lässt sich aber vereinfachen, indem die Abfrage auf einer Seite ausserhalb der Namensräume einmal hinterlegt und mit "include" auf jeder Seite einer Baugruppe eingefügt wird. Damit kann die Abfrage später einfach angepasst werden.

Fragen?

da_user

2019-01-27, 13:37 #8

Member since Oct 2018 · 27 posts
Group memberships: Members

Show profile ·

Link to this post

Fragen?

Im Moment überwiegt "klar wie Kloßbrühe". Sind dir Erdäpfel- oder Semmelknedl lieber? ;-)

Sind jetzt erstmal sehr viele Infos. Ich werde mir da wohl mal ein "Playgroundwiki" anlegen müssen, mit dem ich da rumexperimentieren kann. Dann werden u.U. schon Fragen auftauchen.

Danke erstmal!

Edit: eine Frage hätte ich da noch:
Die Namensräume, sind das Namensräume innerhalb des DokuWikis oder Namensräume innerhalb des Structs?

pop (Moderator) 2019-01-27, 16:54 #9

Member since Nov 2016 · 213 posts · Location: near Basel. Switzerland
Group memberships: Global Moderators, Members

Show profile ·

Link to this post

Quote by da_user:
Die Namensräume, sind das Namensräume innerhalb des DokuWikis oder Namensräume innerhalb des Structs?

Namensräume betreffen zunächst die Textseiten des Wiki und daraus abgeleitet die Mediendateien (die Bilder). In der Verzeichnisstruktur des Wiki entsprechen Namensräume den Unterverzeichnissen.

Bei einem Page-Schema in struct definierst Du, welche Seiten mit den Daten in einer Tabelle verbunden werden sollen. Für diesen Fall ist die Verwendung verschiedener Namensräume für verschiedene Tabellen die offensichtliche Lösung. Man kann sich aber auch bestimmte Regeln ausdenken, wie die einzelnen Seiten benannt werden sollen. Das scheint mir aber der umständlichere Weg zu sein.

Juergen_aus_Zuendorf 2019-01-28, 08:33 #10

Member since Apr 2012 · 226 posts
Group memberships: Members

Show profile ·

Link to this post

In reply to post #4

Quote by cziehr on 2019-01-27, 01:05:
Ich habe mich auch mal mit dem struct-plugin versucht, aber bin ebenfalls da nicht so richtig durchgestiegen.

Auch wenn das data-plugin der Vorgänger des struct-plugins sein soll, so finde ich die Benutzung des data-plugins sehr viel einfacher, und es hat grundsätzlich den gleichen Anwendungsfall. Vielleicht wäre das ja auch für Dich was?

Viele Grüße,
Christoph

Ihr solltet unbedingt das neue Struct-Plugin nutzen, das hat viele Vorteile gegenüber dem Data-Plugin! Habe auch ewig gebraucht, bis ich das ganze so halbwegs verstanden habe. Aber es lohnt sich!

da_user

2019-01-28, 12:50 #11

Member since Oct 2018 · 27 posts
Group memberships: Members

Show profile ·

Link to this post

Also tatsächlich hänge ich jetzt etwas.

Folgende Tabellen sind als Page-Schemas angelegt:

Struct Schema Editor
   Page Schema:
      antriebe
      lastmesssysteme
      lms_can

Dann folgende Namensräume und die Hauptseiten dazu:

*[[struct:antriebe]]
*[[struct:lastmessysteme:lms]]
*[[struct:lastmesssysteme:cancards]]

Auf der Seite struct:antriebe habe ich jetzt mal mit dem Bureaucracy-PlugIn ein Eingabefeld angelegt:

====== Antriebe ======
<form>
Action template templates:antriebe Antrieb :
struct_schema "antriebe" !
submit "Erstelle neuen Antrieb"
</form>

Wenn ich das jetzt ausfülle, und auf "Erstelle neuen Antrieb" klicke, erhalte ich folgende Fehlermeldung:

Could not read template "templates:antriebe". Maybe it doesn't exist or you have no read permissions?

Was läuft da schief?

pop (Moderator) 2019-01-28, 13:03 #12

Member since Nov 2016 · 213 posts · Location: near Basel. Switzerland
Group memberships: Global Moderators, Members

Show profile ·

Link to this post

Ich kenne mich mit dem Bureaucracy-Plugin überhaupt nicht aus, aber Du hast ein "Template" (offenbar eine Vorlage) aufgerufen: template templates:antriebe

Hast Du so eine Vorlage irgendwo hinterlegt? - Das Plugin sagt, dass es sie nicht finden oder nicht darauf zugreifen kann.

da_user

2019-01-28, 13:16 #13

Member since Oct 2018 · 27 posts
Group memberships: Members

Show profile ·

Link to this post

Ähm, nein. Ich bin da jetzt ziemlich doof nach der Struct-Doku vorgegangen: https://www.dokuwiki.org/plugin:struct:bureaucracy

Wie schreibst du Dateien in das Struct und zeigst diese an?

This post was edited on 2019-01-28, 13:24 by da_user.

pop (Moderator) 2019-01-28, 14:44 #14

Member since Nov 2016 · 213 posts · Location: near Basel. Switzerland
Group memberships: Global Moderators, Members

Show profile ·

Link to this post

Für ein Schema, das mit Seiten verbunden ist, füge ich dem Wiki neue Seiten zu; dabei zeigt Dokuwiki eine Eingabemaske an, die ich ausfülle. Für ein Schema ohne Bezug auf Seiten formuliere ich auf einer eigenen Seite ein "Lookup" (eine Abfrage). Das zeigt eine Tabelle an, in welcher ich die Daten eingeben und bearbeiten kann.

Allerdings verwende ich meine Wikis auch hauptsächlich für Textseiten, die mit wenig Daten angereichert sind. Ich habe bisher mit Dokuwiki noch kein Projekt begonnen, das die Kernfunktionen einer Datenbank benötigt. Ich glaube nicht, dass sich dieses Werkzeug für solche Zwecke besonders gut eignet. Kommt dazu, dass die wenigen Funktionen, die sich mit Daten befassen, nur von mir allein verwendet werden. Das Publikum kann die Lookups und Datenfelder nur sehen.

In der Zwischenzeit habe ich die Doku zum Bürokratie-Wiki durchgelesen. Der Mechanismus der Templates wird dort als mächtig aber ziemlich komplex beschrieben. In meinem Weltbild ist das nichts für Leute, die erst vor dem Erlernen des Struct-Plugins stehen. Das ist meine persönliche Empfehlung.

da_user

2019-01-28, 15:16 #15

Member since Oct 2018 · 27 posts
Group memberships: Members

Show profile ·

Link to this post

In der Zwischenzeit habe ich die Doku zum Bürokratie-Wiki durchgelesen. Der Mechanismus der Templates wird dort als mächtig aber ziemlich komplex beschrieben. In meinem Weltbild ist das nichts für Leute, die erst vor dem Erlernen des Struct-Plugins stehen. Das ist meine persönliche Empfehlung.

Alles klar. Ich hätte gedacht, man bräuchte quasi beides. Dann erstmal ganz klar struct!

Für ein Schema, das mit Seiten verbunden ist, füge ich dem Wiki neue Seiten zu; dabei zeigt Dokuwiki eine Eingabemaske an, die ich ausfülle.

Wenn ich das richtig verstehe, muss ich dafür dann ein "Schema Assignments" erstellen. Das hätte ich jetzt gemacht für das Schema "antriebe":

Page/Namespace Schema
struct:antriebe antriebe

Und dann auf die Seite "struct:antriebe" einfach ein

[[struct:antriebe:foo]]

? Da bekomme ich keine Eingabemaske, sondern nur das "Dieses Thema existiert noch nicht".

Global DokuWiki Links