base: n-m-Relationen oder Untertabellen

Papyrus Vorschläge & Feedback
1

Ist es möglich, mit Papyrus-BASE Tabellen mit n-m-Beziehungen oder Untertabellen aufzubauen? Mit der Lösung, wie sie im mitgelieferten “Faktura” angeboten wird, bin ich nicht wirklich glücklich, da sie sehr aufwändig in der Realisierung ist.

Anstelle im Rechungsdatensatz 10 fixe Datensätze für die verrechneten Produkte einzubauen und bei Berechnungen viele Felder ansprechen zu müssen, möchte ich diese lieber in einer separaten Tabelle bzw. Untertabelle verwalten. Innerhalb des Rechungsdatensatzes sollen dann jeweils so viele Produkte (beliebig viele) eingefügt werden, wie gerade benötigt werden.

Dadurch werden einerseites die Anzahl Positionen nicht im voraus limitiert. Zudem können Berechnungen eleganter formuliert werden. z.B: Summe der Einzelpreise über alle Positionen.

Für meine Zwecke müsste es nicht eine komplette n-m-Relationen Umsetzung sein, wie sie beim Datenbankentwurf vokommen. Eine Realisierung von Untertabellen innerhalb einer Tabelle würde auch schon weiterhelfen. Idealerweise kann man von der Untertabelle aus auch Relationen herstellen.

Wie so etwas im Handling elegant gelöst werden könnte, hätte ich eine vage Idee. Falls sich jemand dafür interessiert, würde ich das mal kurz skizzieren.

2

Naja, das ist (meines Wissens) der (einzige) Wermutstropfen, den Base hat.

Papyrus sucht und findet verdammt flott und ist im Betrieb wahnsinnig sicher, aber diese form der Relationalität ist leider nicht gegeben. Das bläht den Datensatz nicht nur unnötig auf, das verhindert auch Ergebnisauswertungen!

Fragestellungen wie “welche Rechnungen hat Kunde X insgesamt bekommen und wieviel Umsatz macht er?” machen andere DB-Systeme quasi nebenher, Papyrus kann das in dieser Form noch(?) nicht.

Andererseits bin ich trotzdem bei Papyrus geblieben, weil das DB-Konzept auch Vorteile bietet. Seit ca. 10 Jahren programmiere ich um die n:m Problematik herum und habe Lösungswege gefunden, die einen manchmal schmunzeln lassen. Man trägt manchmal die Kirche ums Dorf, aber bis auf die Auswertung ist mir noch kein Problem untergekommen, das ich mit BASE nicht lösen konnte.

Meine Tabelle Rechnungen hat 30 Posten, und wenn die Bgrenzung von 255 Feldern pro Tabelle fällt kann sie von mir aus auch 150 Posten haben. Was soll´s? Strom ist geduldig :wink:

Eine Adresse wird in meiner Datenbank von “Adressen” zu “Aufträgen” und von dort zu “Rechnungen” getragen. Da kräuseln sich professionellen Programmierern sicherlich viele Körperteile, schade.

Aber andererseits ist sie immer da. Im Datensatz. In 3 Tabellen, manchmal noch mehr.

Meine ganze Datenbank hat trotzdem nur 10 MB, mein Arbeitsspeicher 2 GB. Da kann man die dollsten Sachen treiben.

Wie gesagt, die Struktur hat sicher Nachteile und ich unterstütze auch den Wunsch nach n:m Relationalität (unterstellt, wir meinen dasselbe) Aber nicht um den Preis der Schnelligkeit und Datensicherheit. Denn selbst (mehrfache) Stromausfälle beim schreiben eines Datensatzes haben meiner BASE-Datenbank noch nie was anhaben können. Da kenne ich von anderen Datenbanken andere Horrorgeschichten, die meines Wissens eben mit dieser Relationalität zu tun haben. (Allerdings bin da nicht mehr auf dem aktuellen Stand, vielleicht hat sich das ja gebessert.) Und wenn ich unbedingt wissen will, wieviel Umsatz Kunde X hat, suche ich seine Rechnungen und führe einen entsprechenden Report aus.

3

Ich möchte hier mal eine Idee vorstellen, wie sie für mich sehr nützlich wäre. Das ist keine vollwertige n-m-Relationslösung mit allem Schnick-Schnack, aber doch sehr flexibel und meiner Meinung nach auch übersichtlich in der Handhabung.

Nennen wir das mal Gruppierung statt Untertabellen oder n-m-Relation, das passt zum Lösungsansatz am besten.

Bei den Feldeigenschaften gibt es einen neuen Tab für Gruppierung. Dort werden die Gruppen angelegt, welche verwendet werden sollen. Eine Gruppe für jede Untertabelle. Das könnte in meiner Anwendung für eine Therapiepraxis im Rechnungsformular eine Gruppe ‘Dienstleistungen’ und eine Gruppe ‘Heilmittel’ sein.

Zu jeder Gruppe könnten dann allgemeine Einstellungen vorgenommen werden, soweit sinnvoll. z.B: max. Anzahl Datensätze, welche die Gruppe beinhalten darf.

Die Datenfelder innerhalb der Gruppe selbst werden wie bis anhin unter ‘Name und Typ’ festgelegt. Zusätzlich zu den bereits vorhandenen Eigenschaften ‘Feldname’ und ‘Datentyp’ müsste man in einem zusätzlichen Eigenschaftsfeld auswählen, zu welcher Gruppe dieser Eintrag gehört. Per Default ist es die normale Tabelle, ausgewählt werden können dann aber auch eine der angelegten Gruppen.

Das wäre schon alles was den Entwurf der Tabelle betrifft.

In der tabellarischen Übersicht aller Datensätze gibt es dann neu für jede Gruppe eine Spalte. Als Inhalt in dieser Spalte steht z.B., wieviele Datensätze innerhalb der Gruppe angelegt sind.

Es braucht dann natürlich ein paar zusätzliche Formeln, z.B. max, min, avg, count über bestimmte Felder innerhalb der Gruppe.

Was denkt ihr über so ein Feature? Wäre genügend Nachfrage dafür da, damit sowas implementiert werden könnte?

4

Untertabellen sind, wenn ich das jetzt richtig gelesen habe, auch nicht wirklich etwas anderes als m:n Relationen - und mit letzteren hätten wir eine viel leistungsfähigere Funktionalität.

Wenn derlei kommt, dann also als m:n Relation.

5

Stimmt. Mit Untertabellen ist man in der Funktionalität etwas eingeschränkt. Ich hoffe einfach, dass etwas in dieser Richtung in Papyrus einfliessen wird.