Tag: "query"
Die effektive jährliche Verzinsung
Beliebt sind (oder besser gesagt, waren) diese Informationen bei Kreditangeboten aller Art. Einen monatlichen Zinssatz durch die Multiplikation * 12 in einen jährlichen umzurechnen, ist zur gleichen Zeit richtig und doch nicht. Auf diese Weise erhält man nur den Nominalzins. Der sogenannte Zinseszinseffekt kann aber für eine in der Regel weniger erfreuliche Überraschung sorgen. Berücksichtigt man diesen Effekt erhält man den Effektivzins. Dieser liegt umso höher, je mehr Zinszeitpunkte in einer Periode eintreten. Wie man jetzt genau von Nominalzins zum Effektivzins gelangt, ist zu einem guten Teil auch der Kreativität der Mathematiker überlassen. Da gibt es viele verschiedene Methoden, die z.B. mit der exakten Anzahl der Tage rechnen, oder vereinfachend mit 30/360er Regeln und, und... Ferner muß man überlegen, ob und inwieweit Bearbeitungskosten und sonstige Nebenkosten eingerechnet werden oder nicht. All dies interessiert aber hier an dieser Stelle nicht. Wir betrachtet hier einen einfachen Fall.
Beispiel: Die Firma "Wir nehmen's nicht so genau mit der Angabenpflicht unser Kreditangebote GmbH & Co. KG" wirbt mit dem Angebot für nur 1,55% Zinsen pro Monat all die kleinen Konsumwünsche zu erfüllen, auf die man sonst evtl. verzichten müßte. Ferner steht im Angebot eine Angabe zum jährlichen Zins iHv. 18,6%. Da man heutzutage (meint ;-) ) immer mehr repräsentieren zu müssen, um nicht ins gesellschaftliche Abseits, besuchen wir das Büro dieser Firma um einen Kreditvertrag über eine Summe von 10.000 € abzuschließen. Als es dann zur Unterschrift geht, haben wir das Geld zwar schon mental ausgegeben, zum Glück aber nichts an den Augen, als wir über eine Rückzahlungssumme von insgesamt 12.027,05 € in einem Jahr stolpern. Unserer Meinung nach sollte da ein Betrag ihV. 11.860 € stehen. Also über 167 € weniger oder etwas mehr als 1%. Wir verlassen empört das Büro und bauen uns folgendes SQL Statement, um nie wieder auf soetwas herein zufallen.
DECLARE @apr FLOAT
DECLARE @frequency FLOAT
SELECT @apr = 18.6, @frequency = 12
SELECT 100 * (POWER((1 + ((@apr/100)/@frequency)), @frequency)-1) AS EAR
EAR
-----------------------------------------------------
20.270504548765487
(1 row(s) affected)
Als Input wird der jährliche Nominalzins und die Anzahl der Zinszeitpunkte pro Periode angegeben. Da wir einen monatlichen Zins unterstellen, fallen also 12 Zinszeitpunkte in einem Jahr an. Wie bereits schon oben erwähnt, ist dieses Beispiel sehr einfach und kann beliebig variiert und kompliziert werden. Es sollte aber recht gut den Unterschied zwischen beiden Zinsangaben zeigen.
Speichern von Formeln in Spalten
Wie könnte es aussehen, wenn man in einem so dynamischen Umfeld arbeitet, daß man selbst die mathematischen Berechnungsformeln nicht hart kodieren will...
Kleines Beispiel über COUNT()
Unter den diversen Aggregatfunktionen des T-SQL Arsenals nimmt COUNT() einen einmaligen Platz ein, weil dies die einzige Funtion ist, die "NULL-aware" ist. Das heißt, je nach Verwendung werden NULL Marker berücksichtigt oder nicht.
Vorsicht bei der Verwendung von ISNUMERIC()
Liest man sich die Onlinehilfe von SQL Server durch und gelangt an das Thema ISNUMERIC(), erhält man den Eindruck, daß dies eine einfache, schnelle und sichere Methode ist, um zu überprüfen, ob ein gegebener Ausdruck in einen von SQL Server unterstützten numerischen Datentypen umgewandelt werden kann. Also, in einen der Datentypen: INTEGER, FLOAT (REAL), DECIMAL (NUMERIC) und MONEY.
Werte in aufeinanderfolgenden Zeilen subtrahieren
Zunächst vielleicht erst einmal eine Erklärung, was hier überhaupt beschrieben werden soll. Mal angenommen, wir haben eine Tabelle, in der Kurse einer Aktie erfaßt werden. Der Einfachheithalber konzentrieren wir uns hier nur auf die entscheidenden Spalten Datum und Kurs und ignorieren alles weitere hier.
BCP Ausgabe mit Spaltenüberschriften
Schon mal darüber geärgert, daß es keine Möglichkeit gibt, die Spaltenüberschriften im BCP Utility mit auszugeben...?
Teilstrings gleicher Länge extrahieren
Extrahieren von Teilstrings aus z.B. einer kommaseparierten Liste kann man überall nachlesen. Für Fragestellungen, bei denen es um die Extraktion von Teilstrings stets gleicher Länge geht, kann man aber auch einen anderen Lösungsansatz verwenden.
JOIN Stolperfallen Teil 1
Gelegentlich fragt man sich, ob man wirklich so oft auf die Tastatur hämmern muß, oder ob man sich nicht das eine oder andere Zeichen oder Wort sparen kann. Klingt bekannt? Nun, zumindest mir geht es so. Generell ist das auch so in Ordnung, nur manchmal kann man dabei auch auf die Nase fallen. Wenn dann noch eine merkwürdige Syntaxauslegung ins Spiel kommt, wird es richtig interessant. Beispiel:
SELECT r.royalty , t.title , t.type , t.price FROM roysched r INNER JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Die Ergebnismenge wird hier nicht wiedergegeben. Das obige Beispiel läßt sich folgendermaßen "vereinfachen":
SELECT r.royalty , t.title , t.type , t.price FROM roysched r JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Das INNER Schlüsselwort kann man weglassen, da der INNER JOIN der Standard JOIN Type des SQL Servers ist. So weit, so gut!
Schaut man sich den Ausführungsplan an, sieht man, daß SQL Server NESTED LOOPS verwendet. Nun sind NESTED LOOPS gerade bei umfangreichen Abfragen nicht gerade optimal und darum kommt man vielleicht auf die Idee, den Server einen kleinen Hinweis mit auf den Weg zu geben, wie er den JOIN verarbeiten soll. Also schreibt man:
SELECT r.royalty , t.title , t.type , t.price FROM roysched r MERGE JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Was passiert?
Server: Nachr.-Nr. 170, Schweregrad 15, Status 1, Zeile 8 Zeile 8: Falsche Syntax in der Nähe von 'MERGE'.
Was soll das denn jetzt? Sieht doch syntaktisch einwandfrei aus. Ein Blick in BOL bestätigt dies. Warum also wird das Statement nicht ausgeführt???
Der Grund liegt darin, daß SQL Server bei der Verwendung des MERGE Hinweises (oder jedes anderen JOIN Hints) zwingend auf das INNER Schlüsselwort besteht. Ohne dem geht hier gar nichts. SQL Server ist hier nicht in der Lage, den INNER JOIN als Standard JOIN Typ anzuwenden. Also doch wieder ein paar Mal mehr auf die Tastatur hämmern
SELECT r.royalty , t.title , t.type , t.price FROM roysched r INNER MERGE JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Ah, unsere 86 Zeilen kommen zurück und der Ausführungsplan zeigt den MERGE JOIN an. "By design", also nicht wundern oder nachfragen.
