OODBMS - Objektorientierte Datenbank
-
- Beiträge: 298
- Registriert: Di 23. Nov 2010, 23:41
- OS, Lazarus, FPC: Ubuntu/Win, Lazarus trunk, FPC trunk
- CPU-Target: 32Bit/64Bit
- Wohnort: Geldern
- Kontaktdaten:
OODBMS - Objektorientierte Datenbank
Hat schon jemand Erfahrungen mit einem Objektdatenbankmanagementsystem gesammelt wenn ja, gibt es eine Implementierung der Schnittstelle zu Free Pascal/Lazarus oder auch nur Ansätze?
MfG Gocher
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
-
- Beiträge: 6079
- Registriert: Do 21. Sep 2006, 07:51
- OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
- CPU-Target: AVR,ARM,x86(-64)
- Wohnort: Dessau
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
Do meinst NoSQL Datenbanken ?
Oder Object Persistence Frameworks?
Oder Object Persistence Frameworks?
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/
Re: OODBMS - Objektorientierte Datenbank
Sowas, oder? http://de.wikipedia.org/wiki/Objektdatenbank
Da ist mir aber nichts bekannt.
Da ist mir aber nichts bekannt.
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: OODBMS - Objektorientierte Datenbank
Bei einem OODBMS wird nicht auf die Daten "zugegriffen", sondern es werden aktive "Objekte" programmiert. Wenn man (ausschließlich) Pascal programmieren und ein OODBMS verwenden will muss man also ein System haben, das (Teile der) Applikationen von Pascal in die Programmiersprache der virtuellen Maschine des OODBMS übersetzt. Da fpc bereits aus einer Pascal Source Code für eine virtuelle Maschine (nämlich Java Byte Code) erzeugt ist das zumindest prinzipiell denkbar.
Keine Ahnung, was für einen Code OODBMS (falls überhaupt bereits welche existieren) verwenden. Wenn sie von großen Herstellern kommen, sicherlich jedes einen anderen. ORACLE/SUN: Java Byte Code. Google: Dalvic (Java Word Code), Microsoft: CIL (aka .NET / C# / Mono).
Auf absehbare Zeit jedenfalls wenig Aussicht auf Hoffnung,.
-Michael
Keine Ahnung, was für einen Code OODBMS (falls überhaupt bereits welche existieren) verwenden. Wenn sie von großen Herstellern kommen, sicherlich jedes einen anderen. ORACLE/SUN: Java Byte Code. Google: Dalvic (Java Word Code), Microsoft: CIL (aka .NET / C# / Mono).
Auf absehbare Zeit jedenfalls wenig Aussicht auf Hoffnung,.
-Michael
-
- Beiträge: 298
- Registriert: Di 23. Nov 2010, 23:41
- OS, Lazarus, FPC: Ubuntu/Win, Lazarus trunk, FPC trunk
- CPU-Target: 32Bit/64Bit
- Wohnort: Geldern
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
Eigentlich brauche ich eine Datenbank um Objektstrukturen, die ich zur Zeit in Form von XML-Dateien ablege, besser organisieren zu können, zur Zeit habe ich ca. 320.000 Dateien über die ich unterschiedliche Indexe Angelegt habe, das geht im Moment noch, aber ich rechne mal ein Jahr weiter und ~30.000 - 40.000 Dateien mehr, das wird bestimmt nicht besser. Nun habe ich mich umgesehen und auch unterschiedlich Lösungsansätze wie ich mir so etwas vorstellen könnte, es müsste halt vom Typ her ein Document-Store sein, so etwas sollte also mit CouchDB oder MongoDB funktionieren. Jetzt habe ich aber nun mal meine Quellen alle in Pascal und nicht gerade wenige Daten und kenne mich würde ich sagen relativ gut mit SQL aus, habe aber keine Ahnung von den besagten Datenbanken, also kann nicht abschätzen ob eine Datenbank mit einem Volumen in der Größenordnung klar kommt und zweitens ob es dafür eine API für Pascal oder zumindest ordentlich Beschreibung also Grundlage zu Erstellung einer Schnittstelle für Free Pascal gibt.
Zur weiteren Info, die XML-Dateien enthalten Strukturen und Inhalte also im Prinzip stark vereinfacht:
Zur weiteren Info, die XML-Dateien enthalten Strukturen und Inhalte also im Prinzip stark vereinfacht:
Code: Alles auswählen
<root>
<title>Beispiel Titel</titel>
...
<main class="content"> <!-- content, author, ... -->
<!-- INHALT je nach definition der Klasse -->
</main>
<author id="a1" />
...
<attributes>
<attribute id="layout" value="l1" />
<attribute id="pdf" value="l1.pdf" />
...
</attributes>
<entries>
<entry id="x1" url="/x1" alt="querverweis" />
<entry id="x2" url="/x2" alt="querverweis" />
...
</entries>
</root>
MfG Gocher
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: OODBMS - Objektorientierte Datenbank
Den Datenbank-Server selber in Pascal schreiben ?!?!?!?
-Michael
-Michael
-
- Beiträge: 298
- Registriert: Di 23. Nov 2010, 23:41
- OS, Lazarus, FPC: Ubuntu/Win, Lazarus trunk, FPC trunk
- CPU-Target: 32Bit/64Bit
- Wohnort: Geldern
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
Nein das habe ich gerade nicht vor, ich möchte eigentlich eine ordentliche existierende Datenbank nutzen, nur vielleicht die Schnittstelle zu Pascal selber schaffen! Ich wollte eigentlich von den Überlegungen die sich einige Entwickler in den letzten Jahren gemacht haben profitieren
!

MfG Gocher
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: OODBMS - Objektorientierte Datenbank
Klar ist es immer schöner, wenn man "Standards" verwenden kann und damit auf bereits geleistete Arbeit zurückgreift, statt alles selber neu zu erfinden.
Aber "Standard" und "super high Performance" sind oft ein Widerspruch. "SOAP" (= XML über HTTP) ist zwar ein wichtiger Standard und deshalb überall relativ leicht System-übergreifend integrierbar, aber SOAP ist ein bekannter Performance-Fresser und gegenüber binären TCP/IP Socket-Socket Kommunikation grauenhaft langsam.
Wenn Du z.B. jede Menge "Beschreibungs-Records" (Zuordnung von diversen Inhalt zu diversen Eigenschaft) brauchst, wäre es natürlich viel performanter die Daten statt in Dateien als ASN1 Text zu halten, diese im (virtuellen) RAM als binär codierte Objekte (wie fpc/Lazarus das macht) darzustellen.
Über Netzwerk ist vermutlich eine an die Anwendung angepasste binäre Prozedur deutlich performanter als SQL.
Die Aufteilung der Arbeit zwischen Client und Server kann sicher besser an die Anwendung angepasst werden als es mit normalen SQL Mitteln möglich ist. (Auch mit SQL könnten Werte wie Zahlen und Eigenschaften-Namen binär gehalten und erst bei der Darstellung lesbar umgewandelt werden, um beim Server Rechenarbeit und Platz im RAM und in der Datenbank einzusparen. Außerdem kann ein Cache im Client - der z.B. mit Datenbank-Events synchronisiert wird - den Server entlasten.)
Wenn Du Standards und Standard-Software verwenden willst, kommt wahrscheinlich bei normalen Datenbank-Servern die excessive Verwendung von "Stored Procedures" dem Objekt-orientierten Ansatz am nächsten.
Das hat dann mit Pascal natürlich nicht mehr viel zu tun
-Michael
Aber "Standard" und "super high Performance" sind oft ein Widerspruch. "SOAP" (= XML über HTTP) ist zwar ein wichtiger Standard und deshalb überall relativ leicht System-übergreifend integrierbar, aber SOAP ist ein bekannter Performance-Fresser und gegenüber binären TCP/IP Socket-Socket Kommunikation grauenhaft langsam.
Wenn Du z.B. jede Menge "Beschreibungs-Records" (Zuordnung von diversen Inhalt zu diversen Eigenschaft) brauchst, wäre es natürlich viel performanter die Daten statt in Dateien als ASN1 Text zu halten, diese im (virtuellen) RAM als binär codierte Objekte (wie fpc/Lazarus das macht) darzustellen.
Über Netzwerk ist vermutlich eine an die Anwendung angepasste binäre Prozedur deutlich performanter als SQL.
Die Aufteilung der Arbeit zwischen Client und Server kann sicher besser an die Anwendung angepasst werden als es mit normalen SQL Mitteln möglich ist. (Auch mit SQL könnten Werte wie Zahlen und Eigenschaften-Namen binär gehalten und erst bei der Darstellung lesbar umgewandelt werden, um beim Server Rechenarbeit und Platz im RAM und in der Datenbank einzusparen. Außerdem kann ein Cache im Client - der z.B. mit Datenbank-Events synchronisiert wird - den Server entlasten.)
Wenn Du Standards und Standard-Software verwenden willst, kommt wahrscheinlich bei normalen Datenbank-Servern die excessive Verwendung von "Stored Procedures" dem Objekt-orientierten Ansatz am nächsten.
Das hat dann mit Pascal natürlich nicht mehr viel zu tun

-Michael
-
- Beiträge: 298
- Registriert: Di 23. Nov 2010, 23:41
- OS, Lazarus, FPC: Ubuntu/Win, Lazarus trunk, FPC trunk
- CPU-Target: 32Bit/64Bit
- Wohnort: Geldern
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
Also Stored Procedures unter Interbase mit Delphi wie vor 13 Jahren
, nein, nein und nochmal nein! Irgendwie ist das ganze Datenvolumen wie ein riesig großer Treeview mit unterschiedlichen Attributen und Querverbindungen, der in allen Richtungen wächst. Da bin ich dann mit meinen XML-Daten, Index-Dateien, PDF-Dateien, Media-Daten und Suchindex im Filesystem noch besser bedient!

MfG Gocher
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
-
- Beiträge: 340
- Registriert: Di 12. Sep 2006, 08:57
- OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
- CPU-Target: xxBit
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
Die Oracle-Datenbank (11g oder höher) kann ganz gut mit XML umgehen, da sie das XML-Dokument nicht unbedingt zerlegen muss, sondern das Ding als Text speichern kann. Abfragen kann man es danach dennoch über SQL. Allerdings ist dein Fall doch recht speziell. Man mag sich fragen, wie du zu diesem "XML-Datei-Chaos" kommst. Meist hat man ja doch strukturierte Informationen vorliegen. Die Lizenzierung ist für Privatanwender kostenfrei. Allerdings bremst das RDBMS den Server merklich und derAufwand ist schon recht ordentlich.
Grüße, Antrepolit
care only if your os is really burning
care only if your os is really burning
-
- Beiträge: 6079
- Registriert: Do 21. Sep 2006, 07:51
- OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
- CPU-Target: AVR,ARM,x86(-64)
- Wohnort: Dessau
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
In Blobs speichern kann das jede Datenbank. Es gibt aber durchaus direkt XML Datenbanken.
http://de.wikipedia.org/wiki/XML-Datenbank
Das was du sonst beschreibst hört sich nach ner NoSQL Datenbank an.
http://nosql-database.org/
http://de.wikipedia.org/wiki/XML-Datenbank
Das was du sonst beschreibst hört sich nach ner NoSQL Datenbank an.
http://nosql-database.org/
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: OODBMS - Objektorientierte Datenbank
Ein Bekannter von mir verwendet (mit Delphi) "stored Procedures" mit MSSQL (und ich glaube auch mit MySQL) sehr erfolgreich.gocher hat geschrieben:Also Stored Procedures unter Interbase mit Delphi wie vor 13 Jahren, nein, nein und nochmal nein!
-MIchael
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: OODBMS - Objektorientierte Datenbank
Das ist aber eine monstermäßige Platzverschwendung. Es werden doch vermutlich immer wieder dieselben Eigenschaften mit Werten gefüllt. Da sind Tebellen viel effektiver.Antrepolit hat geschrieben: das XML-Dokument nicht unbedingt zerlegen muss, sondern das Ding als Text speichern
-Michael
-
- Beiträge: 298
- Registriert: Di 23. Nov 2010, 23:41
- OS, Lazarus, FPC: Ubuntu/Win, Lazarus trunk, FPC trunk
- CPU-Target: 32Bit/64Bit
- Wohnort: Geldern
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
Naja, zwischen den XML-Dokumenten bestehen Referenzen, im Haupt-Bereich steht eine XHTML Struktur, aus diesem Content existieren, ich nenne sie mal hier harte Referenzen, zu dem Dokument existieren Kind-Elemente, also auch harte Referenzen, aus Themenzugehörigkeit (Rubrik, Keywords, ...) ergeben sich weiche Referenzen, dann existieren noch Boxen mit harten und weichen Referenzen. Genau so existieren aber auch in umgekehrter Richtung Referenzen, die müssen als Fremdbeziehungen geführt werden damit eine Korrektur in diesen Dokumenten auch durchgeführt werden kann, denn beim Hinzufügen, Ändern und Löschen müssen alle diese Referenzen überprüft werden.
Zusätzlich zu diese ganzen Referenzen existieren natürlich noch Links zu Bildern, Filmen, Downloads jeder Art, oder auch eine PDF-Version der Seite.
Zum Inhalt gibt es je nach der Klasse angepasste Teil-Layouts, aus gewissen Gruppen der Klasse Nachricht ergeben sich Feeds, und und und....
Leider können noch nicht immer alle Referenzen automatisch korrigiert werden, darum wird einmal pro Nacht die Struktur überprüft, und eine sogenannte Checkliste angelegt in der die Fehler aufgelistet werden. Mit den Links zum Bearbeiten, angestrebt ist jedoch alle Referenzen automatisch zu korrigieren, also zu löschen (inaktiver Link) wenn eine Beziehung entfällt oder umzubenennen wenn eine Beziehung umbenannt wurde. Externe fehlerhafte Links landen natürlich immer in der Checkliste, außer bei 301 Moved Permanently, da wird verbogen!
Zusätzlich existieren noch Attribute wie z.B. Autor(en), Rubrik, Gültigkeitszeitraum, Änderungsintervall, Wichtigkeit, ... und so ziemlich alles was in den Metadaten einer HTML Vorkommt.
Benötigte Scripte werden während der Generierung der Seite die Objektorientiert zusammen gebaut wird durch die Abhängigkeit zum Objekt hinzugefügt, darum brauche ich mich seit kurzem Gott sei Dank nicht mehr kümmern. Da zum Aufbau einer Seite immer nur die Teilinformationen einiger Referenzen benötigt werden, die Navigation und einmal die Breadcrumbs bis zum Root aus dem Index generiert werden muss, funktioniert der Aufbau relativ schnell (also wenige Millisekunden).
Das wachsende Problem entsteht beim Speichern und Überprüfen der stetig wachsenden Struktur und beim wachsen der Index-Dateien und natürlich auch des Suchindexes!
Zusätzlich zu diese ganzen Referenzen existieren natürlich noch Links zu Bildern, Filmen, Downloads jeder Art, oder auch eine PDF-Version der Seite.
Zum Inhalt gibt es je nach der Klasse angepasste Teil-Layouts, aus gewissen Gruppen der Klasse Nachricht ergeben sich Feeds, und und und....
Leider können noch nicht immer alle Referenzen automatisch korrigiert werden, darum wird einmal pro Nacht die Struktur überprüft, und eine sogenannte Checkliste angelegt in der die Fehler aufgelistet werden. Mit den Links zum Bearbeiten, angestrebt ist jedoch alle Referenzen automatisch zu korrigieren, also zu löschen (inaktiver Link) wenn eine Beziehung entfällt oder umzubenennen wenn eine Beziehung umbenannt wurde. Externe fehlerhafte Links landen natürlich immer in der Checkliste, außer bei 301 Moved Permanently, da wird verbogen!
Zusätzlich existieren noch Attribute wie z.B. Autor(en), Rubrik, Gültigkeitszeitraum, Änderungsintervall, Wichtigkeit, ... und so ziemlich alles was in den Metadaten einer HTML Vorkommt.
Benötigte Scripte werden während der Generierung der Seite die Objektorientiert zusammen gebaut wird durch die Abhängigkeit zum Objekt hinzugefügt, darum brauche ich mich seit kurzem Gott sei Dank nicht mehr kümmern. Da zum Aufbau einer Seite immer nur die Teilinformationen einiger Referenzen benötigt werden, die Navigation und einmal die Breadcrumbs bis zum Root aus dem Index generiert werden muss, funktioniert der Aufbau relativ schnell (also wenige Millisekunden).
Das wachsende Problem entsteht beim Speichern und Überprüfen der stetig wachsenden Struktur und beim wachsen der Index-Dateien und natürlich auch des Suchindexes!
MfG Gocher
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
-
- Beiträge: 298
- Registriert: Di 23. Nov 2010, 23:41
- OS, Lazarus, FPC: Ubuntu/Win, Lazarus trunk, FPC trunk
- CPU-Target: 32Bit/64Bit
- Wohnort: Geldern
- Kontaktdaten:
Re: OODBMS - Objektorientierte Datenbank
Also sauberer geht es eigentlich gar nicht mehr, alle Links bleiben sauber oder stehen zumindest in der Checkliste und können korrigiert werden, Eigenschaften können klassenspezifisch ohne Anpassung eine Datenbank vorgenommen werden.Antrepolit hat geschrieben:... Man mag sich fragen, wie du zu diesem "XML-Datei-Chaos" kommst. Meist hat man ja doch strukturierte Informationen vorliegen...
Bei den ca.40 Klassen mit von der Klasse abhängigen Felder würde entweder eine ziemlich Breite Tabelle entstehen oder einige Tabellen. Zusätzlich wären einige Verknüpfungstabellen erforderlich, bei den XML-Dokumenten sind die Verknüpfungs-IDs gleichzeitig die Dateinamen ohne Endung und sprechende URLs.
Also eher ein schlichter Aufbau, schöner wäre nur eine Riesen Struktur mit Zeigern die man über Programmierte Methoden anpasst, diese Struktur hätte aber leider bei der Datenmasse nicht mehr genug Platz im Speicher und so suche ich nach einer Möglichkeit Teilbereiche dieser Struktur zu verändern und natürlich auch als Gesamtkomplex zu durchforsten, also mich in der Struktur zu bewegen und quasi eine Teilansicht zu generieren.
MfG Gocher
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me
akt. Projekt: Webserver(HTTPS HTTP/2) mit integrierten CMS in Free Pascal - www.gocher.me