Hallo Flash,
das mit der variablen Spaltenanzahl stimmt.
Ich habe das nicht ganz vollständig beschrieben.
Die Spalten 1 bis 26 gibt es immer.
Ab Spalte 27 werden die Ehen ausgegeben, für jede Ehe vier Spalten.
"MARR.DATE.1";"MARR.PLAC.1";"MARR.SPOU.NAME.1";"MARR.SPOU.REFN.1"
Ab Spalte 31:
"MARR.DATE.2";"MARR.PLAC.2";"MARR.SPOU.NAME.2";"MARR.SPOU.REFN.2"
usw.
Die Ehen werden durchnummeriert.
Ich glaube die Anzahl der Ehen ist "unbegrenzt".
Developer Info
Hallo Jürgen,
ja ich meinte stb und sein www-Tool - war also kein klassisches Plugin, vielleicht habe ich es deswegen nicht mehr gefunden. Danke für den Hinweis!
Rogers Idee mit SQLite zu arbeiten ist ein guter Ansatz - das sollte in der Tat um einiges performanter sein und auch bei größeren Datenbeständen kein Problem bereiten.
Marcus
ja ich meinte stb und sein www-Tool - war also kein klassisches Plugin, vielleicht habe ich es deswegen nicht mehr gefunden. Danke für den Hinweis!
Rogers Idee mit SQLite zu arbeiten ist ein guter Ansatz - das sollte in der Tat um einiges performanter sein und auch bei größeren Datenbeständen kein Problem bereiten.
Marcus
Hallo,
Um eine Datenbank anzulegen, muss man doch zuerst mal aus Ahnenblatt heraus eine csv-Datei abspeichern und diese dann in eine Datenbank umwandeln - mit welcher Sprache auch immer. Das erfordert Zeit.
Die Datenbank liegt dann auf der Festplatte.
Der Zugriff auf die Datenbank innerhalb eines Programmes erfordert einen ständigen Zugriff auf die Festplatte.
Wenn ich die von Ahnenblatt erstellte csv-Datei direkt in ein zweidimensionales Array einlese habe ich dieses Array im Hauptspeicher. Einen schnelleren Zugriff auf diese Daten gibt es doch nicht.
Oder habe ich den Sinn der Diskussion nicht verstanden?
ich kann nicht ganz folgen.Roger Paini hat geschrieben:Ein Objektmodell für die Daten zu verwenden halte ich für keinen guten Ansatz da der Overhead bei 25000 Personen wohl extrem wird. Arrays sind schnell, bei sehr vielen Daten wird aber auch dies länger dauern.
Um eine Datenbank anzulegen, muss man doch zuerst mal aus Ahnenblatt heraus eine csv-Datei abspeichern und diese dann in eine Datenbank umwandeln - mit welcher Sprache auch immer. Das erfordert Zeit.
Die Datenbank liegt dann auf der Festplatte.
Der Zugriff auf die Datenbank innerhalb eines Programmes erfordert einen ständigen Zugriff auf die Festplatte.
Wenn ich die von Ahnenblatt erstellte csv-Datei direkt in ein zweidimensionales Array einlese habe ich dieses Array im Hauptspeicher. Einen schnelleren Zugriff auf diese Daten gibt es doch nicht.
Oder habe ich den Sinn der Diskussion nicht verstanden?
Gruß
Jürgen
Jürgen
Der Array ist auf jeden Fall schnell (wenn man nicht darin suchen muss). Roger zielte wohl eher auf die Idee, die Daten in eine geeignete Datenstruktur abzulegen. Die aber wäre wiederum stark vom Einsatzzweck abhängig. Daher könnte das Einlesen und Ablegen in eine Datenbank durchaus schnell sein, wenn danach z.B. nur auf einen kleinen Teilbereich zugegriffen wird oder unterschiedliche Datenstrukturen für unterschiedliche Anforderungen im Programm sinnvoll wären.
Generell schneller ist dies aber nicht. Vor allem wenn Du sowieso jeden Datensatz durchläufst und daraus einfach nur einen unsortierten Wert brauchst, dürfte das Array unschlagbar sein.
Marcus
Generell schneller ist dies aber nicht. Vor allem wenn Du sowieso jeden Datensatz durchläufst und daraus einfach nur einen unsortierten Wert brauchst, dürfte das Array unschlagbar sein.
Marcus
Ich habe mich für ein Objekt entschieden, weil ich so am einfachsten Verwandschaftsverknüpfungen erstellen kann.
Außerdem werden Z.b. REFNs direkt als Integer gespeichert, so daß sie gleich beim Einlesen umgewandelt werden, anstatt bei jedem Aufruf.
So ist die Verwandtschaftssuche im Datenschutz-Plugin jetzt unschlagbar schnell, auch die Filterung inkl. Datenvergleich ist bei einer fünfstelligen Personenanzahl noch extrem schnell.
Es mag ja sein, daß etwas Arbeitsspeicher verschwendet wird, aber das ist mir die Arbeitsersparnis wert - ein Objekt ist in sich funktionsfähig, um ein Array muß immer herumgebaut werden.
Viele Grüße,
Imanuel
Außerdem werden Z.b. REFNs direkt als Integer gespeichert, so daß sie gleich beim Einlesen umgewandelt werden, anstatt bei jedem Aufruf.
So ist die Verwandtschaftssuche im Datenschutz-Plugin jetzt unschlagbar schnell, auch die Filterung inkl. Datenvergleich ist bei einer fünfstelligen Personenanzahl noch extrem schnell.
Es mag ja sein, daß etwas Arbeitsspeicher verschwendet wird, aber das ist mir die Arbeitsersparnis wert - ein Objekt ist in sich funktionsfähig, um ein Array muß immer herumgebaut werden.
Viele Grüße,
Imanuel
-
Roger Paini
- Administrator
- Beiträge: 943
- Registriert: 12.02.2006, 11:32
- Wohnort: Reinach BL
Hallo Jürgen
Sorry, dass ich erst jetzt antworte, zur Zeit geht es Rund bei mir
.
- Durchlaufen des gesamten Datenbestandes in einer Reihenfolge zwecks Ausgabe (Listen, Reports)
- Filterung, Suche und Statistik von Daten und deren Darstellung
Im ersten Fall hat eine Datenbank keinerlei Vorteile, im zweiten jedoch, macht sie das Leben des Entwicklers um einiges einfacher. Vor allem im Hinblick auf Datenbestände von 25'000 Personen und mehr wirst du mit Arrays vermutlich an Grenzen stossen, je nach Filterkriterien der Benutzer auch an Logikprobleme (AND, OR). Ich bin jedoch deiner Meinung, Arrays sind im Arbeitsspeicher und sind daher sehr schnelle Diener, vorausgesetzt der Benutzer hat genug Arbeitsspeicher für die Daten
.
Meine Idee war ein Tool zu schreiben welches eine Gedcom Datei (sorry, ich traue CSV einfach nicht ganz) korrekt mit allen Relationen in einer Datenbank ablegt. Glaub mir, SQLite ist sehr performant! Entwickler von Plugins die dann eine Idee haben und eine Datenbank als guten Weg sehen um ihr Problem zu lösen könnten dann darauf zugreifen, sozusagen als Schnittstelle. Die Routine würde einmal erstellt und könnte von vielen direkt genutzt werden. So schreibt jeder Plugin-Autor mit einer Plugin-Idee die selben Routinen selber - schade wenn's schon ein anderer gemacht hat.
Natürlich kommt es auch immer auf den Kenntnistand der Autoren an ob sie die Schnittstelle verstehen und benutzen können (SQL als Abfragesprache ist ein Muss).
Ich hoffe meine Ausführung hat deine Fragen beantwortet. Die Idee war vor allem als Denkanstoss gedacht.
Gruss
Roger
Sorry, dass ich erst jetzt antworte, zur Zeit geht es Rund bei mir
.Ich sehe 2 Bereiche die oft genutzt werden:Jürgen T. hat geschrieben: ich kann nicht ganz folgen.
Um eine Datenbank anzulegen, muss man doch zuerst mal aus Ahnenblatt heraus eine csv-Datei abspeichern und diese dann in eine Datenbank umwandeln - mit welcher Sprache auch immer. Das erfordert Zeit.
Die Datenbank liegt dann auf der Festplatte.
Der Zugriff auf die Datenbank innerhalb eines Programmes erfordert einen ständigen Zugriff auf die Festplatte.
Wenn ich die von Ahnenblatt erstellte csv-Datei direkt in ein zweidimensionales Array einlese habe ich dieses Array im Hauptspeicher. Einen schnelleren Zugriff auf diese Daten gibt es doch nicht.
- Durchlaufen des gesamten Datenbestandes in einer Reihenfolge zwecks Ausgabe (Listen, Reports)
- Filterung, Suche und Statistik von Daten und deren Darstellung
Im ersten Fall hat eine Datenbank keinerlei Vorteile, im zweiten jedoch, macht sie das Leben des Entwicklers um einiges einfacher. Vor allem im Hinblick auf Datenbestände von 25'000 Personen und mehr wirst du mit Arrays vermutlich an Grenzen stossen, je nach Filterkriterien der Benutzer auch an Logikprobleme (AND, OR). Ich bin jedoch deiner Meinung, Arrays sind im Arbeitsspeicher und sind daher sehr schnelle Diener, vorausgesetzt der Benutzer hat genug Arbeitsspeicher für die Daten
.Meine Idee war ein Tool zu schreiben welches eine Gedcom Datei (sorry, ich traue CSV einfach nicht ganz) korrekt mit allen Relationen in einer Datenbank ablegt. Glaub mir, SQLite ist sehr performant! Entwickler von Plugins die dann eine Idee haben und eine Datenbank als guten Weg sehen um ihr Problem zu lösen könnten dann darauf zugreifen, sozusagen als Schnittstelle. Die Routine würde einmal erstellt und könnte von vielen direkt genutzt werden. So schreibt jeder Plugin-Autor mit einer Plugin-Idee die selben Routinen selber - schade wenn's schon ein anderer gemacht hat.
Natürlich kommt es auch immer auf den Kenntnistand der Autoren an ob sie die Schnittstelle verstehen und benutzen können (SQL als Abfragesprache ist ein Muss).
Ich hoffe meine Ausführung hat deine Fragen beantwortet. Die Idee war vor allem als Denkanstoss gedacht.
Gruss
Roger
Hallo Roger,
jetzt habe ich verstanden was Du meintest.
Leider scheint Visual Basic 2008 Express Edition nicht auf eine SQLite-Datenbank zugreifen zu können.
Zitat:
For those using VS 2008 Express Design-Time support does not work, so do not install it. This is not a glitch, it is disabled by Microsoft in the Express edition of 2008, but does work in the 2005 Express Edition. This is not used in the tutorial so it will not matter either way if you have it installed it.
Ich könnte diese Datenbank also zur Zeit nicht nutzen.
Entweder müsste ich auf die 2005er Express Edition zurückgehen oder mir die 2008er Voll-Version kaufen.
Aber grundsätzlich ist Deine Idee super.
jetzt habe ich verstanden was Du meintest.
Leider scheint Visual Basic 2008 Express Edition nicht auf eine SQLite-Datenbank zugreifen zu können.
Zitat:
For those using VS 2008 Express Design-Time support does not work, so do not install it. This is not a glitch, it is disabled by Microsoft in the Express edition of 2008, but does work in the 2005 Express Edition. This is not used in the tutorial so it will not matter either way if you have it installed it.
Ich könnte diese Datenbank also zur Zeit nicht nutzen.
Entweder müsste ich auf die 2005er Express Edition zurückgehen oder mir die 2008er Voll-Version kaufen.
Aber grundsätzlich ist Deine Idee super.
Gruß
Jürgen
Jürgen
-
Roger Paini
- Administrator
- Beiträge: 943
- Registriert: 12.02.2006, 11:32
- Wohnort: Reinach BL
Hallo Roger,
Aus meinem VB-Handbuch kann ich ersehen, dass folgende Datenbanken von vb 2008 Express gelesen werden können.
Access: (*.mdb)
MySQL mit einem ODBC-Treiber
MS SQL Server 2005
FoxPro VFP
Oracle
Paradox
Visual FoxPro
Zusätzlich lese ich, dass es auch eine Datenbankmöglich auf der Grundlage einer csv-Datei gibt.
Das ist mir neu.
Da muss ich mal näher nachschauen.
wie wahr...Roger Paini hat geschrieben: Sehr enttäuschend...Roger
Aus meinem VB-Handbuch kann ich ersehen, dass folgende Datenbanken von vb 2008 Express gelesen werden können.
Access: (*.mdb)
MySQL mit einem ODBC-Treiber
MS SQL Server 2005
FoxPro VFP
Oracle
Paradox
Visual FoxPro
Zusätzlich lese ich, dass es auch eine Datenbankmöglich auf der Grundlage einer csv-Datei gibt.
Das ist mir neu.
Da muss ich mal näher nachschauen.
Gruß
Jürgen
Jürgen