Xbase++ maximal ?

[AUGE_OHR]

hi,

Es heist doch

DBFDBE (DATA-Komponente)
...
Max. Anzahl Felder Nicht limitiert

hm ... hat das jemand schon mal ausprobiert

CDXDBE (ORDER Komponente)
...
Indizes pro Datei Nicht begrenzt

und genau so viele Index "Tag"s ?

Workspace Ein Workspace in jedem Thread
|
|- Workarea Maximal 65000 Workareas pro Workspace

hm ... was ist euer "Maximum" was ihr habt ?

wenn man also wirklich 65000 DBF a 2GB und 65000 CDX aufmachen "würde", was wird dann die "grösste Bremse" in einem solchen System werden ?

[Martin Altmann]

Moin Jimmy,
Du immer mit Deinen "philosophischen" Fragen!
Schon mal was von Filehandles und damit Ressourcen gehört
Du wirst es unter einem heute aktuellen OS, auf dem Xbase++ läuft, nicht schaffen, so viele Dateien zu öffnen.

Viele Grüße,
Martin

[AUGE_OHR]

Du immer mit Deinen "philosophischen" Fragen!

Nein, diesmal geht es um eine Entscheidung und es sind tatsächlich Dimensionen die ich (noch) nicht kenne.

Schon mal was von Filehandles und damit Ressourcen gehört
Du wirst es unter einem heute aktuellen OS, auf dem Xbase++ läuft, nicht schaffen, so viele Dateien zu öffnen.

das mit den File Handle "könnte" man ja mit "Max. Anzahl Felder Nicht limitiert" minimieren wenn man wüsste wie das "wirkt".
kann man wirklich 500 FELDer oder mehr mit Xbase++ "verwalten" ?
funktionieren 500 "TAG"s oder mehr in einer CDX Index Datei ?

Die DBF wäre ja nur 1 Handle und die CDX ebenfalls, da "müssten" doch 500/500 DBF/CDX auf einem 64bit OS() noch "drin" sein ?
Die Frage ist aber was bei 2K/2K DBF/CDX dann wäre ? Wie "weit" kommt den ADS ?

"SET RELATION" ist auch das Thema, wieviele DBF kann man den "tatsächlich" als 1:n verwenden ?
10 RELATION kann man ja durchaus verwenden, aber geht das auch mit 100 "wirklich" ?

deshalb meine Frage

hm ... was ist euer "Maximum" was ihr habt ?

p.s. Arctica ist in meine Überlegung nicht einbezogen weil "zeitlich" nicht "planbar"

[Martin Altmann]

Hallo Jimmy,

kann man wirklich 500 FELDer oder mehr mit Xbase++ "verwalten" ?

meine "dickste" DBF hat 649 Felder.

Die DBF wäre ja nur 1 Handle und die CDX ebenfalls, da "müssten" doch 500/500 DBF/CDX auf einem 64bit OS() noch "drin" sein ?

Oben fragtest Du jedoch nach:

wenn man also wirklich 65000 DBF a 2GB und 65000 CDX aufmachen "würde", was wird dann die "grösste Bremse" in einem solchen System werden ?

Und 65000 ist ein bisschen was anderes, als 500.
Aber trotzdem brauchst Du ein wenig mehr handles als einen pro DBF und einen pro CDX

Viele Grüße,
Martin

[Koverhage]

Jimmy,

meine größte DBF hat 513 Fleder, Satz hat 4317 Bytes.
Der Nachteil ist: Mit dbu(p) kannst Du diese Datei im Browser darstellen, bei DBFEDITOR
sieht man nicht alle Felder (habe mich noch nicht darum gekümmert, ob man das ändern kann)
Bei den reinen Dateioperationen gibt es keine Probleme, nur beim Browsen der Tabelle.

[brandelh]

Hallo,

die maximale Feldanzahl je DBF habe ich auch noch nicht ausprobiert, aber schon unter Clipper waren mehr als 1000 erlaubt (soweit ich mich erinnere).
Das Problem sind die 2 GB (oder 4GB) Gesamtdateigröße. Denn diese geteilt durch die Satzlänge ergibt die maximale Satzanzahl.
Dass die Handles in einem 32 Bit System ein Problem darstellen glaube ich nicht, denn die dürften ein LONG INT Datentyp sein.

