Datenbankschema

[PascheW]

Hallo,

gibt es irgendwo eine Dokumentation der egw-DB-Tabellen? Mir würde schon so etwas wie: Ein Satz zur Tabelle und eine Bemerkung je Spalte reichen. Momentan geht es speziell um den Projektmanager, da ich die Aufgabe habe, einen XML-Export von Projektdaten zu implementieren (ausgehend von einem “Projektknoten” für den ganzen “Baum” darunter (incl. Infolog und Timesheets). Ziel ist der Import in eine Mindmapping-Anwendung. Für mich (da ich seit ca. 15 Jahren Datenbankadministration und DB-Entwicklung betreibe) scheint es am einfachsten, die Daten direkt aus der DB zu holen (MySQL 5) und per Java-Programm (oder ggf. auch php) die XML-Ausgabe zu generieren. Die meisten Zusammenhänge habe ich bereits analysiert (pm_projects, pm_elements, links, infolog mit info_link_id, pm_members -> accounts etc.), aber eine entsprechende Kurzbeschreibung wäre eben doch sehr hilfreich um auszuschließen, dass ich etwas übersehe. Oder gibt es irgendeine API-Funktion, die mir die Daten liefern würde?

Vielen Dank im Voraus für Hilfe und
Grüße aus Hamburg

Wolfgang Pasche

[Manfred_Kiss]

Hallo Wolfgang,

meines Wissens existiert keine Doku zum egroupware Datenbankschema.

Zum einen ist - wenn ich das richtig sehe - der Aufbau der Schemata für MySQL und PostGres unterschiedlich.

• Bei PostGres scheint es keine referentielle Integrität zu geben.

[Und es gibt Konstrukte, die mich zum Verzweifeln bringen, wie die Integration von Kalender-Kategorien
in einem Characterfeld egw_cal.cal_category, bzw. im Adressbuch egw_addressbook.cat_id].

Ein Datenbankschema ist in diesem Forum schon mehrfach vergeblich angesprochen worden.

Solch ein Schema müßte halt permanent gepflegt werden.

Ein Reverse-Engineering dürfte hier auch relativ wenig bringen, auf Grund der fehlenden referentielle Integrität.

Gruß

Manfred

[PascheW]

Hallo Manfred,

zunächst einmal danke für die Antwort. Was ich mich halt frage: Offenbar gibt es doch mitunter neue Entwickler. Müssen die erraten, wofür die Tabellen bzw. deren Inhalte da sind, oder bekommen die “irgend etwas”, womit sie sich einarbeiten können? Dieses “irgend etwas” hätte ich halt gerne auch!

Grüße
Wolfgang

[sbegw]

Hallo Wolfgang,

hier findest du die Dokumentation für Entwickler:
http://www.egroupware.org/devdocs

Die Beschreibung der Datenbankfelder sind natürlich in EGroupware abgelegt.
Dazu einfach die Anwendung etemplate öffnen und auf das DB-Tool klicken.

Stefan

Hallo Manfred,

zunächst einmal danke für die Antwort. Was ich mich halt frage: Offenbar
gibt es doch mitunter neue Entwickler. Müssen die erraten, wofür die
Tabellen bzw. deren Inhalte da sind, oder bekommen die “irgend etwas”, womit
sie sich einarbeiten können? Dieses “irgend etwas” hätte ich halt gerne
auch!

Grüße
Wolfgang

–
Stylite GmbH

Morschheimer Strasse 15 D-67292 Kirchheimbolanden
Tel +49(0)6352-70629-0 Fax +49(0)6352-70629-30
E-Mail: sb@stylite.de

Managing Directors
Andre Keller, Ralf Becker
VAT DE214280951 HRB 30575 Kaiserslautern
http://www.stylite.de

---

The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server’s
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[moe]

Hallo,

Ja, so ein Schema wäre schon was …

Zum einen ist - wenn ich das richtig sehe - der Aufbau der Schemata für
MySQL und PostGres unterschiedlich.

• Bei PostGres scheint es keine referentielle Integrität zu geben.
  Bei PG gibt es eig. schon immer? ref. Integrität nur bei MySQL gab es
  die erst später …

Ein Datenbankschema ist in diesem Forum schon mehrfach vergeblich
angesprochen worden.
Ja, schade eig. Es würde die Entwicklung sicherlich enorm vereinfachen.

Solch ein Schema müßte halt permanent gepflegt werden.
Das ist kein Argument … wenn es einmal erstellt ist, sollten die DB
Änderungen ja nicht mehr gravirend sein.

Gruß moe

---

The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server’s
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[moe]

Hallo Stefan,

Die Beschreibung der Datenbankfelder sind natürlich in EGroupware abgelegt.
Dazu einfach die Anwendung etemplate öffnen und auf das DB-Tool klicken.
Entweder ich verstehe Dich miss oder du meinst etwas anderes.
Ein DB-Schema kann ich dort nicht erkennen. Da kann man anscheindend
Tabellen bearbeiten aber wo stehen die Beschreibungen der Tabellenfelder
und die zusammenhänge zwischen Tabellen bzw. Tabellenspalten?

Gruß moe

---

The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server’s
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[Manfred_Kiss]

Hallo moe

Bei PG gibt es eig. schon immer? ref. Integrität nur bei MySQL gab es
die erst später …

Lege einmal eine private Kalenderkategorie an.
Erzeuge einen Termin mit dieser Kategorie und lösche diese Kategorie dann.
Funktioniert prima.

Darf aber nicht, wenn eine referenzielle Integrität existieren würde.

Gruß

Manfred

[moe]

Hallo Manfred,

ich meinte nicht das was von egw genutzt wird, sondern das was die
DB-Server an sich “können”.
Und da ist es eben so, dass MySQL erst ref. Int. bekam als es PG schon
jahrelang unterstützte … also ob man wollte oder nicht musste man bei
MySQL darauf verzichten. Ob man die jeweiligen Funktionalitäten der DBMS
nutzt steht ja auf einem ganz anderen Blatt … nach Deinen Erfahrungen
ja anscheindend bzgl. egw nicht in diesem Fall. Habs aber nicht probiert
… glaube es Dir auch so.

Gruß Moe

Lege einmal eine private Kalenderkategorie an.
Erzeuge einen Termin mit dieser Kategorie und lösche diese Kategorie dann.
Funktioniert prima.

Darf aber nicht, wenn eine referenzielle Integrität existieren würde.

Gruß

Manfred

---

The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server’s
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[PascheW]

Hallo Wolfgang,

hier findest du die Dokumentation für Entwickler:
http://www.egroupware.org/devdocs

Die Beschreibung der Datenbankfelder sind natürlich in EGroupware abgelegt.
Dazu einfach die Anwendung etemplate öffnen und auf das DB-Tool klicken.

Stefan

Hallo Stefan,

die Developer Doku hatte ich bereits gefunden, aber auch dort sehe ich keine Tabellenbeschreibungen. Genauso in den DB-Tools der etemplate Anwendung: Die dortigen Infos liefert mir jedes beliebige DB-Tool, sei es nun TOAD, phpmyadmin oder DBVisualizer (etc., etc…). Interessant wäre genau die Spalte “Kommentar”, aber leider ist die in keinem einzigen Fall gefüllt. Es bleibt also bedauerlicherweise doch nur raten und ausprobieren. Schade!
Die Fälle, in denen der Spaltenname übereinstimmt, sind natürlich harmlos, aber schon die Tabelle “links” muss man ja erst einmal “entdecken”. Und so etwas wie die Spalte “info_link_id”, die dann wieder auf “pe_id” zeigt, ist noch schwerer zu finden. Hier wären kurze Kommentare extrem hilfreich. Vielleicht zumindest eine Aufgabe für ein zukünftiges Release? Würde sich doch eigentlich für alle lohnen.

Grüße
Wolfgang

[Manfred_Kiss]

Hallo Moe,

Das ist kein Argument … wenn es einmal erstellt ist, sollten die DB
Änderungen ja nicht mehr gravierend sein.

Ich denke, das sollte man nicht unterschätzen.

Wenn z.B. unterschiedliche Trunkversionen diverse Änderungen im Schema nach sich ziehen,
müßte man für jede Trunkversion eine eigene Version des Schemas führen.

Gruß

Manfred

[moe]

Das ist kein Argument … wenn es einmal erstellt ist, sollten die DB
Änderungen ja nicht mehr gravierend sein.

Ich denke, daß sollte man nicht unterschätzen.

Wenn z.B. unterschiedliche Trunkversionen diverse Änderungen im Schema nach
sich ziehen,
müßte man für jede Trunkversion eine eigene Version des Schemas führen.

Moin Manfred,

tue in keinem Fall. Was ich damit meinte ist, dass ein gutes DB-Design
keine gravierenden Änderungen erfahren muss wenn es von vorn herein sehr
gut durchdacht ist. Natürlich gibt es im Laufe der Entwicklung immer mal
situationen, die erfordern ein Feld oder eine Beziehung oder sogar eine
Tabelle zu ergänzen. I.d.R. fällt aber nichts weg, schon wegen der
abwärtskompatiblität. Wenn neue Module hinzukommen kann natürlich auch
mal ein Schwung neuer Tabellen nötig sein, aber wenn das ganze halbwegs
modular aufgebaut ist, ist auch das kein Problem.
Eigentlich bestehen, die Änderungen also aus Ergänzungen und Ergänzungen
könnte man genauso Versionieren wie man es mit Softwareständen tut. IMHO
ändert sich in den Trunkversionen ja nicht immer etwas am DB-aufbau.
Aber ich glaube wir dirten hier schon wieder ins OT ;))

schönen Tach!
Moe

---

The ultimate all-in-one performance toolkit: Intel® Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german