Archiv der Kategorie: Plauderei

Beitragskategorien aus der Datenbank abfassen

Für Spitzenklöppler: das WordPress-Kategorienmodell

Um an die Beitragskategorien heranzukommen, muss man sich mit sage und schreibe 5 Tabellen herumschlagen. Das kommt daher, weil die WordPress-Entwickler das Kategorienmodell unbedingt mehrstufig anlegen mussten. Das ist zwar wunderbar verschachtelbar und ergibt ganz eindrucksvolle Baumstrukturen, aber datenverarbeitungstechnisch ist es meiner Meinung nach mit Kanonen auf Spatzen geschossen. Mit einer winzigen Ausnahme (die Backrezepte im Inselfisch-Kochbuch) habe ich noch in keinem meiner Blogs eine Unterkategorien-Ebene gebraucht, und damit das hier nicht allzu unübersichtlich wird, lasse ich es auch bei der einen Ebene. Haben sie ein bißchen Zeit? dann wollen wir mal.

Die relevanten Tabellen

Erstens natürlich die wp_posts, aus der holen wir uns die ID, also den Primärschlüssel der Beiträge. Dann brauchen wir noch:

  • wp_term_relationships
  • wp_term_taxonomy
  • wp_terms
  • (wp_termmeta, nein, die brauchen wir nicht, nur der Vollständigkeit halber erwähnt)

Warum das ganze mit Term und nicht mit Category bezeichnet ist: rein theoretisch kann man sich auch noch eigene Taxonomien anlegen, die dann eben nicht Kategorie heissen sondern einen eigenen Namen kriegen. Sowas hab ich anno Dunnerkeil mal in meinem Bilderblog gemacht, da gabs eine eigene Taxonomie „Jahreszeiten“, die bestand aus genau vier Einträgen, nämlich „Frühling, Sommer, Herbst, Winter“. Bin ich wieder davon abgekommen, ich hab die Jahreszeiten einfach in die erste Kategorieebene mit aufgenommen, geht auch und ist wesentlich einfacher zu verwalten. Aber das nur am Rande bemerkt, wir holen uns die Tabellen jetzt mal ins Access rein und basteln uns die nötigen Verknüpfungen.

Das Datenmodell im Detail

Die ersten beiden Tabellen: wp_term_relationships und wp_posts

Wichtig ist hier erstens die object_id, das ist die ID des Beitrags aus der wp_posts. Einem Beitrag können ja mehrere Kategorien zugeordnet sein, deshalb tauchen die IDs hier auch mehrfach auf. Die term_taxonomy_id verweist auf die Kategorie. Die term_order könnte man für eine benutzerdefinierte Sortierung der Kategorien verwenden, aber das geht jetzt zu weit, das lassen wir weg.

screenshot_term_relationships

screenshot_term_relationships

Wir basteln uns also die erste Verknüpfung mit der object_id auf die wp_posts.

screenshot_beziehnungen_posts_relationships

screenshot_beziehnungen_posts_relationships

Die dritte Tabelle: wp_terms_taxonomy

Hier wird es schon ein bißchen undurchsichtiger. Die ersten drei Felder ID, term_taxonomy_id und term_id haben alle den selben Wert, da kann man nur raten wofür welches gut ist. Da wir nur die term_taxonomy_id aus der wp_term_relationships eindeutig zuordnen können, nehmen wir die halt, und merken uns als Hauptschlüssel die ID. Im Feld taxonomy steht immer der Wert category, wir haben ja nur diese eine Taxonomie, das können wir auch weglassen. Interessanter wäre da noch das Feld „parent“, das die übergeordnete Kategorie im Falle verschachtelter Kategorieebenen enthält, aber auch das lassen wir mal aussen vor, sonst blickt hier kein Schwein mehr durch.

Kleine Kuriosität am Rande: hier wird ein count mitgeführt, der die Anzahl der Beträge zu einer Kategorie wiederspiegelt. Kann man das nicht nachher im Rahmen einer Abfrage berechnen?

screenshot_term_taxonomies

screenshot_term_taxonomies

Unsere Beziehungen sollten jetzt so aussehen:

screenshot_beziehungen_3

screenshot_beziehungen_3

Die vierte Tabelle: wp_terms

Na gottseidank, da blickt man wenigstens halbwegs durch. Die term_id können wir aus der wp_term_taxonomy zuordnen, der name (na endlich!) ist der Name der Kategorie, slug ist auch klar, und die term_group ignorieren wir einfach.

screenshot_wp_terms

screenshot_wp_terms

Jetzt kommt endlich Butter bei die Fische, wir können unsere Beziehungen vervollständigen.

screenshot_beziehungen_4

screenshot_beziehungen_4

Haben wir da nicht noch was vergessen?

Die Tabelle wp_termmeta

Ja, die gibts auch noch, aber ehrlich gesagt weiß ich nicht so ganz genau, wofür man die verwenden könnte, die zieht nur wenn man mit mehreren Taxonomien arbeitet. Bei marketpress gibt es eine gelehrte Abhandlung dazu, ich hab sie allerdings nicht ganz verstanden, muss ich zugeben. Nachdem die Tabelle allerdings bei mir immer leer ist, ignoriere ich sie schlicht und ergreifend.

Sonst noch was? Ach ja, ich hätts beinah vergessen:

Die Tags = Schlagwörter stecken in der selben Logik

Und zwar wird für die Schlagwörter eine eigene Taxonomie „post_tag“ angelegt. Ich verwende prinzipiell keine Schlagwörter, wenn sie es getan haben lassen sie sich nicht irritieren, uns reichen die Beziehungen über die Kategorien.

Und jetzt: die Abfrage der Kategorien über alle vier Tabellen

Anmerkung: damit das hier nicht total uferlos wird, beschränke ich mich hier auf eine Kategorieebene. Sie sehen gleich, warum: Wir holen uns zunächst mal eine Auswahl relevanter Daten aus allen vier Tabellen, der SQL sieht dann so aus:

SELECT wp_posts.ID, wp_posts.post_title, wp_term_relationships.object_id, wp_term_relationships.term_taxonomy_id AS wp_term_relationships_term_taxonomy_id, wp_term_taxonomy.term_taxonomy_id AS wp_term_taxonomy_term_taxonomy_id, wp_term_taxonomy.term_id AS wp_term_taxonomy_term_id, wp_term_taxonomy.taxonomy, wp_term_taxonomy.count, wp_terms.term_id AS wp_terms_term_id, wp_terms.name
FROM wp_terms INNER JOIN ((wp_posts INNER JOIN wp_term_relationships ON wp_posts.[ID] = wp_term_relationships.[object_id]) INNER JOIN wp_term_taxonomy ON wp_term_relationships.[term_taxonomy_id] = wp_term_taxonomy.[term_taxonomy_id]) ON wp_terms.[term_id] = wp_term_taxonomy.[term_id];

Das Ergebnis: eine schon mal relativ übersichtliche Tabelle

Hier taucht jedes Rezept so oft auf, wie es Kategorien zugeordnet hat. Wenn wir jetzt ausser den Kategorien noch Schlagwörter mit drin hätten, müssten wir die herausfiltern, aber haben wir nicht, alles brav nur Kategorien.

