[Allegro] o-invent.flx
Thomas Berger
ThB at Gymel.com
Fr Feb 6 13:52:29 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lieber Herr Eversberg,
>> M.E. sollte daher auch a99 "traditionelle" Nummerngeneratoren
>> unterstuetzen, die eine in einem separaten Datensatz gespeicherte Zahl
>> simpel hochzaehlen.
>>
> Ob das mehrheitsfähig ist?
> Denkbar und vielleicht effizienter wäre es, eine simple kleine Datei
> bereitzulegen, in der die nächste Nummer steht, und die (innerhalb von
> "set lock" ... "set free" natürlich) gelesen und upgedatet würde.
>
...
>
>
> Das kann man sich einbinden wo immer nötig. Die Sache mit den
> Generatoren ist ja eine verstaubte Erfindung der früheren DOS-Versionen
> und heute entbehrlich.
> Vorsicht allerdings beim Migrieren: Die Datei nextnum.dat muß dann mit!
Datenbanken koennen im Allegemeinen gut zaehlen, und sie werden
dann eingefuehrt, wenn die Verwaltung von Einzeldateien nicht
mehr praktikabel ist. Die Auslagerung auch der Datensaetze in
Einzelfiles hatten Sie allerdings schon vor Jahren fuer eine
der naechsten Versionen angekuendigt.
Bei allegro ist es allerdings tatsaechlich so, dass das Locking
in der Datenbank tatsaechlich teurer ist als das im Dateisystem,
insofern ergibt sich die paradoxe Situation, dass die Arbeit
umso effizienter wird, je weniger man allegro einsetzt.
"Klassische Generatoren" kann ich aber auch unter a99 effizient
einsetzen, denn mit
set rec loc
...
put unlock
kann ich die Zeiten der Komplettsperre der Datenbank minimieren
(sie ist nur noch waehrend des put gesperrt, nicht mehr waehrend
der Rechnung im Flex [ich weiss allerdings nicht, wie das "set rec loc"
implementiert ist, evtl. ist es nicht einmal sauber, ausser ich habe
vorher ein explizit "set tbl lock" gegeben? das waere fatal. Oder es
sperrt kurzzeitig die komplette Datenbank mit einem impliziten "set tbl
lock"? Das waere nicht sehr effizient).
Dieses "put" waere ausserdem extrem schnell, da keine Index-
Eintraege aktualisiert werden muessen [ausser im seltenen Fall der
Umspeicherung des Datensatzes], zumindest dann, wenn man ein
Feature haette, temporaer das Aktualisieren von Datumsstempeln
abzuklemmen, zur Not geht das natuerlich mit der PV.
Overhead waere das Aufsuchen und Abspeichern des Zaehlerdatensatzes,
aber ob das wirklich ineffizienter ist als dasjenige einer separaten
Datei im Netz? Das Beispiel von Frau Panski zeigt, dass man eine
registerinduzierte Zaehlerfunktion oft auch nur um den Preis bekommt,
die zaehler-tragendenden Datensaetze einmal mehr als sonst
abzuspeichern, wobei es dann oft zur Umspeicherung kommt, die extrem
teuer sein kann.
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSYwyjWITJZieluOzAQJRigQAlhnwXNdRzTzG6gK2EizBv1nQlzlIlXbq
5eLwWAi9qdkNNpEymFxOKGtosWkTsFZ74y3qK7Ss3ek0Qz7sXFtMyX69ynOHvObS
zH3qJNDUw1FgS/6n/+Ep/Fj+9vy6fuhdQs8NjNiKALP8vRByDseoP3DAm/AitP0t
RxgJXxH/Ygk=
=Tc4E
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Allegro