Es gibt Wochen, da läuft alles nach Plan. Kunden sind zufrieden, Projekte schreiten voran, und der Schäfer blickt zufrieden über seine Datenherde. Und dann gibt es Wochen wie diese. Nicht schlecht – aber anders als erwartet. Produktiv auf Umwegen, sagen wir mal so.
Wenn der Schäfer sein eigenes Depot hütet
Angefangen hat es mit einer simplen Frage: Wo notiere ich eigentlich meine Wertpapiertransaktionen? Excel hatte ich jahrelang genutzt, Apps habe ich getestet, und am Ende war ich bei keiner Lösung wirklich zufrieden. Zu viel Cloud, zu viele Abonnements, zu wenig Kontrolle. Also habe ich das getan, was ich am besten kann: Ich habe mir eine Lösung in Microsoft Access gebaut. Ernsthaft.
Das klingt erst mal nach einem Witz. Aber es ist keiner. Eine Access-Datenbank als persönliche Depotverwaltung ist kein Rückschritt, sondern eine bewusste Entscheidung. Die Daten liegen lokal, ich zahle keine monatliche Gebühr, und ich verstehe jede einzelne Zeile meiner Struktur. Das ist kein Nostalgie-Projekt, das ist Pragmatismus.
Die Kern-Tabellen sind schnell erklärt: Transaktionen (Kauf, Verkauf, Datum, Kurs, Stückzahl), Dividenden (Zahlung, Quellensteuer, Datum), und eine Berechnungslogik für die Performance. Für die steuerliche Seite habe ich eine FIFO-Auswertung gebaut, weil das Finanzamt gerne wissen möchte, welche Anteile zuerst verkauft wurden. Wer das jemals in Excel nachgebaut hat, weiß: Das ist keine Schönwetteraufgabe. In einer relationalen Datenbank mit sauberem Datenmodell ist es handhabbar.
Das Ergebnis ist ein Formular, das mir auf einen Blick zeigt, was ich halte, was ich gezahlt habe, was an Dividenden geflossen ist, und wie sich das alles entwickelt hat. Kein Dashboard mit bunten Animationen, aber eines, das funktioniert.
Wie trackt ihr euer Depot? Excel, eine App, gar nicht – oder auch eine eigene Lösung?
Die Herde braucht frische Daten: Externe Quellen an SQL Server anbinden
Der logische nächste Schritt nach dem Aufbau der Grundstruktur war die Frage nach aktuellen Kursdaten. Manuell Kurse eintippen ist keine Option, die ich länger als eine Woche durchhalte. Also habe ich mich diese Woche intensiv damit beschäftigt, externe Datenquellen direkt in SQL Server zu ziehen.
Konkret: Yahoo Finance, CoinGecko und Alpha Vantage liefern Kursdaten als JSON über ihre APIs. SQL Server kann damit umgehen. Der Weg dorthin führt über Linked Server oder alternativ über gespeicherte Prozeduren, die mit OPENJSON die zurückgegebenen JSON-Antworten zerlegen und in Tabellen schreiben. Ein SQL Agent Job erledigt das täglich automatisch zur gewünschten Zeit. Einmal eingerichtet, kommen die Daten einfach rein, ohne dass ich einen Finger rühren muss.
Das ist kein triviales Setup, aber es ist sauber, wiederverwendbar und vollständig unter eigener Kontrolle. Wer das einmal verstanden hat, kann das Muster auf beliebige andere APIs anwenden: Wetterdaten, Logistikschnittstellen, Lieferanteninformationen, was auch immer die Herde gerade braucht.
Was ich dabei gelernt habe: Die größte Fehlerquelle ist nicht die Technik, sondern die Datenqualität der Quellen. APIs liefern manchmal fehlende Werte, unerwartete Formate oder Ratenlimits, die einen Job stillschweigend scheitern lassen. Gute Fehlerbehandlung und ein Logging-Konzept sind kein Luxus, sondern Pflicht.
Welche externen Datenquellen habt ihr schon an SQL Server angebunden? Ich bin gespannt, was in anderen Projekten so angeflossen ist.
Fazit: Manchmal ist die eigene Lösung die beste
Diese Woche hat mich an etwas erinnert, das ich eigentlich schon weiß, aber gerne vergesse: Die beste Lösung ist nicht immer die modernste. Manchmal ist es die, die man selbst durchdringt, kontrolliert und nach eigenen Bedürfnissen anpasst. Access und SQL Server sind keine Dinosaurier, sie sind Werkzeuge. Und ein guter Schäfer sucht sich das Werkzeug, das zur Herde passt, nicht das, das gerade auf dem Markt beworben wird.
Die Woche war unplanmäßig produktiv. Der Schäfer zieht den Hut, bevor er ihn wieder aufsetzt und weiterzieht.