screenshot_kategorien_rohdaten

screenshot_kategorien_rohdaten

Ein kleiner Kunstgriff: die Abfrage auf der Abfrage

Damit ich mir keinen Wolf parametrisiere, habe ich einfach auf die eben gezeigten Rohdaten (die Abfrage heisst auch kategorien_rohdaten) eine zweite Abfrage aufgesetzt, die ist schon übersichtlicher:

SELECT Count(kategorien_rohdaten.[ID]) AS AnzahlvonID, kategorien_rohdaten.[name]
FROM kategorien_rohdaten
GROUP BY kategorien_rohdaten.[name];

Auf Deutsch: ich zähle nur die Beitrags-IDs zu jeder genannten Kategorie, und fasse pro Kategorie die Summe zusammen. Das Ergebnis:

screenshot_kategorien_endergebnis

screenshot_kategorien_endergebnis

Na bitte, geht doch 🙂

Nur noch ein kleiner Glitch ist drin: die Summe beim Backwerk stimmt nicht. Das kommt daher, dass ich bei den Backwerken drei Unterkategorien angelegt habe, nämlich „Kuchen und Torten“, „Weihnachtsbäckerei“ und „Pikante Bäckereien“. Allerdings erlaubt es einem WordPress beim Erstellen oder Bearbeiten eines Beitrags, eine Unterkategorie anzugeben ohne auch die übergeordnete Hauptkategorie anzukreuzen, das habe ich offensichtlich einige Male gemacht, und daher stammt der Zählfehler. Die Korrektur ist einfach: ich entferne die Kategorie Backwerk und behandle die drei Unterkategorien wie Kategorien erster Ordnung, mein Excel für das Tortendiagramm kann mit Unterkategorien eh nix anfangen 🙂

Ich überlasse es jedem, der mit mehr als einer Kategorieebene gearbeitet hat selber, da die Logik entsprechend rauszupfriemeln, da muss man in der wp_terms_taxonomy den parent berücksichtigen, das ist mir jetzt hier zuviel Gedöns. Das hier langt jetzt nämlich echt für einen Beitrag, der hier ist lang genug – schließlich ist ja schon fast Feiertag!

 

 

 

 

 

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Kategorien im Inselfisch-Kochbuch, statistisch aufbereitet (kleine Schummelei)

Der einfache Weg – ich schummle ein bißchen

Ich lass mir ja die Beitrags-Kategorien im Inselfisch-Kochbuch in der Sidebar anzeigen, mit der Anzahl der jeweiligen Beiträge, das sieht so aus:

screenshot_kategorien

screenshot_kategorien

Und weil ich manchmal ein bißchen ein Faulpelz bin, kopier ich mir den ganzen Schamott als unformatierten Text in eine Spalte ins Excel rein, hacke mir in der zweiten Spalte die Anzahlen manuell rein und bastel mir mein erstes Tortendiagramm:

Rezeptkategorien-Diagramm

kategorien_torte

kategorien_torte

Nanü, ich hab also am allermeisten vegetarische Rezepte eingestellt? Darüber liesse sich debattieren, schließlich habe ich auch alle Kuchen, Torten und Süßspeisen als „vegetarisch“ kategorisiert. Kann ich aber damit leben, darunter fallen nämlich auch alle Salate und Gemüsezubereitungen, und sowas esse ich täglich, das hat schon seine Richtigkeit.

Rang zwei mit 99 Rezepten hat die Kategorie „Für Kinder“, und auch das hat seine Richtigkeit, denn schließlich stelle ich auch viele Rezepte aus meiner Kinderzeit aus Omas Küche ein, die werden von den Kiddies heute auch noch geliebt!

Der Rest spiegelt getreulich wieder was ich selber oft und gerne esse. Mir sind gute Saucen genauso wichtig wie das Stückchen Fleisch auf dem Teller, und meine ganz große Liebe gehört der Mittelmeerküche. Ausserdem esse ich viel Gemüse, und Kuchen gebacken wird bei mir auch regelmäßig.

Fazit: Ins Inselfisch-Kochbuch kommen nur Rezepte, die garantiert ausgetestet sind und die bei mir selber oft auf den Tisch kommen. Deshalb sind auch die Zubereitungsbeschreibungen sehr genau und gut nachzuvollziehen, so daß die Rezepte leicht und gelingsicher nachzukochen sind. Mein Publikum mag es so – Rezepte für jeden Tag sind gefragt, keine ausgefallenen Exoten! Ich bleibe bei dieser Philosophie, und schreibe weiter nur das hinein, was ich auch selber gern koche und esse.

Ja, aber das war doch geschummelt!

Klar wars geschummelt – aber die Kategorien zu den Beiträgen aus der WordPress-Datenbank zu holen ist ein Späßchen für sich, und dazu gibt es einen neuen Beitrag.

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Beitragsstatistik: weil mir das Dashboard da nicht reicht

Da waren die WordPress-Programmierer ein bißchen sparsam

Zugegeben, eine rudimentäre Beitragsstatistik läßt sich auch im Dashboard unter „alle Beiträge“ ablesen. Lesen, wohlgemerkt, wenn man da aussagekräftige Auswertungen fahren will, steht man ganz schön auf dem Schlauch, da kann man sich die Zahlen nur abschreiben, und das ist ein mühselig Spiel. Schon die allereinfachsten Statistiken wie z.B. Anzahl der Beiträge über die Tage gerechnet kann man sich zwar am Bildschirm angucken, aber wie zum Geier kriegt man die Daten da raus und rein ins Excel? Pfiffkas, da braucht man schon wieder Plugins dafür… ähem, Spaß muss sein, wir machen das natürlich anders 🙂

Ran an die Datenbank

Die meisten Daten von Interesse, wenn es um die Beiträge geht, stecken in der WordPress-Haupttabelle, der wp_posts. Die kennen wir ja schon recht gut, und die klemmen wir uns jetzt mal und schubsen sie aus MySQL raus und rein ins Access, da lässt es sich besser werken. Ich nehme wieder die Daten aus dem Inselfisch-Kochbuch, da war am meisten los.

Anmerkung am Rande: eine Access-2010-Lizenz gibts ab um die 30 €, wer öfter mal ein handliches Datenbankerl braucht sollte über diese Investition nachdenken!

Da hat sich ganz schön was angesammelt übers Jahr

Auf gehts, raus aus MySQL via CSV für Excel, Zeichensatz Windows 1250, Erste Zeile enthält Feldnamen anhaken und Schuß! Rein in Access, darauf gucken dass das Feld post_content den Datentyp Memo kriegt, und jetzt fangen wir richtig an.

1543 Datensätze bei 316 Rezepten – ganz schön viel Holz, aber das filtern wir uns gleich mal zurecht. Das ist jetzt alles Wiederholung, ich schalt mal den Schnellgang ein.

  • unser Erfassungszeitraum startet am 29.10.2016. Das Inselfisch-Kochbuch gibts zwar schon länger, aber da habe ich es nach einem katastrophigen Providerwechsel neu aufgebaut.
  • Ende-Datum ist gestern, 21.12.2017.
  • Uns interessieren eigentlich nur die veröffentlichten Rezepte, die erkennt man am post_type = post und post_status = publish.

