Alle Artikel zu #datenbank


Veraltete Datenbank-Backups löschen

Dank des Perl-Skripts von MySQLDumper laufen Datenbank-Backups bei mir vollautomatisch. Mit der Funktion des regelmäßigen Aufräumens war ich aber nicht ganz zufrieden. Ich wollte gerne, dass immer die zehn neuesten Backups behalten werden und von den älteren nur noch eins pro Woche. Das geht mit folgendem Bash-Skript:

#!/bin/bash # Get all konzertheld backup files reverse ordered (konzertheld_yyyy_mm_dd_hh_mm.sql.gz) FILES=`ls konzertheld_* -r` # Initiate i=0 LWNR=0 # Go for f in $FILES do i=`expr $i + 1` # skip first 10 backups if [ $i -gt 10 ] then # Get the database name by extracting the substring before the position of the first _ # echo ${f:0:`expr index "$f" _`-1} # Get the date part by extracting a 10 long substring from the position after the first _ DATUM=${f:`expr index "$f" _`:10} DATUM=${DATUM//_/-} # Get week number WNR=`date +%V -d $DATUM` # If we already had that week number this is an older backup from that week. Delete it! if [ $LWNR -eq $WNR ] then echo $f fi # Set the last week number to the current one. So if the next backup is from a different week it will be kept, if not, deleted. LWNR=$WNR fi done

So werden von den älteren immer alle bis auf eines aus einer Woche gelöscht. Wenn man nur automatisiert backupt, kann man das natürlich auch ohne die Wochennummer machen und einfach jedes siebte Ei jede siebte Datei löschen, aber mit der obigen Methode werden auch alte Backups gelöscht, die man mal manuell angelegt hat. So wie ich an Tagen, an denen alle zehn Minuten die Datenbank explodieren könnte, so dass ich ständig Backups anstoße...



Zahlen & Umbauten

Wieder mal ein paar Updates am Blog.
Content

  • Die Themensuche ist in einer verbesserten Version fertig gestellt. Über der Titelzeile neben den Kategorien ist jetzt das Thema zu sehen (anklickbar), in der Vollansicht gibt es unter dem Post einen Link. Die Themensuche ist jetzt noch präziser und findet nun endgültig nur noch Artikel, die von mir als zu dem selben Thema gehörig gekennzeichnet wurden. Dafür musste ich das Trennzeichen nach | ändern, da Leerzeichen zu einer Oder-Suche führen und Unterstriche als Leerzeichen behandelt werden...
  • Das Titel-Tag [blog] ist rausgeflogen, ich habe nun eine eigene Kategorie für Posts, die den Blog betreffen eingeführt. Sie heißt Blog. Total kreativ, ich weiß.
  • Irgendwann letztens habe ich wohl mal den 200. Artikel veröffentlicht, es müsste der Vorab-Post zu den Kirchentagsberichten sein, aber aus irgendwelchen Gründen hat Wordpress zwischendurch mal die Zählung geändert und ich hatte 201 Artikel statt 200, obwohl ich gar keinen veröffentlicht habe. 8O
  • Ein paar Verbesserungen am Quellcode, um die Validität zu erhöhen. Wenn mir einer den Fehler nennt, der jetzt noch auftrittt... *kopfschüttel* Was unterscheidet diesen Link <a href="http://www.stepmania.com/" class="extern" target="_blank">Seite</a> von diesem <a class="extern" href="http://de.wikipedia.org/wiki/Tanzmatte" target="_blank">Wikipedia</a> außer der Ziel-URL? Richtig: Der zweite wird vom Validator als falsch angestrichen. :wall: (es ist nicht immer dieser, aber immer irgendeiner im Dokument - aber nur einer! Angeblich existiert bei diesem einen dann das Attribut target nicht.)

Backend & Datenbank

  • Es werden nicht mehr alle Überarbeitungen gespeichert, sondern nur die neusten zwei. Eigentlich brauche ich diese Funktion gar nicht, aber sie gibt irgendwie Sicherheit... Wie das geht, habe ich hier gefunden: Quelle
  • Die alten Artikelversionen habe ich dann direkt mal alle gelöscht, dadurch ist die Datenbank um 196 Artikel ärmer. Schöne Entlastung.

Schimpfen auf Wordpress

  • Das Wordpress-Tag "code" formatiert Code nur so, dass er wie Code aussieht, zeigt aber tatsächlichen Code nicht an. Sprich, Links bleiben Links und werden nicht als Quellcode dargestellt. Das da oben ist also ein Misch aus "code" und eigenem Gefrickel.
  • Wenn ich einen Artikel anfange und speichere am Tag x und dann später am Tag y fertig stelle und veröffentliche, ist das Veröffentlichungsdatum nicht Tag y, sondern Tag x. Sprich, irgendwann angefangene Artikel befinden sich nach dem Publizieren nicht oben. -.-


Wordpress Standard-Kategorie ändern

