alte Hassliebe

Lange habe ich überlegt ob ich hier auf dem Spielplatz eine andere alte Liebe vorstellen soll - wo sie doch eher auf den Friedhof gehört. Sind wir mal ehrlich - schon vom Grundsatz her - ist die alte Dame heute aus der Zeit gefallen.

Als klassische Client-Server Anwendung ist Sie auch denkbar unattraktiv - schon die Optik ist nicht die einer "APP". (Wenn man meine unqualifizierte Meinung mal hören möchte...Mein Eindruck: Wir haben 10Jahre versucht Internetseiten wie Desktopanwendungen aussehen zu lassen - dann 10 Jahre Desktopanwendungen wie Webanwendungen... naja zuletzt muss alles aussehen wie eine web. Dann sitzen wir im Büro und wischen ständig über den Monitor - naja, wird der auch gleich sauber).

Für viele Benutzer ist auch  die (gleichzeitige) Darstellung der Artikelvarianten schon zu viel. Das hat meins Erachtens heute auch etwas mit der Konditionierung auf maximale 6" Smartphone-Displays zu tun.

Diese Darstellung folgt aber durchaus der Datenstruktur. Ausgangspunkt für die angelegte Struktur war ein variantenreicher Artikel wie man ihn gerade bei Textilien (aber durchaus anderen Artikeln) findet. Neben der Vielzahl der Varianten haben diese Artikel meist auch eine besondere Struktur. Bei einer geschickten Datenstruktur und Stammdatenanlage lässt sich dieser Umstand dazu nutzen erheblich. 

Beispiel (Schematisch):

Ok, Joomla und das Template haben mir wieder die Tabelle zerkloppt - aber Hey - ich rege mich nicht mehr auf...

Exkurs: Relationale Datenbanken und OOP/OOD

Es gibt immer wieder Situationen da bekomme ich Pickel...besonders, wenn mir besonders gebildetes Jungvolk etwas erzählen will was unglaublich modern klingt. Es ist Teilweise zum heulen.... Ich erkläre es mal an meiner alten Auftragsbearbeitung/Warenwirtschaft.

 Es gibt einen "Hauptartikel" den nennen wir mal "Hans"  Hans steht jetzt mal ganz unten auf der Leiter. Hans hat eine ganze Reihe von Eigenschaften (Auswahl):

• Einen Hersteller
• Er gehört einer best. Artikelgruppe an (Hose, Hemd, Autoreifen, Oberbekleidung - eine eher lose Zuordnung)
• weitere auf dieser Ebene sinnvoll zu platzierende Eigenschaften

Ein erste Variante des Hauptartikels ist der - ich nenne s mal "Farbartikel". Oft wird dieser "Farbartikel" - die Variante gehandhabt wie ein weitere Eigenschaft des Hauptartikels. Vor vielen Jahren habe ich aber schon praktisch erfahren, dass dies eine suboptimale Handhabung handelt. Deshalb jetzt mal dem Gedanken folgen... Auf dem Niveau des Farbartikels lassen sich weitere Eigenschaften zuordnen, die wohl alle Artikel dieser Variante betreffen - nicht aber alle anderen Mitglieder des Hauptartikels. Ein Beispiel könnte sein:

• Materialzusammensetzung
• die physische Farbe (daher meine Begriffswahl)
• weitere Eigenschaften - wie z.B. die Angebotenen Größen

Oben auf dem Baum findet sich dann dass, was sich gemeinhin dann als Artikel im Handel findet, also z.B. dass, was an der Kasse mit dem selben EAN gescannt wird. Typische Eigenschaften auf der Ebene wären im Beispiel

• Die Größe
• der EAN-Code
• Der VK

Wir haben also soetwas wie einen Artikelbaum mit dem Stamm:

Hauptartikel_________ ;Eigenschaften (A)

                                   |
                                   |

                             Farbartikel______________; Eigenschaften (B)

                                                                          |
                                                                          |

                                                                     EAN-Artikel________________;Eigenschaften (C)

Wo ist denn nun der oft leichtfertig aufgeworfene Widerspruch zwischen relationalen Datenbanken und einem Objektansatz? Im Gegenteil: Die hier bei einer Normalisierung zu beachtenden (und eben zu vermeidenden)  Redundanzen könnte man auch, als von Stufe zu Stufe, vererbte Eigenschaften einer Klasse ansehen.

Schaut man in die weiter Oben dargestellte (und von Joomla ziemlich verhunzte) HTML-Tabelle würde sie so eine Sicht er Tabellen mit nicht redundanter Daten darstellen .

Das Aussehen - das heute vielleicht etwas Angestaubt ist, ist dem Werkzeug "Powerbuilder" und dessen "Datawindows" (Link führt auf eine Beschreibung auf der SAP Seite).

Diese "Datawindows" sind die mächtigsten Zugriffsobjekte für Datenbankanwendungen die ich je kennengelernt habe.  

Ich habe den Powerbuilder kennengelernt , als er in den Händen von Sybase war, so um das Jahr 2000 herum...ein schnelleres Tool zur Entwicklung Kaufmännischer Anwendungen ist mir nicht untergekommen.

Nie verstanden habe ich hier die Vertriebsidee hinter dem Werkzeug. Einerseits war es nicht im engeren Sinne "geheim" aber andererseits ist - trotz zwischenzeitlicher nicht unerheblicher Verbreitung - kaum Literatur auf dem Markt. Ein einziges englisch sprachiges Buch zu Powerbuilder 7 nenne ich mein eigen - viel mehr war damals auch nicht erschienen und schon damals waren die Entwicklerlizenzen nicht wirklich einsteigerfreundlich ... Meine erste - nagelt mich nicht fest - für die "Enterprise Edition" - die ich als Selbsttändiger damals noch gekauft habe kostete so ca. 2500,-€ für einen Entwickler. Heute bietet Appeon ein Paket für $895/Jahr an, dass wohl heute das Äquivalent wäre (?) - was preislich nicht weit davon entfernt ist (auch damals brauchte man alle paar Jahre ein Update) . 

Der Unterschied in der Lizenzierung fällt deshalb kaum in's Gewicht, da MS & Co allein durch die Betriebssystem dafür sorgen, dass man ein Werkzeug spätestens nach 2 Jahren ... äh... archivieren kann.

Interessant:

Das letzte kommerziell eingesetzte "Kompilat" meiner Software war auf Windows 7 getestet und lief mit MSSQL Server 2008r (... ein weiteres Problem bei der Entwicklung die verschiedenen Datenbanktreiber)  läuft heute "so zum Spaß aber auch noch unter Windows 10)

... Ach so.. zurück zum Text...

Die Struktur der hierarchischen Artikel  unterstützt nicht nur  - gerade in der relationalen Speicherung - ein OOD, welches "Methoden" unterstützt, die man "Farbe  hinzufügen" oder "Größe hinzufügen"  nennen könnte. Das meiste was ich auf Objektdatenbanken gesehen habe war und ist zum Scheitern verurteilt (meine Meinung).

Nebenbei:

Klassen die den Datenbankzugriff erlauben sind schon in den 90'ern entsprechend verkapselt... was wollen wlle von mir?