Daraus stricken wir unsere erste Abfrage, wir nehmen erstmal nur wenige Felder mit, für den Anfang reichen uns das Erstellungsdatum (post_date) und der Titel (post_title). Im Access-Abfrageassistenten sieht das ganz bequem so aus:

Datum und Titel

Datum und Titel

Und hier kommt noch für alle Hardcorer das SQL:
SELECT wp_posts.post_date, wp_posts.post_title
FROM wp_posts
WHERE (((wp_posts.post_status)=“publish“) AND ((wp_posts.post_type)=“post“));

Das Ergebnis hat die erwarteten 316 Datensätze und sieht doch schon mal sehr hübsch aus:

liste_datum_titel

liste_datum_titel

Und wo ist der Rest geblieben?

Immerhin 1227 Datensätze sind bei unserer Abfrage auf der Strecke geblieben, wer oder was sind die? Access zu Hilf!

  • 1192 Datensätze sind vom post_status „inherit“, davon wiederum 1120 vom post_type „revision“. Das sind die Revisionen, die man sich im Beitragseditor zurückholen kann, wenn man mal einen Beitrag verschlimmbessert hat und eine frühere Version wieder herstellen möchte.
  • 16 mal post_type = page, das sind Seiten, keine Beiträge.
  • 72 mal post_type = attachment, das sind die hochgeladenen Bilder
  • und noch ein bißchen Kleinkram, ein paar drafts vom post_type = nav_menu_item und ein Contact-Form-Seven-Formular, das wars dann aber auch.

Wir bleiben jetzt mal bei unseren 316 veröffentlichten Beiträgen = Rezepten. Hier kommt die erste Statistik, die:

Anzahl der veröffentlichten Rezepte pro Tag über den ganzen Erfassungszeitraum

rezepte_pro_tag

rezepte_pro_tag

Was sagt uns dieses zackige Diagramm? Ich habe von Ende Oktober 2016 bis Ende Januar 2017 Rezepte eingehackt wie der Weltmeister, das war erstens die Wiederherstellung aus dem Datenbankbackup und zweitens die gleichzeitige Überarbeitung aller Rezepte im Hinblick auf Barrierefreiheit.  Von April bis Juli hab ich dann noch die Nachzügler aus dem Backup eingehackt, und ab August läuft dann der Normalbetrieb, mit ein bis zwei Rezepten an einem Tag. Dazu nehmen wir mal zum Vergleich die:

Besucherentwicklung über den gleichen Zeitraum

Man kann ganz deutlich sehen, dass die Anzahl der eingestellten Rezepte und die Anzahl der Besucher über den gleichen Zeitraum nahezu nix miteinender zu tun haben.

ifkb_besucher_pro_tag

ifkb_besucher_pro_tag

Ich mach hier mal einen kleinen Kunstgriff (wen es interessiert: mit dem GIMP) und mache eine

Kombination beider Diagramme

Jetzt stimmt natürlich die Y-Achsenbeschriftung nicht mehr, aber das kann ich verschmerzen. Die blaue Linie ist die Anzahl der von mir eingestellten Rezepte, die grüne Linie zeigt den Besucherverlauf.

besucher_gegen_rezepte

besucher_gegen_rezepte

Fazit: meinen Besuchern ist es nicht so wichtig, dass ständig neue Rezepte eingestellt werden. Die kommen, weil sie ein bestimmtes Rezept über Google gefunden haben, und dann kommen sie wieder und wieder zum Schmökern und zum Nachschlagen. Zur Erinnerung: ich habe 2819 Stammkunden (erkenntlich an den individuellen IP-Adressen), die so oft hereinschauen, dass sie den Löwenanteil meiner über 50.000 Hits auf dem Inselfisch-Kochbuch ausmachen.

Ich lerne daraus

Ja, was eigentlich? Dass ich mit dem Inselfisch-Kochbuch auf einem guten Weg bin, ein treues Stammpublikum habe und mir keinen Streß machen muss, weil ich nicht täglich neue Rezepte einstelle. Das läuft prima so wie es ist, die Besucherzahlen haben insgesamt eine leicht steigende Tendenz, das ist ein gesundes Wachstum und sehr erfreulich.

Und damit lass ich es für heute mal gut sein. Morgen gibts noch mehr WordPress-Zahlenschubserei,versprochen!

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Noch mehr Zahlenschubserei: Besucher im schwarzen Pinguin

Ich machs kurz, ich verspreche es! 🙂

Die Besucherstatistik vom schwarzen Pinguin 2017

Vom Start der Zählung am 10.2.2017 bis gestern,  21.12.2017 waren es insgesamt 8704 Besucher an 316 Tagen im letzten Jahr, macht 27,5 Besucher pro Tag. Als Rohdiagramm sieht das so aus:

exceldiagramm besucher pro tag

besucher pro tag

Da ist im September ein Ausreisser dabei, das war 132 mal die selbe IP-Adresse, scheint ein Hack-Versuch gewesen zu sein. Den nehmen wir mal raus, der verzerrt mir die Stat doch sehr. Dasselbe nochmal ohne den Hacker:

ohne_hacker

ohne hacker

Na, das nenne ich doch einen vernünftigen Geschäftsverlauf. Ich hab das Jahr recht ruhig angefangen, dann einen sehr aktiven Sommer hingelegt und so ab September wieder ein bißchen weniger geschrieben. Da wärs jetzt natürlich interessant, wenn man die Besucherzahlen gegen die Anzahl meiner Beiträge gegenrechnen könnte, aber dazu kommen wir später. Jetzt gibts erst noch die Stammkunden, also alle, die öfter als einmal auf der Seite waren, das waren 970 Leutchen. Wie man hier sieht, waren die meisten so etwa zwischen 5 mal und 15 mal da:

stammkunden

stammkunden

Auch das ist eine sehr zufriedenstellende Gauss’sche Glocke, wie es sich gehört. Und damit laß ich es auch schon gut sein, jetzt gehen wir ans WordPress-Eingemachte, und dazu gibt es einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Alle alten Programmierer lieben Zahlenschubsereien – Besucherstatistik im Inselfisch-Kochbuch

„Trau keiner Statistik, die du nicht selbst gefälscht hast!“

Das ist mein Motto seit den ersten Stat-Vorlesungen an der Uni in den frühen 80er Jahren. Und es ist heissa! Jahresende und Zeit für einen statistischen Jahresrückblick.

Unser gutes altes WordPress sitzt ja auf einer wunderbaren Datenbank, und Datenbanken sind heissbegehrtes Statistikerfutter. Ich nehme mir mal mein Inselfisch-Kochbuch vor, das lebt und ist das ganze Jahr gepflegt worden, wollen mal sehen was wir da an statistischen Auswertungen rauskriegen. Es wird schon lange mal wieder Zeit für ein bißchen Spaß auf der Datenbank!