Für den Beitrag über Burger King-Gutscheine habe ich QuickPress* verwenden wollen. Allerdings sollte der Beitrag nach "Kurz notiert". Da das eigentlich eh die Kategorie ist, die ich verwenden würde, wenn ich Beiträge aus QuickPress direkt publiziere, bietet es sich ja an die als Standard zu verwenden.

  1. Wieso kann man eigentlich die Kategorie bei QuickPress nicht angeben?
  2. Wieso kann man die Standardkategorie nicht ändern?

Antwort auf 2.: Weil es einfach die Kategorie ist, die zuerst angelegt wurde. In der Wordpress-Datenbank werden Kategorien, Tags, Link-Kategorien usw. als "terms" gespeichert und in einer zweiten Tabelle wird deren Abhängigkeit ("term taxonomy") gespeichert. Eigentlich eine clevere Idee, nur leider werden so einfache Dinge wie Ändern der Standardkategorie dadurch erschwert.

Lösung: IDs der alten und der neuen Standardkategorie tauschen, danach die "taxonomy" von Hand anpassen (die neue Standardkategorie hat jetzt die Unterkategorien der alten). Funktioniert. hahahah

* QuickPress ist ein in Wordpress 2.7 neues Feature, mit dem man von der Admin-Startseite (Dashboard) direkt einen Artikel schreiben und veröffentlichen kann. Dabei kann man aber nur einen Titel und Tags angeben und als "Editor" bekommt man nur eine Textbox.



Datenbankzugriffe beschleunigen in Visual Basic

Seit ich bei E.ON den Programmcodeblock zum Update der Datenbank geschrieben habe, stört mich die irre lange Ausführungszeit. Es geht dabei darum, von ca 300.000 Datensätzen anhand zweier Felder zu prüfen, ob sie bereits in der Datenbank sind, und ggf. Ergänzungen vorzunehmen. Beide Felder enthalten numerische Werte.

Bisher habe ich dazu ein Recordset geladen, was alle Datensätze in der Tabelle enthält, und dann eine Schleife geschrieben die alle eventuell zu ergänzenden Datensätze durchläuft. Darin wurde dann jedesmal ein Filter auf das Recordset gesetzt, und entweder blieb dann genau ein Datensatz über oder keiner, wenn's keiner war, musste ich den ergänzen. Das hat natürlich immer ewig gedauert, so etwa 1,5h, denn je nachdem wie intelligent Access da arbeitet, waren das 300.000 Durchläufe - für jeden der 300.000 Datensätze.

Jetzt habe ich einfach mal, in der Hoffnung den Vorgang vielleicht wenigstens auf ein Drittel reduzieren zu können, eine ganz andere Methode gewählt: Ich erstelle ein zweidimensionales Boolean-Array (für jedes Feld eine Dimension) mit den minimalen und maximalen Werten der Fehler als Grenzen (... To ..., ... To ... mit ReDim, Dim lässt da nur konstante Werte zu, meine sind aber dynamisch, da es sich um IDs einer anderen Datenbanktabelle handelt). Dann durchlaufe ich das Recordset, bei dem ich vorher immer den Filter setzen musste, einmal komplett und setze dabei im Array alle Felder, die durch das Recordset angegeben werden, auf true (meinarray (rs("feld1"), rs("feld2")) = true). So erhalte ich ein Array, in dem die vorhandenen Felder markiert sind.

Das Recordset wird jetzt schon nicht mehr benötigt. Der nächste Schritt durchläuft alle möglichen Werte für die beiden Felder (verschachtelte Schleife) und prüft dabei, ob der Wert im Array an der gerade durch die Schleifen gegebenen Stelle false ist. Falls ja, wird das Wertepaar in der Datenbank ergänzt. Dadurch, dass das Array vom minimalen zum maximalen Wert der Felder dimensioniert ist, gibt es, wenn die Tabelle, der die IDs entstammen, nicht durchgehend ist (Datensätze gelöscht...), mehr Positionen im Array als abgefragt werden, die dann auch auf false stehen. Macht aber nix, da die Schleife, in der die Ergänzungen vorgenommen werden, mit den tatsächlich eingetragenen Werten arbeitet und so keine IDs eingetragen werden, die es gar nicht mehr gibt.

Ergebnis: Statt 1,5 Stunden dauert der Vorgang jetzt vielleicht noch 20 Sekunden... Hätte nicht gedacht, dass es SO ineffizient ist, mit einem Recordset zu arbeiten. Anscheinend wird doch keine Kopie im Programm angelegt, sondern immer direkt auf die Datenbank zugegriffen.

Was vielleicht noch anzumerken ist, wäre die Tatsache, dass ich beim Anlegen des Recordsets nebenbei den Zugriffsmodus auf "adLockBatchOptmistic" gesetzt habe, was sich vom Namen her passender anhört als "adLockReadOnly", welches ich zuvor verwendet hatte. Die Beschreibung sagte was anderes, deshalb hab ich das zuvor nicht benutzt. Was genau jetzt den größeren Geschwindigkeitsvorteil ausgemacht hat, weiß ich nicht, ist mir aber eigentlich auch egal :D