See what is actually stored beneath your tables

Früher oder später kommt eine Frage, die SQL nicht beantworten kann. Eine Zeile existiert im Global, aber die Class Query liefert sie nicht zurück. Eine Property liest sich über die Objektschicht als null, während die Daten sichtbar da sind. Eine Legacy-Routine hat vor zwanzig Jahren direkt in den Storage geschrieben und niemand erinnert sich mehr an das Format. An diesem Punkt muss man den Global selbst ansehen, und die üblichen Optionen sind eine Terminal-Session mit ZWRITE oder jemanden mit Server-Zugriff zu bitten, das zu tun.

Warum Globals wichtig sind, auch wenn man nur SQL schreibt

Jedes Datenelement in einer InterSystems IRIS Datenbank wird in einem effizienten, baumbasierten, dünn besetzten mehrdimensionalen Array gespeichert — einem Global. Globals bilden die Grundlage sowohl der Objekt- als auch der SQL-Schnittstelle der Plattform: ein Datenkatalog, erreichbar als Tabellen, als Objekte, als mehrdimensionale Arrays oder als Dokumente, alles ruhend auf demselben Storage. Man muss nie direkt mit ihnen arbeiten, aber das Verständnis, wie IRIS sie verwendet, verwandelt ein unerklärliches Ergebnis in eine Diagnose.

Daten können in einem Global unter beliebig vielen Subscripts gespeichert werden, und Subscripts sind typlos. Ein Subscript auf einer bestimmten Ebene könnte die Zahl 34 sein, während sein Nachbar auf derselben Ebene der String "LineItems" ist. Eine Lagerbestandsanwendung für Artikel, Größe, Farbe und Muster könnte so aufgebaut sein:

^Stock(item,size,color,pattern) = quantity

mit Daten wie:

^Stock("slip dress",4,"blue","floral") = 3

Diese Flexibilität ist genau der Grund, warum generische SQL-Clients hier nichts anzeigen können: Es gibt keine feste Zeilen- und Spaltenform zum Rendern. Der Global Browser rendert stattdessen den Baum.

Navigation durch den Baum

Globals in einem Namespace werden als Ordner im Server Navigator aufgeführt, mit genauer Item-Anzahl, und expandieren Ebene für Ebene. Man steigt ein Subscript nach dem anderen ab, sieht die Subscripts, die auf jeder Ebene tatsächlich existieren, anstatt einen Bereich zu erraten, und der Wert an jedem Knoten wird angezeigt, sobald man ihn auswählt. Der Subscript-Pfad wird in einer Form angezeigt, die man direkt in ein Terminal oder in ObjectScript kopieren kann, sodass das, was man im Browser gefunden hat, anderswo reproduzierbar ist.

Da Subscript-Ebenen Datentypen auf derselben Ebene mischen können, sortiert und zeigt der Browser numerische und String-Subscripts nebeneinander an, ohne das eine in das andere zu kollabieren — ein Fall, der früher falsch behandelt wurde und jetzt explizit ist.

$LISTBUILD-Werte, aufgelöst

IRIS und Caché speichern die Properties eines Objekts in einer kompakten binären Darstellung, die mit $LISTBUILD gebaut wird, sodass ein einzelner Global-Knoten typischerweise eine ganze Zeile enthält. Roh ausgegeben ist dieser Knoten eine Folge nicht druckbarer Bytes mit gelegentlich erkennbaren Strings darin. Der Global Browser dekodiert die Liste und zeigt die Elemente als einzelne, nummerierte Felder, die man dann mit der Storage-Definition der Klasse abgleichen kann, um zu sehen, welche Property in welcher Position sitzt.

Das ist das Nützlichste, was das Tool mit Globals macht. So bestätigt man, dass der Wert tatsächlich in Slot 7 steht, die Klasse ihn aber in Slot 8 erwartet, oder dass eine Property als String geschrieben wurde, wo die Storage-Definition Integer sagt.

Wenn die Daten nicht sind, was sie vorgeben zu sein

Legacy-Systeme, die die SQL- und Objektschichten umgehen, führen zu Fehlern, die von oben schwer zu sehen sind: Werte, die überhaupt nicht gelesen werden können, Werte, die gültig aussehen, aber nicht den Metadaten entsprechen, und Werte, die stillschweigend angepasst werden, um einem erwarteten Typ zu entsprechen. Der Global Browser ist darüber absichtlich ehrlich. Wenn man ihn bittet, einen Knoten als $LISTBUILD zu interpretieren, und der Knoten nicht in diesem Format vorliegt, sagt er, dass das Format ungültig ist, und zeigt, was tatsächlich dort ist, anstatt plausiblen Unsinn zu rendern oder mit einem Stack Trace zu versagen.

Dieses Verhalten passt zur Fehlerbehandlung beim Lesen im SQL-Editor: Der Editor findet die Zeile und Spalte eines Werts, der nicht seinen Metadaten entspricht, und der Global Browser sagt, was dort gespeichert ist.

Von der Tabelle zum Storage und zurück

Der Weg zu einem Global beginnt meist bei einer Tabelle. Die IRIS-Storage- und Index-Tabs des Table Viewer nennen die Globals, in denen eine Tabelle und ihre Indizes tatsächlich leben, zusammen mit ihren Größen, sodass man von „diese Tabelle ist 14 GB" zum spezifischen Global, der sie hält, gehen kann, und dann hier in diesen Global einsteigen. In die andere Richtung zu arbeiten ist genauso üblich: einen verwaisten Subscript im Browser finden, dann zurück zu SQL gehen, um herauszufinden, welche Anwendung ihn geschrieben hat.

Größen sind auf diesem Weg beachtenswert. Eine Tabelle, deren Index-Globals größer geworden sind als ihr Daten-Global, ist meist eine Geschichte über einen redundanten Index, und das ist eine Frage für die Performance-Tools.

Die Fähigkeit, den eigenen Storage lesen zu können, verändert, wie schnell seltsame Daten erklärt werden — ein zehnminütiger Blick statt eines Tickets an denjenigen, der Terminal-Zugriff hat. Der Global Browser ist in jeder Edition enthalten, auch in der Free Edition. SQL DATA LENS herunterladen und einen Global auf einem Test-Namespace öffnen, um zu sehen, wie Ihre Tabellen darunter wirklich aussehen.