Was natürlich die SEO-Freaks interessiert: der Besucherzähler

Aber klar doch, den nehmen wir uns als Erstes vor. Ich verwende das leichtgewichtige Visitor Counter Plugin , das ist problemlos in der Installation und Anwendung. Es schreibt die statistischen Werte in eine eigene Tabelle weg, die heißt (Präfix-)vcp_log und ist damit einfach zu lokalisieren. Als CSV für MS Excel exportieren, und der Spaß kann losgehen…  aber halt! Ich schubs die ganze Sache natürlich in mein Leib- und Magen-Datenbankerl rein, das feine alte Microsoft Access, da kann ich Auswertungen fahren bis die Schwarte knackt 🙂

Visitor Counter Plugin: die Rohdaten

Schauen wir uns die Tabelle vcp_log mal kurz an, die ist übersichtlich genug. Es gibt drei Felder:

  1. LogID
  2. IP
  3. Time

und das wars schon. Die LogID ist ein Autoinkrement und interessiert nicht weiter, die IP-Adresse ist selbsterklärend und der Timestamp als Datum und Uhrzeit auch.

Aber ansonsten kanns jetzt mal losgehen: Time in Tagesdatum umwandeln, Gruppieren, Anzahl von IP ausgeben, Excel-Liniendiagramm draus machen und schon haben wir diese hübsche Grafik der Besucher pro Tag:

Excel-Diagramm Neue Besucher pro Tag

Excel-Diagramm Neue Besucher pro Tag

Kurze Analyse des Diagramms

Wow, was war Anfang September los? Der Peak mit den fast 700 Besuchern kommt von der Veröffentlichung des Inselfisch-Kochbuchs im Newsletter des Bayrischen Blinden- und Sehbehinderten-Verbandes, das ist ganz eindeutig zuzuordnen.

Ansonsten ist der Grafik noch zu entnehmen, dass die Anzahl der Besucher sich übers Jahr bei ungefähr 100 – 200 pro Tag eingependelt hat, Tendenz leicht steigend.

Was die Grafik nicht zeigt – nicht zeigen kann – ist die Anzahl der „Wiederholungstäter“. Ich weiss aber aus vielen persönlichen Kontakten, dass das Inselfisch-Kochbuch ein treues Stammpublikum hat, viele kommen immer wieder, auch mehrmals die Woche, und schauen ihre Lieblingsrezepte nach oder gucken obs was Neues gibt. Die gibts aber ein andermal, das sprengt mir hier sonst den Beitrag.

Was wir noch machen können: die Uhrzeit

Dabei kommt eine kleine Überraschung heraus: angeblich hatten wir Nachts um 1 die meisten  Besucher:

Excel-Diagramm Besucher nach Uhrzeit

Excel-Diagramm Besucher nach Uhrzeit

Das glaube ich ja noch nicht ganz! Wollen mal sehen, wenn der Timestamp in GMT (Greenwich Mean Time) angegeben sein sollte, sind wir mit der MEZ eine Stunde voraus, und mit der Sommerzeit sogar zwei Stunden. Dann läge der Peak so bei ca. 11 Uhr abends, das glaub ich ja schon eher, da guckt man nach der Sportschau nochmal in den Computer. Das würde auch den relativ niedrigen Stand zwischen 21 und 23 besser erklären, wenn das in echt 19 – 21 Uhr war, da sind die Leute beim Abendessen, das haut schon eher hin!

Und noch ein bisschen Kleinkram

Seit Beginn der Zählung am 29.10.2016 hatten wir 51789 Besucher insgesamt, nur in 2017 (bis gestern, 21.12.) waren es 45172. Das macht im Durchschnitt rund 123 Besucher pro Tag, in 2017 waren es pro Monat im Schnitt 3771. Spitzenreiter war der September mit 5367 Besuchern insgesamt, s. oben.

Nachgereicht: die „Wiederholungstäter“

Also, gucken wir da noch mal genauer hin: wir hatten insgesamt 51789 Besucher. Wenn ich mir die nach der IP-Adresse gruppiere, bleiben noch 8479 übrig. Das heisst, jeder Besucher ist im Schnitt 6,11 mal im Inselfisch-Kochbuch gewesen. Das geht natürlich noch genauer, ich klemm mir mal alle, die öfter als einmal da waren (das waren 2819 Stammkunden) und bastel mir ein Diagramm:

Besucher öfter als einmal

Besucher öfter als einmal

Na wer sagts denn, das sieht doch einer Gauss’schen Glocke verdammt ähnlich! Die allermeisten Besucher kommen anscheinend so zwischen 30 und 70 mal im Jahr, damit kann ich prima leben. Der Ausreisser am Anfang mit über 400 Hits war übrigens wahrscheinlich ein Hacker, der hat die Seite im Sekundenrythmus angesurft. Den muss man aus der Stat  rausnehmen, dann siehts so aus:

Ohne Hacker

Ohne Hacker

Na bitte, geht doch! Eine wunderbare Normalverteilung, wie aus dem Lehrbuch. Ich lieeebe Statistik! 🙂

Und das genügt jetzt auch mal fürs Erste! Natürlich wollen wir auch noch Stats über die Rezepte und Kategorien und so weiter fahren, aber dazu gibts einen neuen Beitrag.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

In eigener Sache: Let’s talk about SEO, baby!

An diesem Wochenende hat mein Besucherzähler auf dieser Seite die 5.000er-Marke geknackt, und das ist eine respektable Zahl für einen sehr spezialisierten kleinen Blog wie den schwarzen Pinguin. Gezählt wird hier seit Februar diesen Jahres (2017), also hab ich hier rund gerechnet 5.000 Besucher in einem halben Jahr gehabt. Das freut mich persönlich sehr und ermutigt mich, mit meiner lockeren Plauderei über IT am Feierabend und WordPress im Speziellen weiterzumachen. Mir geht auch so schnell der Stoff nicht aus, keine Bange, nächste Woche gibts dann wieder Spaß auf der Datenbank!

Barrierefreiheit als SEO-Booster

Da wir gerade beim Thema sind: der Renner auf evileu.de ist nach wie vor das Inselfisch-Kochbuch mit aktuell 33.648 Besuchern, und da sind die Besucherzahlen nach einem eh schon guten Start nochmal kräftig in die Höhe gegangen, seit ich das Kochbuch in Sachen Barrierefreiheit  komplett umgebaut habe. Auch nicht schlecht läuft meine Oddballs-Handarbeitsseite, hier sind es immerhin auch schon 11.297 Besucher in einem halben Jahr. Das ist wirklich nicht übel für eine rein private Webseite, und ich werde oft gefragt, wie ich das denn gemacht habe.

Meine SEO-Tricks

Da muß ich euch leider enttäuschen. Ich nutze kein SEO-all-in-one Pack, ich jongliere nicht mit Keywords, mir ist mein Google Ranking egal, ich schalte keine Werbung, ich mach das hier alles zu Fuß.

