<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div><br/>
Verlautbarung 279 zur allegro-Entwicklung                    2016-04-12<br/>
-----------------------------------------</div>

<div>Der Kern der Dinge : SQL or NoSQL ...<br/>
=====================================</div>

<div>"Datenbank" - dieser Begriff ist immer noch für manche Mitglieder der<br/>
Entwicklerprofession im Kern verbandelt mit dem Paradigma "Tabelle",<br/>
und das Werkzeug für den Umgang damit ist SQL. Alle Dinge der Welt,<br/>
so die ungeschriebene Übereinkunft, lassen sich damit abbilden und<br/>
informatisch handhaben. Dieses Weltbild wird jedoch zunehmend als<br/>
gußeiserne Mechanistik empfunden und der Grundkonsens gerät damit<br/>
langsam ins Wanken, auf anderen Fundamenten stehen zumindest die<br/>
Trendsetter der Suchmaschinen und der Discovery-Systeme . Man muß<br/>
nicht gleich von einem Gespenst reden, das da nun umgehe, aber es<br/>
*geht* etwas um, nicht nur in Europa, und sein Name ist NoSQL.<br/>
Das Akronym "NoSQL" benennt allerdings kein neues Paradigma mit klaren,<br/>
kantigen Konturen, sondern umschreibt eher ein Sammelbecken von<br/>
heterogenen Konzepten der Datenmodellierung samt dem Umgang damit.<br/>
Manche wollen "NoSQL" nicht wörtlich verstanden wissen, sondern deuten<br/>
es als "Not only SQL", wollen somit die Tabellen nicht gleich in Bausch<br/>
und Bogen in die Obsoleszenz entlassen, wollen ihnen aber sehr wohl die<br/>
Deutungshoheit und der SQL-Sprache das Handlungsmonopol im Kern der<br/>
Dinge absprechen. Oder anders gesagt, was die Welt im Innersten<br/>
zusammenhält, das ringt man ihr nicht ab mit Hebeln und mit Schrauben,<br/>
sondern es gibt andere Werkzeug- und andere Sprachparadigmen, die in<br/>
Ausdrucksmacht, Funktionsspektrum und Performanz dem alternden<br/>
Monopolisten zur Seite treten können und sollten und ihm gern auch hier<br/>
und da die Show stehlen. Man findet leicht viel Material:<br/>
  Mehr zum Thema: bei Google "nosql" einwerfen.<br/>
  Umfängliche Liste von Systemen: http://nosql-database.org</div>

<div>Kurzum, Tabellen bleiben in der Welt, und zwar vielerorts eben gerade<br/>
im Kern der Dinge, man sollte sich also mit ihnen rumzuschlagen wissen.<br/>
Für einen Teil der evtl. anfallenden Aufgaben haben seit Jahren schon<br/>
den Funktionsbereich "Tabellen erstellen" (h table, ausführlicher<br/>
erklärt in  h tablh).<br/>
Was aber auch gelegentlich vorkommt und damit noch nicht abgehandelt<br/>
ist, das ist der Import von Fremdtabellen, d.h. die Umwandlung von<br/>
aus SQL-Systemen stammenden Daten in allegro-Daten. In der Sprache des<br/>
Handbuchs (Kap. 11.2 oder h ac11-1) sind das Fremddaten vom Typ B,<br/>
"Sätze mit fester Feldanzahl". Mit Import wird das ja schon längst oft<br/>
praktiziert, doch es ist manchmal recht mühsam, und wer kennt sich<br/>
schon heute noch aus mit der Importsprache? Mit FLEX ist es bisher eher<br/>
noch kniffliger.<br/>
Dagegen läßt sich einiges tun!</div>

<div>Konkret sieht das so aus:<br/>
Ein SQL-System kann i.a.R. eine Tabelle in Textgestalt so exportieren:</div>

<div>Feldname1TABFeldname2TABFeldname3<br/>
Inhalt1-1TABInhalt1-2TABInhalt1-3<br/>
Inhalt2-1TABInhalt2-2TABInhalt3-3<br/>
usw.</div>

<div>Dabei ist TAB der Code 09, und ein Inhalt kann, aber muß nicht, in ".."<br/>
eingeschlossen sein, was bei textuellen Inhalten oft so gemacht wird.<br/>
(Wie ein zum Inhalt gehöriges " zu codieren ist, das zwar nicht streng<br/>
standardisiert; oft wird es schlicht verdoppelt.)<br/>
Mehr:  https://de.wikipedia.org/wiki/CSV_(Dateiformat)</div>

<div> <br/>
Ein neuer Job für acon wurde geschrieben:  sqltr.job (SQL table read).<br/>
Er enthält das gesamte Rahmenwerk, um leicht eine SQL-Tabelle der<br/>
genannten Form in allegro-Daten zu wandeln, aber zuerst einmal eine<br/>
numerierte Liste der Felder auszugeben, mit der sich dann leicht<br/>
umgehen läßt, um die gewünschten Felder in geeigneter Form in<br/>
allegro-Felder zu überführen. Dazu ist dann innerhalb von sqltr.job<br/>
ein eigener Abschnitt zu schreiben, aber mehr eben auch nicht, und<br/>
am Beispiel sieht man, wie's geht. Der Job ist ansonsten angemessen<br/>
kommentiert (*** an den zu beachtenden Stellen). Schnell besorgen:</div>

<div>   X gf sqltr.job</div>

<div>Mit  acon -j sqltr -h  bekommt man kurz die Optionen eklärt.<br/>
Hat man nun eine Tabellendatei der besagten Struktur namens xyz.cvs,<br/>
dann gibt man mal ein:</div>

<div>  acon -j sqltr -nxyz.cvs -ff     bzw.  -Test  statt -ff<br/>
um die Liste der Felder zu erhalten, bzw. mit -Test die ersten 5 Felder<br/>
jedes Satzes angezeigt zu kriegen.<br/>
Mit Option -ff entsteht eine Datei  xyz.fl  mit der Feldliste.<br/>
Ohne die Option -ff wird eine Datei  xyz.adt  erstellt. Die wird aber<br/>
nur was taugen, wenn man vorher in  sqltr.job  den Abschnitt unter<br/>
diesen Zeilen:</div>

<div>:vl<br/>
// *** Echtmodus: Auswertung</div>

<div>geeignet bearbeitet. Dazu braucht man die Feldliste, aus den Beispiel-<br/>
zeilen ersieht man, wie damit umzugehen ist. Die einzelnen Felder<br/>
stehen zur Laufzeit dann in $f1, ... $f57, wenn z.B. 57 die Anzahl<br/>
der Tabellenspalten ist. Was man damit macht, dem setzt nur die<br/>
FLEX-Sprache Grenzen.<br/>
Der Zeichencode wird von ANSI (gibt SQL normalerweise aus) in ASCII<br/>
gewandelt. Das ließe sich natürlich noch flexibilisieren und<br/>
optionieren. (Hinweise im Kommentar)</div>

<div> </div>

<div> </div>
</div></div></body></html>