[Allegro] Hochfrequente Mehrfachfelder : Neue Lösung gesucht

[Bernhard Eversberg]

Am 19.06.2014 16:33, schrieb Thomas Berger:
>>
>> und statt 2 und 3 kann es auch lauten 0 und 1 oder 1 und 9 oder
>> a und b oder X und Y usw. - Die Zeichen müssen nur eindeutig sein,
>> d.h. zweimal #40a in einem Satz geht nicht.
>
> Ich denke, das ist die Stelle, an der angesetzt werden muss:
> Die Mehrfachcodes muessen weg!
>
Zuzugeben ist: Die allegro-Mehrfachmethodik ist eigenwillig und folgt
keinem Standard. Allerdings gibt es auch keinen, der explizit
durchdacht wäre. MARC und Pica (und teilweise MAB) wiederholen schlicht
die Nummer. Auch XML-Schemata haben eine schlichte Wiederholtechnik
ohne individualisierende Kennzeichnung der einzelnen Feldinhalte.
So etwas geht bei der internen Technik der Satzverwaltung in
allegro nicht, sondern jedes Feld braucht seine Identität, und sie
liegt nicht einfach in der Position innerhalb einer Folge von Feldern
mit gleicher Nummer, sondern sie liegt in dem Zeichen direkt hinter
der Feldnummer. Dies grundsätzlich zu ändern würde einen nicht
unbeträchtlichen Änderungsaufwand innerhalb der Programme bedeuten.
Zu ändern wäre zum einen auch die Felddefinition der CFG, oder doch
deren Interpretation durch die Programme, zum andern kann es
vielfältige Aus- und Nebenwirkungen, die zu Änderungen zwängen, auch
in den Parametern und FLEXen geben, in denen mit Mehrfachfeldern
gearbeitet wird.

> Beim Speichern in der Datenbank braucht man sie nicht, beim
> Einlesen eines Datensatzes kann man fuer die interne Verarbeitung
> ja mitzaehlen:...

Das ist leicht gesagt! Wieder mal liegt einem das Wallenstein-Zitat auf
der Zunge, weil solche Äußerungen schnell Begehrlichkeiten wecken, die,
wenn wir sie nicht erfüllen können, dann uns als Versagen oder Faulheit
angelastet werden, statt dem Forderungssteller den Nachweis
abzuverlangen, daß und wie es denn machbar sei.

Wir bleiben lieber bei dem Grundsatz, nichts zu versprechen, wenn wir
nicht sicher sind, es halten zu können. In diesem Fall sind wir es,
und nachgedacht worden ist darüber ja schon oft genug, eben nicht.
Uns ist beim besten Willen keine mit darstellbarem Aufwand zu
realisierende Lösung vorstellbar, die Bergers Vorstellungen entspräche,
aber für CFG, Parameter und FLEXe änderungsneutral wäre.

Zunächst einmal müssen und können wir uns nur auf die Unicodisierung
konzentrieren, und das geht nicht in einem Rundumschlag, der das ganze
Umfeld der mit einem implementierten System verbundenen Dateien
automatisch mit erledigen würde. Es kann erst einmal nur darum gehen,
den Umstieg so einfach wie möglich zu machen, sonst machen es am
Ende nur sehr wenige mit und wir kriegen ein Zweiklassensystem. Dafür
gibt es Beispiele genug, man braucht keine Namen zu nennen, und jeder
weiß, wie unerfreulich das ist.

Was Berger *eigentlich* will, das ist ein neues System, das nicht nur
an dieser Stelle bessere Eigenschaften hätte, sondern an sehr vielen
anderen Stellen auch. Das wird auch kommen, aber woher, das weiß im
Moment noch keiner. Dann braucht's nur noch  einen "Migrationspfad",
und das ganze Gerümpel der Parameter etc. kann in den Schrott. So ist
doch der Lauf der Welt, oder nicht?
Im Kontext eines existierenden und vielfältig eingesetzten Systems aber,
das läuft und das weiterlaufen soll, da kann man nur vorsichtig
operieren. Es gibt neuerdings das Konzept des "Incremental Commitment
Spiral Model", demzufolge man den Fortschritt nicht als einen 
Gewaltsprung, sondern als Folge kleiner Schritte in die richtige
Richtung verstehen sollte, die jeweils überschaubar sind und
konkret durchführbar aber auch jeweils einen Vorteil bringen.

B.E.