Was ich allerdings schon mache: ich blogge wie der Weltmeister. Im Inselfisch-Kochbuch gibts mindestens einmal die Woche ein neues Rezept, hier quassel ich auch ungefähr ebenso oft aus dem Nähkästchen der alten Programmiererin, und auf den Handarbeitsseiten gibts regelmäßig Fotos meiner aktuellen Socken, Schals und Pullover und gelegentlich auch mal eine neue Anleitung zum Download als PDF. Das heißt, auf meinen Blogseiten ist regelmäßig Neues geboten, und das lieben nicht nur die Suchmaschinen, das lieben anscheinend auch menschliche Besucher.

Beiträge mit Hand und Fuß

Und ich erzähle halt nicht nur irgendeinen Keyword-gespickten Quark, meine Beiträge haben (meistens) Hand und Fuß. Nach meinen Kochrezepten kann auch ein Anfänger kochen, wenn man einen Schal nach meiner Handarbeitsanleitung strickt, dann wird das auch was, und wenn man meinen Code hier nachprogrammiert, dann funzt das auch. Das ist mein ganzes Geheimnis.

Wiederholungstäter und Mundpropaganda

Das sind meine wichtigsten Werbemittel. Meine streng wissenschaftlichen Analysen (ich hab einfach viele Leute gefragt) haben ergeben, dass gerade das Inselfisch-Kochbuch durch Mundpropaganda immer mehr Besucher bekommt, besonders das mit der Barrierefreiheit spricht sich hübsch herum. Und dann kommen meine Besucher auch wieder, sie benutzen das Kochbuch als Nachschlagewerk. Ich hab jetzt schon von vielen weiblichen Fans gehört, dass sie im Supermarkt mit dem Smartphone schnell mal ein Rezept im Inselfisch-Kochbuch nachschlagen und schauen, was sie dafür einkaufen müssen. Da hilft es natürlich, dass ein sauber umgesetztes WordPress-Theme im Regelfall fully responsive ist und auch auf dem Smartphone vernünftig dargestellt wird.

Spezialisierung: ein Blog, ein Thema

Das mit der Spezialisierung war bei mir dringend notwendig, weil ich so breitgefächerte Interessen habe. Ich male, ich programmiere, ich koche für mein Leben gern, ich schreibe Bücher für Kinder und für Erwachsene und produziere Handarbeiten am laufenden Band, und das ist noch lang nicht alles.

Ich habe in früheren Jahren schon mehrere vergebliche Anläufe gemacht, alle meine Interessensgebiete auf einer einzigen Webseite unterzubringen, und bin jedesmal  an dieser Sysiphosarbeit gescheitert. Letztendlich war  Wordpress der Schlüssel für die erfolgreiche Realisierung des Gemischtwarenladens evileu.de.

Ich habe jedem meiner vielen Hobbies einen eigenen Blog gegönnt, in dem ich jeweils nur über ein einziges Thema blogge. Es sind jetzt insgesamt etwas mehr als 10 Blogs, nicht alle sehr aktiv, aber doch eine stolze Anzahl für eine private Homepage. Wenn man nur mal auf die Seiten über meine Malerei schaut, das Thema ist jetzt aufgesplittet in meine Biographie als Malerin, meine Aquarelle, die Serie mit den blauen Planeten und dazu noch die Computergrafiken mit GIMP. Das macht 4 Kunst-Blogs, und die sind alle proppevoll mit Bildern und meinen Texten dazu. Aber eben sauber nach Themen getrennt, sonst verzettelt man sich. Und auch die Besucher verzetteln sich wenn eine Webseite zu viele verschiedene Topics anbietet, da werden die Menüs und Untermenüs und Unter-Untermenüs so verschachtelt, dass kein Schwein mehr durchblickt, und die Besucher nicht wiederkommen, weil sie nichts wiederfinden.

Jetzt fahre ich da eine ganz klare Linie, und das hat für mich als viel-Bloggerin den Vorteil, dass ich sofort weiß wohin damit, wenn mir eine Idee zu einem neuen Beitrag kommt. Und meine Besucher kennen sich auch aus, da jeder Themenblog einen unverwechselbarenb Look&Feel hat, und man sofort weiß ob man auf der Handarbeitsseite oder im Inselfisch-Kochbuch gelandet ist. Ich bin ein Buchhalterkind, ich liebe strukturierte Ablagesysteme!

Damit sind wir ganz wunderbar beim nächsten Stichwort gelandet:

Strukturierung: h1, h2 und Co.: eigentlich HTML für Anfänger

Ob sie es glauben oder nicht, Textverarbeitung am Computer gab es schon lange vor Windows und WYSIWYG. Ich erinnere nur an TeX/LaTeX oder an Word für DOS, wo man mitnichten auf dem Bildschirm angezeigt bekam, was dann auf dem Drucker herauskam. Damals lernten wir alles über die Verwendung von sog. Textauszeichnungen, in Word für Windows heißen sie Formatvorlagen. Und da HTML nichts anderes als eine Textauszeichnungssprache ist, gibt es sie  hier genauso. Jeder kennt sie, kaum jemand wendet sie richtig an.  Für Überschriften sind h1..h6 vorgesehen, eine Tabelle formatiert man mit Hilfe des <table>-Tags, es gibt nummerierte Listen, es gibt Image-Tags für die Bilder… das sind viele, aber doch nicht endlos viele. Eine hübsche komplette Liste aller HTML5-Tags findet ihr hier bei MDN Web Docs

Trennung von Text und Formatierung

Die Idee dabei ist, Text und Formatierung sauber zu trennen. Ein einfaches Beispiel: eine Hauptüberschrift soll fett, in Arial und in 30 Punkt Größe angezeigt werden. Was macht der WYSIWYG-Anwender? Er markiert den betreffenden Textabschnitt, drückt auf das Icon für „fett“, wählt in der Dropdownliste für die Schriftart „Arial“ und scrollt in der Schriftgrößen-Zahleneingabe rauf bis 30. Das erzielt zwar den gewünschten Effekt, aber es ist textverarbeitungstechnisch nicht sauber. Wie gehts richtig? Die Überschrift kriegt die Tags <h1>…</h1>, und wenn man es nicht dem Browser überlassen will wie eine Überschrift erster Ordnung dargestellt wird, legt man es in seiner CSS-Datei fest. Hierhin kommen unsere Textattribute, wenn man es richtig machen will.

Saubere Gliederung

Das habe ich bei der Umarbeitung meiner Webseiten auf barrierefrei neu lernen müssen, bei mir hatte sich da über die Jahre auch eine gewisse Schlamperei eingeschlichen. Ich schreibe ja sehr viel Text, und lange Textwüsten auf einer Webseite sind absolutes Bildschirmgift, die liest kein Schwein. Also, umdenken, Text in kürzere logische Einheiten unterteilen, Zwischenüberschriften einfügen, wo es Sinn macht, Listen und Tabellen verwenden. Das erhöht die Lesbarkeit und hält den Besucher bei der Stange, weil er nicht von unstrukturierten Endlostexten gelangweilt wird.

Einfaches Beispiel: Rezepte mit Struktur

Ich hätte da wieder ein einfaches Beispiel: alle meine Rezepte im Inselfisch-Kochbuch haben die selbe logische Gliederung:

  • Einleitung
  • Zutaten
  • Zubereitung
  • Tipps

