Wenn ich in meinem normalen Job sitze, dann arbeite ich sehr viel mit SQL-Datenbanken. Dazu haben wir ein sehr schönes Tool, den Toad von Quest, den ich auf fleißig jeden Tag nutze.
Also ich bin ganz ehrlich: Sowas hätte ich auch gerne für die Figuren-Datenbank.
Dort gib es u.a. auch einen Editor, in dem ich meine Suchabfrage (vielleicht auch über mehrere Tabellen?) erstellen kann, mit einem Ausgabefenster untendrunter, in dem meine Ergebnisse stehen.
Gibt es sowas schon? Oder muss ich dazu immer Reports basteln?
Wie bekäme ich zum Beispiel raus, wie viele Figuren bei mir eine bestimmte Eigenschaft besitzen? Stehe da bisschen auf dem Schlauch.
Als Beispiel “Wieviele Figuren sind Schweizer?” im SQL-Statement:
SELECT COUNT(*) FROM Figuren WHERE Land = ‘Schweiz’
Unterhalb meiner Abfrage steht dann eben die Antwort
Schön wäre natürlich auch noch das Verknüpfen von mehereren Tabellen inkl. LEFT JOIN, RIGHT JOIN …
Ähm - verlange ich zuviel? Oder wäre das leicht realisierbar? Oder gibt es das schon, nur ich find’s nicht?
Oder sehe ich den Wald vor lauter Bäumen nicht. Beispiele habe ich keine gefunden, nur die Referenzen, was die DB alles kann. Aber wie ich es einsetze - außer bei Reports - habe ich nicht finden können.
Gibt es vielleicht auch noch eine etwas umfangreichere Anleitung zur Figuren-Datenbank?
Wenn du die Tabelle Figuren offen hast, gibst du im Suchanfragefenster oben einfach ein:
Land =: Schweiz
Dann werden alle zutreffenden Datensätze angezeigt und die Summe ist in der Statuszeile abzulesen.
ja, richtig. Aber jetzt hätte ich die Leute gerne zusammengezählt. Wenn ich jetzt beispielsweise 35 Schweizer habe, wird es doch ein bisschen kompliziert, die alle am Bildschirm zu zählen. Das heißt jetzt nicht, dass ich 35 Schweizer habe, aber nur mal als Beispiel.
Ich habe in meinem Roman ein Fürstentum mit Adligen, einer Stadt und Bauernhöfen. Das Fürstentum steht im Krieg mit einem anderen Volk. Und ich habe im Fürstentum 3 Schauplätze (Adel, Stadt und Bauernhof) mit verschiedenen Protagonisten. Ich wollte halt gerne mal wissen, wie viele Leute, das jetzt in etwa namentlich sind, um manches mal abschätzen zu können. Beispielsweise will ich das Buch illustrieren und hätte dazu gerne die ganzen Familienwappen. Damit könnte ich dann herausfinden, wie viele Wappen ich etwa brauche / ich mir ausdenken muss.
Da jedes Kind sein Wappen aus dem Wappen des Vaters und dem Wappen der Mutter zusammensetzt (Geschwister habe dann gleiche Wappen), könnte ich dann mal zählen, wie viele Personen gleiche Teile in ihrem Wappen tragen (gleiches Elternteil) und so Scherze. Hätte ich halt mal gerne aufgedröselt. Da ich meine Stammbäume schon irgendwie in der DB drin habe (mit der Benennung von Vater und Mutter), müsste ich mir das dann eigentlich auch schnell mal ziehen können, was ich wirklich brauche.
Naja, das soll jetzt mal nur ein Beispiel für eine Anwendung sein.
Hab vielleicht verrückte Ideen, geb ich ja zu. Ich hab einfach Spaß in meiner Welt
Zählen brauchst du die nicht, die “35” würde dann unten im Fensterrahmen der Tabelle in der Statuszeile stehen.
Ich verstehe, was du meinst, allgemein gesehen. Und je mehr Informationen man in die DB hineingegeben hat, um so mehr möchte man - und kann man - im Prinzp auch herausholen. Nur mit dem “schnell mal” ist das oft so eine Sache.
In Base ist das Gute, dass für das “schnell mal” tatsächlich die Sucheingabezeile im Tabellenfenster zuständig ist, in der sich auch recht komplexe Abfragen relativ einfach formulieren lassen. Um nachzugucken, welche Möglichkeiten es da gibt, kann man die “erweiterte Suche” aufrufen (z.B. auf die Lupe klicken). Dort sind viele Möglichkeiten, wie man in einem oder mehreren Feldern mit verschiedenen logischen Verknüpfungen was explizit suchen kann, anklickbar. (Das entspräche dann dem SQL-Tool, von dem du sprachst.)
Und wie gesagt, für manches davon brauchst du das extra Suchfenster gar nicht zu öffnen. In der einen Suchzeile kannst du angeben, in welchem DB-Feld x du einen Namen y suchst (und/oder einen anderen) und/oder in welchem weiteren DB-Feld welche andere Angabe (und/oder eine andere) vorkommen oder auch nicht vorkommen soll.
Die logischen Verknüpfungen werden mit Operatoren wie and (auch weglassbar), or, ! (für Negation) und ggf. durch Klammerungen (und Anführungszeichen) dargestellt.
Ein konkretes Beispiel für deine Welt kann ich schlecht versuchen zu formulieren, weil ich nicht weiß, wie genau du z.B. die Verwandtschaftsbeziehungen, das biologische Geschlecht usw. in der DB untergebracht hast.
Was mir wohl manchmal fehlt bei der “Sucherei”, ist eine Art Protokollfunktion, das mir die Ergebnisse meiner Suchen in eine Datei schreibt.
Aber erstmal viel Spaß bei der Suche, ich hoffe, es gelingt dir zu finden, was du suchst. (Wenn etwas unklar ist, frage gern wieder nach.)
Ja, danke!
Die erweiterte Suche ist schon mal ganz gut. Und ich bekommen ja wirklich die Anzahl der Datensätze angezeigt. Das hilft mir schon mal viel. Bei Summen wird es dann wieder kniffliger, aber die brauche ich ja im Moment gar nicht. Und wenn mans nicht braucht, ist es ja auch nicht schlimm, wenns nicht geht
Ich meld mich auf jeden Fall wieder, wenn ich in der DB nicht mehr weiterkomm. Jetzt geht es erst mal wieder Dankeschön!
Hallo,
SQL Abfragen funktionieren doch nur auf SQL DB.
Hmmh ich habe mir mal vor einiger Zeit die Papyrus DB angeschaut und glaube, das es keine SQL DB mehr ist (früher m.W. SQLlite). Die Rohdaten sehen aus wie XML Statements. Im XML Editor auch formatierbar.
Ergo müßte da anders rangegangen werden. Vielleicht für die meisten Nutzer hier wird es dann zu technisch…
Nein, Papyrus-Base war schon immer XML. Als es zum ersten mal veröffentlicht wurde, gab es noch kein SQLite.
Die Rohdaten sind zwar in XML verpackt, aber nicht ganz sauber gekapselt. Das heißt, jede Tabellenzeile wird zwar in und eingefasst, aber darin sind die einzelnen Tabellenfelder sind lediglich durch ein Zeilenende getrennt. Dadurch lässt sich eine .pb-Datei nur begrenzt mit XML-Werkzeugen bearbeiten oder auswerten.
Ich hole mal den Thread hier aus dem Keller. Da gibt es nämlich eine Frage, die ich an euch bzgl. Relationen stellen möchte:
Angenommen ich mach mir eine Romane-Tabelle, eine Pseudonyme-Tabelle und eine Genres-Tabelle.
In der Genres-Tabelle habe ich zwei Spalten: Genre und Pseudonym. Hier hinterlege ich ein Genre und welches Pseudonym für dieses Genre schreibt.
Beispiel: High Fantasy - Alberta Aeon
Horror - Bernd Biest
Kinderbücher - Alberta Aeon
Mystery - Bernd Biest
Das Pseudonym ist eine Verknüpfung zu meiner Pseudonyme-Tabelle. Dort gibt es neben dem Namen beispielsweise noch eine entsprechende Autorenvita oder sonst irgendwas.
In meiner Romane-Tabelle habe ich im Feld Genre eine Verknüpfung zur Genres-Tabelle (und damit auch zum entsprechenden Pseudonym).
Angenommen, ich möchte jetzt für meine Romane einen Kurzabriss als Report ausgeben. "Roman X ist von Genre High Fantasy, geschrieben von Alberta Aeon. Hier ist die Kurzvita der Autorin: … "
**Gibt es eine Möglichkeit, im Roman-Report zu sagen: **
Für die Autorenvita gehe laut dem Feld Romane.Genre in den entsprechenden Datensatz der Genres-Tabelle und von dort aus weiter über Genres.Pseudonym zum Datensatz der Pseudonyme-Tabelle und füge die dort hinterlegte Autorenvita an die Stelle im Report.
(in SQL-Schreibweise wäre das: Select Pseudonym.Autorenvita from Romane, Genres, Pseudonyme where Romane.Genre = Genres.Genre and Genres.Pseudoym = Pseudonyme.Pseudonym).
DAS wäre richtig klasse! Dann würde ich mir nämlich (mit noch ein paar Tabellen mehr, z.B. Fragenkatalog, eventuell abhängig vom Genre) einen für meine Texte allgemeinen Betaleser-Fragebogen erstellen. Wenn ich einem Betaleser was schicken will, lass ich dann den Report über den entspechenden Romaneintrag laufen (wenn ich die Anzahl der Kapitel in der Romantabelle hinterlegt habe, könnte ich vielleicht sogar für jedes Kapitel einen gesonderten Fragenkatalog machen) und schicke ihn mitsamt meinem Romantext an mein"Opfer". Wenn ich mir auch noch ne Betaleser-Tabelle anlege, könnte ich vielleicht sogar noch in einem Rutsch alle Betaleser beglücken.
Okay, zugegeben, ich bin vielleicht ein bisschen gaga. Die paar Leser kann ich eigentlich ja auch so bedienen. Aber ich fänd das richtig schick (mir geht da das Herz auf, wenn es dann tatsächlich funktioniert). Würde das Ergebnis auch gerne teilen, wenn jemand so etwas haben wollen täte (und ich es hinbekomme).
Oder kommen Reports über eine Tabelle nicht hinaus?
Du kannst im Report alle Felder der aktuellen Tabelle nutzen als auch alle per Relation erreichbaren Felder aus weiteren Tabellen. Allerdings müssen die Relationen für die aktuelle Tabelle definiert sein, sodass man nicht so tief schachteln kann wie in SQL.
In deinem Fall sind Romane und Genres über die Relation »Genres« verknüpft und in der Genres-Tabelle ist wiederum das Pseudonym eingetragen. Damit kannst du im Report ein Datenfeld Genres->Pseudonym anlegen, um das Pseudonym auszugeben.
Für die Autorenvita kann man leider nicht Genres->Pseudonym->Autorenvita schreiben (schön wär’s @Ulli). Stattdessen müsstest du in der Genres-Tabelle ein weiteres Feld »Autorenvita« anlegen, welches dieselbe Relation benutzt wie schon das Pseudonym. Dadurch wird die Autorenvita in der Genres-Tabelle eingeblendet und sie wird im Romane-Report als Genres->Autorenvita verfügbar.
Mir fällt nur ein Umweg ein: Die Papyrus-Datenbank exportieren und in die gewünschte SQL-Datenbank importieren.
Sind ein paar Arbeitsschritte (+ Zusatztabellen), aber dann steht die SQL-Welt offen für alle COUNTS und JOINS.
Ja, da hast du schon recht. Aber mir gefällt ja gerade so gut, dass ich in Papyrus alles beieinander habe. Und da nutze ich die Papyrus-Base gerne mit. Wenn ich mir jetzt noch eine SQL-DB nebenher anlege, dann müsste ich ja 2x pflegen… Ansonsten stimmt’s schon, was du sagst.
Ich verstehe das, ein einheitliches Tool wäre ideal. Sonst müsste man entweder zwei Datenbanken parallel pflegen, oder bei jeder Änderung wieder exportieren und importieren. Und das zu automatisieren oder in einen einzigen Mausklick zu verpacken, könnte eine ziemlich heftige Tüftelei werden mit Macro Recorder, Batch-Datei und Chron-Jobs für Imports im SQL-Server aus fremden Datenquellen.
Beim Thema “Warum es wichtig ist, bei den eigenen Romanfiguren den Überblick zu behalten” fällt mir immer die Episode von King of Queens ein, in welcher der schrullige Arthur den Nachbarn Lou Ferrigno mit seinem selbstgeschriebenen Drehbuch terrorisiert: https://www.imdb.com/title/tt0620028/quotes/?tab=qt&ref_=tt_trv_qu
