Joerg on the web

(Ja, wer diesen Artikeltitel schon bei Kris gelesen hat: eine sehr ähnliche Thematik, nur halt eben nicht mysql)

Ich hatte letzte Woche den Fall, dass ich eventuell vorhandene Zeilen in einer Oracle 10g Datenbank anpasen musste; falls sie nicht vorhanden waren, mussten sie erzeugt werden. Natürlich kann man das ganze mit einem select vorab prüfen, ob das ganze da ist und dann entsprechend mit einem update oder einem insert weiterarbeiten (und nicht vergessen, das ganze in eine Transaktion zu packen). In meinem naiven jugendlichen Datenbank-Leichtsinn dachte ich mir aber, dass dieser Usecase so häufig vorkommt, dass er auch angenehmer mit Oracle-Bordmitteln gelöst werden kann.

Tut er auch. Dank ein bisschen Hilfe der Kollegen kam dann folgendes Statement

merge INTO DCS_SKU sku using ( SELECT 1 FROM dual ) ori

ON (sku.SKU_ID = 'SB1234' )

when matched then

    UPDATE SET

      sku.VERSION='1',

      sku.CREATION_DATE=TO_DATE('09/03/2010 15:59:00', 'DD/MM/YYYY HH24:MI:SS')

when NOT matched then

     INSERT(sku.SKU_ID, sku.VERSION,sku.CREATION_DATE)

      VALUES('SB1234', '1',TO_DATE('09/03/2010 15:59:00')

raus. Es prüft, ob sku.SKU_ID mit dem Wert "SB1234" bereits vorhanden ist. Wenn ja, wird entsprechend ein Update gefahren, ansonsten ein Insert.

Eigentlich nutzt man das "merge"-Statement zum Zusammenfassen von Tabellen, man kann es aber auch für diesen Zweck etwas zweckentfermden. Im Gegensatz zu Kris kenne ich mich mit Oracle zu wenig aus, um zu sagen, wo die (sicherlich vorhandenen) Fehler liegen und welche side effects man beachten muss. (Für den Usecase, bei dem ich es eingesetzt habe, war Fehlerhandling auch sehr nachrangig.) Vielleicht mag mich ja jemand aufklären

Meaningful error messages are good. Period. A lot of software badly sucks at this point. They throw "an error happened" or show a strange behaviour, but they don't say, that they cannot open a file because of missing access rights. I stress in application guidelines for java software, that every exception is getting caught and at least logged at an warning loglevel. This mechanism offers the possibility to increase the loglevel from the usual "ERROR" to something like "INFO" if we're debugging an issue.

Ich bin durch Zufall über einen wunderbaren Artikel gestolpert: Wie schreibe ich ein nicht-skalierbares Content Management System.

Es wird da allen Ernstes behauptet, das Datenbanken nur unnötige Komplexität haben und Personal brauchen, ein Filesystem dahingehend pflegeleicht und schnell sei.



Ich glaube, ich muss den Menschen mal einladen und zeigen, welche Probleme man kriegt, wenn man das Rad neu erfinden will. Wir setzen so ein filebasiertes Content Management System ein und haben sehr viel Spaß damit ...

Die allermeisten Webmaster sind an den Zugriffszahlen auf ihre Webseiten interessiert und benutzen Werkzeuge (awstats, modlogan, webalizer), die ihnen diese gewünschten Zahlen aus den Logfiles der Webserver extrahieren. Allerdings sind diese Zahlen notorisch unzuverlässig, da sie nur einen sehr kleinen Einblick gewähren, wie oft Zugriffe auf die Webseite erfolgen; interessante weitere Informationen (beispielsweise wie oft ein Benutzer auf die Webseite zugegriffen hat oder in welcher Reihenfolge er die Seiten auf der Webseite durchstreift) kann man daraus aber nicht herauslesen.

Bei der täglichen Arbeit ist mir letzthin ein Ant-Problem umgekommen, das im Kontext meines Artikels aufgetreten ist. Das Problem war, daß gewisse Properties von einem zur Ausführungszeit bestimmten Wert abhängig gemacht werden sollten; in meinem Fall war, daß IP-Adressen abhängig von dem Namen der Maschine eingetragen mussten.

wenn ihr meint, daß Euer (Web) Content Management System jede Änderung an einer Seite aufzeichnen und abspeichern soll, ist das eine gute Idee. Nicht so toll ist es allerdings, wenn alle Daten im Dateisystem liegen. Nun gut. Wenigstens habt Ihr daran gedacht, die älteren Versionen nicht in dasselbe Verzeichniss zu speichern wie die aktuelle Version; stattdessen baut ihr aus den internen IDs der Seiten (man nehme jeweils die Hashes der paar Verzeichnissnamen im logischen Pfad zu dieser Seite und hängt hintendran nochmals einen Hash über den Rest und schon hat man diese ID) einen Verzeichnissstruktur und schmeisst dort diese älteren Versionen wieder rein. So einfach, so gut.

Verschlüsselte Verbindungen sind oftmals ein Muss; sobald in irgendeiner Art vertrauliche Daten (und seien es nur Passwörter für das Einloggen auf einer bestimmten Seite), sollte man gesicherte Verbindungen benutzen.

Viele web-basierte Anwendungen prüfen deshalb, ob sie bei der Durchführung bestimmter Aktionen (beispielsweise bei der Verarbeitung persönlicher Daten) die Daten über eine verschlüsselte Verbindung erhalten. Das geht noch ziemlich einfach, wenn diese Anwendung die Verschlüsselung direkt durchführt; dann steht die Information "Diese Daten kamen über eine verschlüsselte Verbindung" nämlich direkt zur Verfügung.

Eine Versionsverwaltung kann viel Arbeit ersparen. Insbesondere entfällt das händische Versionieren (wer kennt nicht die Dateien, die aus dem eigentlichen Namen plus einem angehängten Datum bestehen), was sehr schnell unübersichtlich wird. Neben den Software-Entwicklern, aus deren Bedürfnissen sich solche Software entwickelt hat, kann man auch als Admin eine Versionsverwaltung sinnvoll einsetzen.

Das beste Beispiel: Konfigurationsdateien von Anwendungen. Diese tendieren dazu, sich im Laufe der Zeit zu verändern; wird an der Anwendung neue Funktionalität hinzugefügt, resultiert dies in Änderungen an der Konfiguration; neue Anforderungen der Umgebung benötigen geänderte Einstellungen. Hat man Gewissheit, daß die Änderung, die man durchführt, richtig ist und ein Rollback nicht notwendig sein wird, spricht nichts dagegen, direkt die Konfigurationsdateien im System zu editieren.

Schwierig wird das ganze erst, wenn man diesselbe Konfiguration auf mehreren Systemen pflegen muss; beispielsweise eine Test- und eine Produktionsumgebung oder ein Verbund mehrerer Systeme mit identischer Konfiguration. Hier kann es sich schnell zur Plage entwickeln, Konfigurationsdateien manuell synchron zu halten. Spannend wird es zudem, wenn zudem noch host- und/oder instanzspezifische Daten in der Konfiguration enthalten sein müssen. Dann nämlich wird es richtig schwierig, die Unterschiede im Auge zu behalten.

Das Not-Invented-Here-Syndrom ist eine weit verbreitete Krankheit, die insbesondere unter Softwareentwicklern grassiert.

Passt bestehende Software nicht zu 100% genau auf die eigenen Anforderungen (welche tut das schon?), wird sie einfach durch einen Eigenkreation ersetzt. Insbesondere, wenn das die eigentliche Aufgabe "trivial" ist. Sei es jetzt eine simple kleine C-Bibliothek zur Verwaltung von dynamischen Datenstrukturen (Argument dagegen: "verschwendet zuviel Platz") oder eine Monitoring-Lösung ("Ich mochte XY noch nie, und ausserdem kann man sich das mit den Plugins von XY ja problemlos selbst eine Lösung schreiben"), der gemeine Entwickler ist sich selten schade genug, das Rad neu zu erfinden, weil alle bisherigen Räder nicht die Anforderung erfüllen, die gerade spezifisch für sein Problem sind. Eine 99% Lösung zu nehmen und das restliche Prozent selbst dazuzuentwickeln kommt als Lösung auch nicht in Frage ("Dann muss ich die Patches ja bei jeder neuen Version mitziehen" oder "$Upstream/$Hersteller wird mein Patch nie akzeptieren, weil er zu spezifisch ist").

Hat man denn nun eine neue, hundertprozentige, selbstgestrickte Lösung entwickelt und nimmt sie in Betrieb, so stellt sich normalerweise sehr schnell heraus, daß diese 100 Prozent bei weitem nicht ausreichen (Stichwort: sich ändernde Umgebungsbedingungen); man hat Fehlerfälle komplett ausgeklammert oder übersehen, die einem in einem ernsthafteren Betrieb sofort auf die Nase fallen. Bei 100 Datensätzen ist die Lösung noch elegant und brauchbar, bei der tausendfachen Anzahl schläft man ein.

Bereits bestehende Software hat eine Vorteil: Es verwendet sie auch jemand anders. Und dieser jemand hat vielleicht schon diverse Fehler behoben/beheben lassen. Es besteht die Hoffnung, daß diese Lösung bereits einen Reifungsprozess hinter sich hat und man selbst nicht für diesen kompletten Prozess verantwortlich zeichnen muss.

Wiederverwendbarkeit ist das Stichwort. Sei es bei Bibliotheken oder kompletten Anwendungen. Gibt es für ein Problembereich viele Komponenten/Bibliotheken und Anwendungen, bedeutet das üblicherweise:

1. Das Feld ist extrem breit, von der Software für den Heimanwender bis zur absoluten Profianwendung.
2. Das Problem scheint so einfach zu sein, daß jeder eine eigene Lösung anbieten kann und will.

Und letztere Lösung sieht man insbesondere im Opensource-Bereich sehr viele. Angefangen bei den ähnlichen Routinen, die im C-Umfeld immer wieder neu erfunden werden (was die STL für C++ ist, gibt es für C leider nicht) und immer ihre eigenen Bugs mitbringen. Dann zu den manigfaltigen Netzwerk-Monitoring-Lösungen, die vielmals aus persönlichen Animositäten herrühren.

Habt ihr auch schon solche Software geschrieben? Und wenn ja, warum?