Diese Elemente sind als h2-Überschriften formatiert. H1 ist der Titel des jeweiligen Rezepts, das ist unser post_title aus WordPress. Der Text dazwischen ist einfach <p> wie Absatz. That’s all, nach diesem Muster schreibe ich alle meine Rezepte. Ich muß nicht drüber nachdenken wie ich es mache, und es hat bei meinem Publikum einen hohen Wiedererkennungswert und dient der allgemeinen Übersichtlichkeit und Verständlichkeit. Mehr ist nicht dran an der Strukturierung – machen muß man es halt!

Übrigens: Suchmaschinen lieben klar strukturierte HTML-Dokumente. Benutzer mit Handicap (Screenreader & Co.) lieben sie auch, weil sie so klar durch das Dokument navigieren können. Deswegen ist eine gute Textstrukturierung auch eine der wichtigsten Voraussetzungen der Barrierefreiheit nach WCAG.

Mehr ist nicht dran an meinem SEO-Programm

Mit dieser Strategie bin ich zu meinen stolzen Besucherzahlen gekommen, über alle Blogs gerechnet sind das jetzt insgesamt fast 50.000 seit Anfang des Jahres. Genug aus dem Nähkästchen geplaudert, ich mach hier mal die Kiste zu. Ich hab mir nämlich gerade ein neues Projekt in Sachen Barrierefreiheit angelacht, da hat der schwarze Pinguin jetzt ein bißchen Sendepause. Bis die Tage!

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

WordPress als führendes System für die Mitgliederverwaltung? Ein Fazit

Ich habe mich jetzt in etlichen Beiträgen mit dem CSV-Import eigener Daten für eine Mitgliederverwaltung in WordPress herumgeschlagen, da wird es Zeit, ein Resumee zu ziehen.

Ist die Lösung mit dem CSV-Import praxistauglich?

Zur Erinnerung: ich habe mich dafür entschieden, immer die komplette CSV-Datei zu importieren, und einen Select vorzuschalten, der bereits vorhandene Datensätze (kenntlich an der eindeutigen ID/Mitgliedsnummer) unberührt stehenläßt.

Das kann man wirklich so machen, da im WordPress-Beitragseditor vorgenommene Änderungen an Mitgliederdaten so erhalten bleiben. Man muß halt nur konsequent sein, und eventuelle Änderungen von Adress- oder sonstigen Daten wirklich in WordPress einpflegen und nicht in der Excel-Liste, die ja nach wie vor weitergeführt wird.

Was nicht so schön ist: die Vergabe einer neuen Mitgliedsnummer muß in der Excel-Liste manuell erfolgen. Man könnte zwar auf die Idee kommen, die beim Anlegen eines Beitrags erzeugte WordPress-ID aus der Tabelle wp_posts als Mitgliedsnummer zu verwenden. Aber das ist ziemlich unbefriedigend, weil WordPress ja allen möglichen Ruß in der wp_posts speichert, Bilder und andere Attachments und Seiten und und und….

In der Praxis wird man hier früher oder später von der Excel-Liste auf eine separate Datenbanktabelle umstellen, sei es nun MySQL oder Access oder was auch immer. Hier hat man die Möglichkeit, die neue ID für ein neues Vereinsmitglied per AutoIncrement automatisch erzeugen zu lassen, das schließt Fehler bei der Vergabe einer neuen ID effektiv aus, und man kann seinen Nummernkreis selbst bestimmen.

Ja aber – wenn wirs schon in einer Datenbanktabelle haben…

Genau! Meine Rede! Wir entscheiden uns für eine MySQL-Lösung, und dann gehen wir weit, weit zurück und erinnern uns, was ich in etlichen Beiträgen vor langer Zeit über die Einbindung eigener Tabellen in WordPress erzählt habe. Es ist relativ einfach zu realisieren, die Datenpflege kann über unseren selbstgeschriebenen Datenbankeditor sehr komfortabel erfolgen, es kann in der eigenen Tabelle sehr gezielt nach den unterschiedlichsten Kriterien gesucht werden, um nur einige Pluspunkte zu nennen. Das bringt mich auf was, das ich beinahe vergessen hätte:

Benutzerdefinierte Felder sind importiert, und nun?

Wir können sie auch relativ problemlos anzeigen, aber was ist, wenn ich mal eine gezielte Suchauswertung über mehrere Custom Fields fahren will? Zum Beispiel alle Mitglieder herausfinden, die in München wohnen, männlich sind und an Fußball interessiert.

Da hakts nämlich kräftig. WordPress bietet so ad hoc keine Möglichkeit dafür. Ja ich hörs schon, es gibt Plugins die einem da behilflich sind und eine gezielte Suche nach benutzerdefinierten Feldern ermöglichen, aber wie sieht das Ergebnis aus? Krieg ich halt die Ergebnisse meiner Suche auf einer WordPress-Seite als HTML angezeigt.Na prima.

Und was ist wenn ich das weiterverarbeiten will, z.B. für eine gezielte Mailing-Aktion an alle meine Münchner Fußballmänner? Da muss ich schon auf die Datenbank.

Nochmal langsam zum Nachvollziehen: für jedes Custom Field ein Join

Zur Erinnerung, meine benutzerdefinierten Felder stecken in der wp_postmeta und sind dort über die post_id den Datensätzen in der wp_posts zugeordnet. Das Feld für den Ort hat den meta_key „ort“ und als meta_value den entsprechenden Eintrag, z.B. München. Um jetzt alle Datensätze herauszufischen, die in der wp_postmeta beim meta_key einen Ort haben, muß ich die Tabellen über die post_id joinen, das sieht dann in etwa so aus:

SELECT wp_postmeta.meta_id, wp_postmeta.post_id, wp_postmeta.meta_key, wp_postmeta.meta_value, wp_posts.post_title, wp_posts.post_content, wp_posts.post_status
FROM wp_posts INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id
WHERE (((wp_postmeta.meta_key) Like „ort“) AND ((wp_posts.post_status) Like „publish“));

Ganz schön viel Holz für ein einzelnes Feld, nicht wahr? Wenn ich jetzt zusätzlich noch ein zweites Feld, z.B. die Postleitzahl, mit dazuhaben möchte, muß ich tatsächlich die Tabellen ein zweites Mal  joinen und die where-Klausel nochmal stellen mit wp_postmeta.meta_key) Like „plz“, das sieht dann schon so aus:

SELECT wp_postmeta.meta_id, wp_postmeta.post_id, wp_postmeta.meta_key, wp_postmeta.meta_value, wp_posts.post_title, wp_posts.post_content, wp_posts.post_status, wp_postmeta_1.meta_key, wp_postmeta_1.meta_value
FROM wp_postmeta AS wp_postmeta_1 INNER JOIN (wp_posts INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id) ON wp_postmeta_1.post_id = wp_posts.ID
WHERE (((wp_postmeta.meta_key) Like „ort“) AND ((wp_posts.post_status) Like „publish“) AND ((wp_postmeta_1.meta_key) Like „plz“));

