der Unterschied zwischen sequentieller und paralleler Datenverarbeitung ... for Dummies

In diesem Video wird leicht verständlich erklärt, worin der Unterschied zwischen sequentieller und paralleler Datenverarbeitung besteht (Marketinggag für eine Grafikkarte).
Und zwar mit einem 1100(!)-läufigen Paintballmarkierer. check it.



via [HackADay]

XML, XSL, XPath

Ich bearbeite gerade mein erstes Datenbankprojekt, das XML beinhaltet. Sehr spannend.

Ziel soll es sein, eine WHERE Klausel für einen SQL-String als XML-Dokument zu erstellen, dieses in einem TreeView-Steuerelement darzustellen und später die Klausel aus dem XML-File zu generieren.
Als schwierig stellt sich momentan heraus, in dem Treeview nur bestimmte Elemente des XML-Files darzustellen. Logischwerweise möchte ich in dem TreeView nur für Endanwender angenehm zu lesende Kriterien wie "Geburtsdatum größer gleich 1.1.1980" stehen haben anstatt tblKandidaten.DOB >= '#1980-01-01'.
Das XML-File enthält also für Klauseln (Verknüpfung der darunterliegenden Elemente mit AND oder OR) und die Kriterien ([Tabelle].[Feld] [operator] [Wert]) jeweils 2 Felder: Anzeigetext und SQL-Code. Angezeigt werden soll logischerweise nur der Anzeigetext.

Das gestaltet sich gar nicht so einfach, wie es sich möglichwerweise anhört. Seit dem MSXML3 gibt es die Möglichkeit XPath auf das Dokument anzuwenden, quasi eine Abfragesprache für das Dokument. Das Ergebnis ist allerdings eine flache Liste, die Hierarchie ist dahin. Man müsste also rekursiv jede Ebene einzeln nach den gesuchen Elementen abfragen und das TreeView füllen.

Hat bisher noch nicht geklappt, diverse kleine Stolpersteine verhindern den Erfolg.
Eine wietere Möglichkeit, die sich nach Lektüre diverser Internetseiten aufgetan hat, ist das XML-Dokument mithilfe von XSLT in eine weiteres XML-Dokument zu transformieren, dass nur die gewünschten Elemente enthält und damit ganz einfach angezeigt werden kann.

eine Lösung steht noch an. Der usenet-thread zu dem Thema ist hier zu finden.

EXISTS vs. IN

Ich hatte hier eine Abfrage in einer gespeicherten Prozedur nach dem Schema

INSERT INTO Tabelle1
SELECT DISTINCT Spalte1, Spalte2, Spalte3
FROM Tabelle 2
WHERE Spalte3 NOT IN
(SELECT Spalte3b FROM Tabelle1);

Also nimm alle Datensätze aus Tabelle2, deren Spalte3 keine Entsprechung in Spalte3b der Tabelle1 hat und füge diese in die Tabelle 1 ein. Also um sicher zu stellen, dass jeder Datensatz nur ein mal in Tabelle 1 eingefügt wird. Hat bisher prima funktioniert. Nur heute war das einzufügende Resultset leer, obwohl nachweislich Daten da waren, die das Kriterium erfüllten.

Rätsel, Rätsel, Recherchier, Recherchier und siehe da: Die gute alte NULL war mal wieder schuld an allem. Ist in dem Resultset der Unterabfrage (SELECT Spalte3b FROM Tabelle2) eine NULL enthalten, so führt das zum "dritten" Booleanwert unknown, weshalb die gesamte Bedingung falsch wird.
Besser man nutzt EXISTS, was die NULL-Werte ignoriert:


INSERT INTO Tabelle1
SELECT DISTINCT Spalte1, Spalte2, Spalte3
FROM Tabelle2
WHERE NOT EXISTS
(SELECT * FROM Tabelle1 WHERE Tabelle1.Spalte3b = Tabelle2.Spalte3);

et voila!

entsprechender Thread bei theScripts