DAS Problem was ich sehe sind eindeutig die Probleme mit vielen offenen Indexdateien und Relationen.
Eine Bewegung in einer der führenden Dateien zieht dann einen Rattenschwanz an Festplattenzugriffen nach sich, um die abhängigen Dateien zu syncronisieren.
JEDER PC der abstürzt reist zumindest theoretisch alle Indexe in den Abgrund. Der Reindex wird dann ein SPASS !

Zusätzlich stellt sich mir die Frage der Wartbarkeit und wie sind die Daten normalisiert ?
Meine größte Datei hat etwa 119 Felder, Header() = 3778, RecSize() = 1644, LastRec() = 319929.
Für eine sequenzielle Auswertung durch alle Sätze und Felder braucht mein einzelner Rechner lokal etwa 20 Minuten.
Wenn ich mir vorstelle, dass diese von z.B. 100 PCs übers Netzwerk konkurierend mit Indexen verwaltet werden soll,
da habe ich schon Zweifel ob die Performance ausreichen würde. Wenn du nun 10 oder 100 solcher Dateien mit Relationen und Indexen nimmst,
dafür wollte ich nicht den Kopf hinhalten !

Ich denke solche Dimmensionen benötigen einen sauberen Datenbankserver und einen Datenbankadministrator der sich auskennt

Aber wenn dich die max Dimmensionen interessieren, dann baue ein Testprogramm, dass Dateien mit 500, 1000, 1500 Felder etc. erstellt.
Sobald es kracht kennst du die max Feldzahl je Datei. Danach generiere 2 GB Dateien und duppliziere sie. Eine Festplatte wird mit der DBFDBE sicher
bald zu langsam sein, daher gibt es ja Datenbankserver, die ganz andere Zugriffsmöglichkeiten haben als wir im Einzelzugriff.

[Jan]

Hey Jungs,

habt Ihr schon mal was von Normalisierung gehört

Bin ich wieder fies heute...

Jan

[Manfred]

Ey Kiste,

Normalisierung schlägt nur wirklich an, wenn es um doppelte Datensatzführung geht. Also der gleiche Inhalt in mehr als einer Datei.

[brandelh]

Hey Jungs,

habt Ihr schon mal was von Normalisierung gehört

Bin ich wieder fies heute...

Jan

Hallo Jan,

hast du denn meinen Beitrag gelesen, da habe ich nachgefragt wie die normalisiert sind
Aber du kannst doch nicht einfach unterstellen dass die vielen 1000 Datei NICHT normalisiert sind

[Jan]

Gemach, gemach! Viel viele Smileys soll ich denn noch reinsetzen um die feine Ironie meiner Worte kenntlich zu machen?

Jan

[Manfred]

So viele gibt es gar nicht!

[brandelh]

Hallo Jan,

wieso feine Ironie, deine Smilies lachen uns doch richtig hönisch aus dieses hier zeigt dass ich es nicht übel genommen habe
Und an denen kannst du sehen dass es mir gut geht insbesondere nach meinem besserwisserischen Exkurs eben =D>

[AUGE_OHR]

habt Ihr schon mal was von Normalisierung gehört

ok die 65000 hatte ich nicht wirklich im Sinn ...
aber die Dimensionen und damit Problem sind durchaus "normal", der Faktor 10 war eher fiktiv

Für eine sequenzielle Auswertung durch alle Sätze und Felder braucht mein einzelner Rechner lokal etwa 20 Minuten.
Wenn ich mir vorstelle, dass diese von z.B. 100 PCs übers Netzwerk konkurierend mit Indexen verwaltet werden soll,
da habe ich schon Zweifel ob die Performance ausreichen würde. Wenn du nun 10 oder 100 solcher Dateien mit Relationen und Indexen nimmst,
dafür wollte ich nicht den Kopf hinhalten !

Ich weiss was du meinst und will das mal so beantworten : Es kommt darauf an was die User machen.

Die Leute bei der Daten Eingabe arbeiten Satz orientiert während Reports etc über eine Menge von Daten arbeitet.
Solange ich Datensatz orientiert arbeite sehe ich mit Xbase++ keine Probleme, dass ansteuern von einem Datensatz geht schnell auch 100 Relationen.
Habe ich aber eine Menge von Daten,so wird schon deren Übertragung ein Problem ... ein normales Browse kann ewig dauern... Quickbrowse kann helfen.

Nun hat Xbase++ auch Thread und bei der CPU Leistung heute "könnte" das ein Vorteil sein und bei einer Multi-Core Server CPU "könnte" man einige Sachen als "Server" laufen lassen (drucken)

selbstverständlich kommt bei solchen Überlegungen ein "anderes" Werkzeug in Betracht, aber ich wollte mal ausloten was mit Xbase++ so möglich ist ...

[brandelh]

Die Leute bei der Daten Eingabe arbeiten Satz orientiert während Reports etc über eine Menge von Daten arbeitet.
Solange ich Datensatz orientiert arbeite sehe ich mit Xbase++ keine Probleme, dass ansteuern von einem Datensatz geht schnell auch 100 Relationen.

bei einem Datensatz aus einer Datei gebe ich dir Recht, denn dazu braucht man wenige Zugriffe in der Indexdatei und dann einen im Datensatz. Bei 100 Relationen stimmt die Aussage nicht mehr, denn jetzt brauchst du 100x soviel Zugriffe für nur einen USER !
Im Netz erscheint es mir mehr als unwahrscheinlich, dass du bei der Datenmenge nur einen User hast. Gib noch mal 10 dazu und du hast soviele Zugriffe dass die Festplatte nicht mehr nachkommen kann. Zudem schreibt ja ab und zu noch einer was ...

Das meinte ich. Die Prozessorzahl des Servers spielt da keine Rolle, es sind die Platten, die Satzweise angesprochen einfach zu wenig Leistung bringen.

[AUGE_OHR]

Das meinte ich. Die Prozessorzahl des Servers spielt da keine Rolle, es sind die Platten, die Satzweise angesprochen einfach zu wenig Leistung bringen.

ok, aber das gilt doch dann für jede Datenbank Sprache, oder ?
Ob ich Xbase++ oder GL5 Application nehme, beide laufen ja dann mit der selben (langsamen) Hardware.

[brandelh]

Hallo Jimmy,

die Festplatten als solche sind ja nicht langsam, nur die Zugriffsweise in Satzlänge ist nicht mehr up to date.
Ein SQL Server verarbeitet eine Anfrage nicht Satzweise sondern intern mit Puffer und ausgeklügelter Abfragestrategie (genauer weis ich auch nicht wie).
Als Beispiel kann ich mich erinnern, dass eine do while ... Feld vergleichen ... Routine im Netzwerk (Satzweise) deutlich langsamer ist, als lokal (mit cache) und mit dbeval (bessere Strategie). Aber vor einiger Zeit wurde berichtet, dass über ODBC mit SQL Abfrage die Ergebnisse viel schneller vorlagen.

Ein SQL Server HAT immer lokale Dateien und verwaltet seinen cache selbst.
Eine Platte kann bei einfachen Leseoperationen mit großen Blöcken (Datei kopieren oder eben sinnvoll lokal lesen) 50 MByte/Sek. liefern.
Wenn man aber eine große Datei mit do while Schleife mit 128 Byte Blöcken (z.B. Recordlänge) liest, dauert das viele Minuten ...

[AUGE_OHR]

die Festplatten als solche sind ja nicht langsam, nur die Zugriffsweise in Satzlänge ist nicht mehr up to date.
...
Wenn man aber eine große Datei mit do while Schleife mit 128 Byte Blöcken (z.B. Recordlänge) liest, dauert das viele Minuten ...

ich denke es werden, bei NTFS, mindesten 4K Blöcke gelesen ... aber ich weiss was du meinst.

Ja, es ist klar Xbase++ eben Datensatz orientiert, während SQL Mengen orientiert ist und bei einer DO WHILE hätte ich ja eine Menge ...

schade das wir noch nicht über Arctica reden können, denn dann könnte man es ja effektiv "testen" wo/was Vorteile bringt.

...mit cache
...
Aber vor einiger Zeit wurde berichtet, dass über ODBC mit SQL Abfrage die Ergebnisse viel schneller vorlagen.

hatte das was mit IP6 zu tun ?
Wenn ich das im "Handbuch" des Server 2008 SBS richtig gelesen habe wird jetzt alles mögliche was "schnell" gehen soll/muss über das IP6 Protokoll gejagt.
Das ganze wird auch noch verschlüsselt und komprimiert und man kann wohl "mehrere" Streams gleichzeitig übertragen.

Es gibt Leute die sich das zu Nutze gemacht haben und somit deutlich mehr Anfragen fahren können und eine Art Cache ist im Konzept vorhanden,
ähnlich wie beim Torrent Prinzip. (Intranet und Internet)

wenn man so was als DATA Komponente mit Xbase++ fahren könnte ...
Frage : wie bekomme ich eine harbour RDD nach Xbase++ ?