Das, liebe Freunde, gefällt mir überhaupt nicht. Auf meiner eigenen Datenbanktabelle würde der Select nämlich ungefähr so aussehen:

Select ID, vorname, nachname, ort, plz from meine_tabelle

Fertig. Ist irgendwie hübscher, nicht wahr?

Mein Fazit

Mir ist für so etwas die simple MySQL-Abfrage auf der eigenen Datenbanktabelle -zigfach sympathischer als der mühsame mehrfache Join von wp_posts und wp_postmeta. Das ist meine persönliche Präferenz als alte Datenbankerin.

Und mein Fazit lautet: Ich würde meinem Kunden auf jeden Fall die Lösung mit der eigenen Datenbanktabelle als die wesentlich flexiblere und übersichtlichere Methode nahelegen. Aber wie gesagt, ich bin da vorbelastet, ich lieeebe Datenbanklösungen und spiele gern mit MySQL. Am Ende muß jeder selber entscheiden, was ihm bzw. seinem Kunden besser taugt.

Ich lass es jetzt mal gut sein und überlege mir ein neues Thema für etwas praktischen Spaß auf der Datenbank. Stay tuned!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Mea culpa: warum dieser Blog alles andere als barrierefrei ist

Barrierefreiheit im Internet ist ein Thema, das mich in letzter Zeit sehr viel beschäftigt hat. Ich bin durch die Initiative „Bayern barrierefrei“ des Freistaats auf das Thema aufmerksam geworden, und halte es für immens wichtig. Auch Menschen mit Handicap haben ein Grundrecht auf Informationsfreiheit! Da ist Umdenken nötig, denn die meisten Webdesigner vergessen vor lauter SEO-Zirkus und Multimedia-Geblinker, daß es auch Benutzer gibt, die z.B. auf einen Screenreader oder eine Braillezeile angeweisen sind.

Mein Pilotprojekt

Ich habe in den letzten Monaten als Pilotprojekt mein Inselfisch-Kochbuch barrierearm gestaltet, und ich kann ihnen sagen: es war eine Heidenarbeit! Wenn ich dabei nicht so tatkräftige Unterstützung von der Stiftung Pfennigparade bekommen hätte, ich hätt’s aufgeben müssen. Dabei ist das mit der Barrierefreiheit, genauer gesagt: mit der Barrierearmut  eigentlich gar nicht so schwer zu realisieren, es gibt einige nicht schwer zu begreifende Grundregeln. Wenn man die von Anfang an beachtet und z.B. seine Beiträge vernünftig durchformatiert und anständig gliedert, und auf aussagekräftige Alt-Texte bei den Bildern achtet, ist schon viel gewonnen. Wenn man das  im Nachhinein korrigieren will, dann artet es in Arbeit aus. Ich habe über 200 Rezepte und -zig Bilder manuell durchgeforstet und überarbeitet. Es gibt  leider keine Plugins, die einem die logische Gliederung von Texten abnehmen könnten, und wird sie wohl auch nie geben, da muß man schon selber ran. Ich versuche mir jetzt anzugewöhnen, von Anfang an strukturiert zu schreiben, weil ich die Ochsentour mit der manuellen Überarbeitung nicht nochmal durchziehen möchte, einmal hat gereicht.

Böse Sünde: Codeschnipsel als Screenshots

Das geht natürlich im Sinne der Barrierefreiheit überhaupt nicht. Screenshots sind ja auch nur Bilder, wenn da was zu Lesen steht, damit kann kein Screenreader etwas anfangen! Ich habe  in diesem Artikel schon mal kurz darüber gemault, daß es einem WordPress so gnadenlos schwer macht, Programmcode vernünftig in einem Artikel darzustellen. Ich habe jetzt die Screenshots als Notlösung genommen, bin aber noch auf der Suche nach einer besseren Lösung. Vielleicht wäre es hilfreich, den relevanten Programmcode zu einem Artikel als Textdatei mit dranzuhängen, das wär schon mal besser als nix. Ich denke da an die vielen IT-Bücher, wo man die Codebeispiele  als CD mitgeliefert bekommt… mhm, könnte gehen, wenn ich es mir recht überlege. Ich werde mal mit meinem Kontakt bei der Stiftung Pfennigparade darüber sprechen, da muß es einen vernünftigen Kompromiss geben, so daß ich ungehindert flüssig schreiben kann und trotzdem eine nach Möglichkeit barrierearme Seite dabei herauskommt.

Nachtrag:  Habe nachgeforscht, leider scheint es wirklich keine andere Möglichkeit zu geben, als den visuellen Editor NICHT zu benutzen. Keine schöne Lösung… na ja, vielleicht finde ich noch ein Plugin, das den Programmcode nicht verhackstückt. Die Hoffnung stirbt zuletzt 😉

Und was hat das alles mit WordPress zu tun?

Mehr als sie denken. Letztendlich ist ja WordPress unser Werkzeug der Wahl zum Erstellen von Webseiten, und dazu gehört ein bißchen mehr als nur schicke Layouts und tolle Animationseffekte. Ausserdem verführt WordPress beim Hochladen von Bildern zur Schlamperei bei der Beschriftung. Von älteren Webdesignern (z.B. der gute alte NVU) wurde man noch gezwungen, beim Bilder einfügen zumindest einen Alt-Text einzugeben. Bei WordPress kann man da locker drüberklicken, die meisten Leute tun es auch weil ihnen nicht klar ist was ein „Alternativtext“ ist und wozu der gut sein soll.

Jetzt noch die gute Nachricht: es ist gar nicht so schwer, mit WordPress barrierearme Webseiten zu gestalten, wenn man es von Anfang an richtig macht. Die meisten modernen Themes sind gut strukturiert und mit <h1>, <h2>, <li> usw. sauber durchgegliedert, und sie sind auch mit der Tastatur bedienbar. Es gibt sogar spezielle Themes, die von Anfang an auf Barrierefreiheit zugeschnitten sind, aber da muß ich noch ein bißchen forschen, dann erzähle ich mehr darüber, ein andermal. Es wird wieder Zeit für ein bißchen Spaß auf der Datenbank!

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

SQL – die vergessene Kunst?

Die dolle Olle – Structured Query Language

Meine zweite große Liebe auf dem Computer, ich hab es schon erwähnt, waren relationale Datenbanken und SQL. Die geniale Structured Query Language wurde an den Universitäten sehr gepflegt, schließlich ist sie ja auch von Wissenschaftlern für Wissenschaftler erdacht worden. Der ursprüngliche Zweck von SQL war ja die digitale Auswertung von Massendaten. Soweit ich weiß waren die Verhaltensforscher die ersten, die mit Hilfe von strukturierten Datenbanken wissenschaftlich fundierte Forschungsergebnisse erzielten. Mehr über die Geschichte und die Grundlagen von SQL kann man hier bei Wiki nachlesen, das ist spannend und gilt alles auch heute noch.

Ach so, und was hat das mit WordPress zu tun? Gemach, gemach.  Ohne MySQL kein WordPress. Mehr dazu (viel mehr!) später.

SQL ist SQL geblieben

Ich jedenfalls habe SQL damals an der Uni sozusagen mit der Muttermilch aufgesogen und habe früh erkannt, welcher Power und welche Vielseitigkeit im relationalen Datenbankmodell steckt. So kam es, daß ich als studierte Biologin in der EDV gelandet bin – und dort echt Karriere gemacht habe. SQL hat sich bis heute kaum verändert. Wer die Grundlagen einmal begriffen hat, dem ist es egal ob er es nun mit Oracle, Access oder SQL Server, MySQL oder sonst einem Dialekt zu tun hat. Einen Select, einen Join oder eine Where-Klausel schreibt man heute noch genauso wie vor 40 Jahren, da ist nicht viel passiert – wozu auch. Die alten SQL-Konzepte sind so gut, da ist nie etwas Besseres nachgekommen.

Datennormalisierung – wer kennt das heute noch?

Was allerdings heute in Vergessenheit geraten scheint, ist die grundlegende Strukturierung der Daten. In SQL-Datenbanken landet heutzutage häufig unkontrolliertes Datenmus, es ist eben zu einfach, irrsinnige Mengen an Daten automatisiert abzuschöpfen. Als Programmierer sitzt man dann zu oft vor einer ungenießbaren Datensuppe, aus der man eine strukturelle Logik erst mühsam herausfieseln muß, ehe man zu vernünftigen Abfrageergebnissen kommt. Dabei könnt’s so einfach sein – wenn sich heute noch jemand die Mühe machen würde, die grundlegenden Tabellen zu Normalisieren und eine vernünftige Struktur hineinzubringen.

Gottseidank gibts Datensuppe – und (noch) keine gläsernen Bürger

Ich bin eigentlich ganz froh, daß die heutzutage erhobenen Datenmengen so schlecht strukturiert sind. Wenn da mal jemand vernünftig aufräumen würde, wären wir ganz schnell beim gläsernen Bürger. Überlegen sie nur mal, was herauskäme, wenn all ihre Bank- und Behördendaten, ihre Handy- und Internetprofile, ihre Krankenkassendaten und was weiß ich noch alles sauber durchstrukturiert und per SQL ganz easy abfragbar wären. Dann hätten wir sie, Huxley’s Schöne Neue Welt – und ich bin heilfroh, daß es nicht so ist.

Unfreiwilliger Schutz vor der totalen Überwachung

Die irrsinnigen Mengen an Datenschrott, die heutzutage über jeden von uns in irgendwelchen Computern gespeichert sind, sollen bitte so unübersichtlich und unauswertbar bleiben, wie sie sind, das ist unser bester Schutz vor der totalen Digitalisierung, die mit den heutigen technischen Mitteln theoretisch schon möglich wäre. Praktisch umsetzbar ist sie (noch) nicht, weil bei der Unzahl an unterschiedlichen Systemen und labyrinthischen gewachsenen Strukturen keiner mehr durchblickt, und das soll bitteschön so bleiben. Daten-Müllhalden als Schutz vor der totalen Überwachung?

Besser als nix, wenn sie mich fragen. Lieber ärgere ich mich noch lange Jahre z.B. mit Behörden oder Versicherungen rum, weil die anscheinend keine Daten speichern (oder sie nicht wiederfinden) und man bei jedem kleinen Antrag alles noch mal von vorn ausfüllen muß. Ist für mich als Bürger etwas unbequem, aber ehrlich: wenn die alle auf Knopfdruck meine sämtlichen Daten da hätten, würde mir mulmig. Da sei St.Murphy vor, er bewahre uns bitte das behördliche Datenchaos. Amen! 😉

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Über mich – ich komme aus der Computer-Steinzeit

Eine nicht ganz so kurze Vorstellung

Gestatten, daß ich meine digitale Historie  vorstelle? Nachdem ich schon sehr lange im Geschäft bin, geht das nicht in drei Worten, aber ich werde versuchen, mich kurz zu fassen.  Sie müssen auch nicht alles lesen, aber andererseits weiß man doch ganz gern, mit wem man es zu tun hat, daher erzähle ich mal ein bißchen was von meinen „Roots“ und ein wenig Computergeschichte. WordPress kommt hier erstmal gar nicht vor, das gibts ja erst seit 2004. Aber Datenbanken gabs damals schon…

Ich bin Fachinformatikerin für Anwendungsentwicklung und seit Anfang der 80er Jahre im IT-Gewerbe tätig. Ich bin auch Datenbankprogrammiererin der ersten Stunde, das fing so ca. 1980 mit Superbase auf dem Commodore C64 an. Damals habe ich an der Uni jeden greifbaren Kurs und jedes Seminar belegt, das irgendwie mit Computern zu tun hatte, und mit Begeisterung bald die ersten Projekte umgesetzt. Meine allererste Datenbank enthielt meine Kochrezepte, dieses Hobby pflege ich auch heute noch digital, schauen sie mal rein ins Inselfisch-Kochbuch.

Die ersten PCs und dBase

Die zweite Datenbank war dann schon etwas ernsthafter gestrickt, da habe ich ein Verwaltungsprogramm für eine mittelgroße Taxifirma mit dBase auf DOS programmiert. Das waren die Zeiten, als es noch Computer ohne Festplatten gab, und Floppy Disks noch floppten – Disk1 fürs Betriebssystem, Disk2 fürs Anwendungsprogramm, und immer schön aufpassen daß der RAM nicht volläuft…. aber ich schweife ab, das sind Relikte aus der Steinzeit, als IT noch EDV hieß.

Informatik studieren? Gabs damals nur als Nebenfach

Einen Studiengang Informatik gab es damals leider noch nicht (den hätte ich sofort genommen!), es wurden allerdings an sämtlichen naturwissenschaftlichen Fakultäten Computerkurse angeboten. Viel noch am Großrechner, weil Standalone-PCs damals noch unmöglich teuer waren, und die Mainframes eh an den Unis rumstanden. Ich entsinne mich an meinen ersten Programmierkurs „Standard Pascal unter Unix“, da ging die Eingabe noch über Lochkarten, und die Programm-Ausgaben erfolgten an Deckwriter-Terminals. Nix Monitore! Das kann man sich heute gar nicht mehr vorstellen, aber es hat funktioniert.

Grundlagen in strukturierter Programmierung

Vielleicht hat es mich nachhaltig geprägt, daß meine erste Programmiersprache nicht BASIC-Spaghetti war, sondern das streng strukturierte prozedurale Pascal. Was ich damals über Variable und Konstanten, über if..then..else, über do…while, Gültigkeitsbereiche von Variablen, Funktions- und Prozeduraufrufe und all diese klassischen Programmierkonstrukte aufgesaugt habe, hat mich mein ganzes Programmiererleben lang begleitet und ganz ehrlich: so viel hat sich bis heute nicht geändert . Wenn ich meine Sourcecodes von damals noch hätte, ich wette, die würde ich ohne große Änderungen auch unter PHP, Javascript oder VBA zum Laufen kriegen!

Meine zweite große Computerliebe war SQL, aber das, finde ich, verdient einen eigenen Artikel.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend