Handicap-Wetten

Informieren Sie sich über die Bedeutung von Handicap-Wetten, die Funktionsweise und die verschiedenen Arten von Handicap-Wetten bei Pinnacle. Lesen Sie weiter, um ein Experte für Handicap-Wetten zu werden.

Im Fußball wie im gesamten Leistungssport gibt es normalerweise einen Unterschied in der wahrgenommenen Qualität der gegnerischen Mannschaften; die Größe dieses Unterschieds variiert in Abhängigkeit von einem komplexen Spektrum von Einflüssen, das von historischer Dominanz und finanzieller Unterstützung bis hin zu situativen Faktoren wie Heimvorteil oder Verletzungen/Verfügbarkeit der Spieler reicht. Fußball-Wetten interpretiert diese Faktoren und stellt sie als Erfolgschancen für jede Seite in Form von Quoten dar.

Handicap-Wetten erklärt

Wo der wahrgenommene Unterschied in den Fähigkeiten signifikant ist, sind die Wettquoten auf den Favoriten so gering, dass er minimale Renditen und damit wenig Anreiz für die Wettenden bietet.
Um der wahrgenommenen Verzerrung der Fähigkeiten entgegenzuwirken und um ausgewogenere und ansprechendere Quoten zu bieten, bieten Buchmacher so genannte Handicap-Wetten an. Im Kontext des Fußballs gleichen die Handicap-Quoten das Spielfeld aus, indem sie den Unterschied in der wahrgenommenen Stärke der Teilnehmer berücksichtigen, indem sie buchstäblich ein Torhandicap – positiv und negativ – auf jede Seite anwenden. Dies gibt Wettern die Möglichkeit, mehr Wert zu finden, als wenn sie einen schweren Favoriten in der traditionellen 1X2-Wette unterstützen – die häufigste Art, auf Fußball zu setzen.

Das Handicap wird auf das tatsächliche Ergebnis des Spiels angewendet, um die Wette zu bewerten (Ergebnis). Es gibt drei Arten von Handicap-Wetten, die Sie vor dem Wetten beachten müssen:

Niveau Handicap

Ein Handicap ist ein Level, bei dem es keinen Unterschied in den Fähigkeiten zwischen Team X und Team Y gibt, so dass kein Handicap-Bias zugewiesen wird und beide Teams mit 0 Toren starten.

Um eine Wette zu gewinnen, muss der Wettende die Mannschaft identifizieren, von der er glaubt, dass sie mehr Tore erzielt als sein Gegner. Diese Art von Handicap ist für einseitige Begegnungen nicht relevant, ist aber insofern nützlich, als es das Unentschieden eliminiert; wenn das Spiel mit einem Unentschieden endet, werden alle Wetten zurückerstattet, da bei einem Handicap von Null kein Team einen Vorteil hat. (Quelle: www.sportwetten24.com )

Einzelnes Handicap

Ein einzelnes Handicap tritt auf, wenn ein Unterschied in den Fähigkeiten zwischen Team X und Team Y wahrgenommen wird.

Die vermeintlich überlegene Mannschaft erhält ein angemessenes Torhandicap, um das Spielfeld für Wettzwecke auszugleichen, d.h. -0,5 Tore, -1 Tore, -1,5 Tore etc.

Zum Beispiel, wenn Sie auf Team X mit einem Handicap von -1 Tor setzen, müssen sie mit mehr als einem Tor gewinnen, um ihr Handicap zu decken und Ihre Wette zu gewinnen.

Wenn sie nur mit einem Tor gewinnen, ist das Ergebnis mit dem angewandten Handicap ein Unentschieden, so dass Ihre Wette zurückerstattet wird. Wenn Team Y zieht oder gewinnt, verlieren Sie Ihre Wette auf Team X. Den passenden Wettanbieter finden Sie hier.

 

cookie based redirect mit lighttpd

Alle unsere Entwickler haben eine komplett eigene Entwicklungsumgebung inkl. WebServer installiert. Manchmal ist es praktisch den aktuellen Entwicklungsstand am Checkout eines Entwicklers zu sehen. Anstatt für jedes Projekt und jeden Entwickler eine interne Subdomain einzurichten, kann man viel praktischer einen zentralen Reverse Proxy nutzen, der anhand einer Cookie Einstellung den Host des jeweiligen Entwicklers auswählt:

$SERVER["socket"] == "10.0.0.20:80" {
    ...
    $HTTP["host"] =~ "^.*\.devcenter.int$" {
        $HTTP["cookie"] =~ "(; )?devredirect=harald" {
            proxy.server = (
                "" => (("host" => "10.0.0.20", "port" => 8080))
            )
        }
        $HTTP["cookie"] =~ "(; )?devredirect=markus" {
            proxy.server = (
                "" => (("host" => "10.0.0.22", "port" => 8080))
            )
        }
    }
}    

Die oben gezeigte Konfiguration installiert einen Reverse Proxy für Subdomains von ‘devcenter.int’ — z.B. ‘clipdealer.devcenter.int’. Über das Cookie ‘devredirect’ kann spezifiert werden, welcher Host angesprochen werden soll.

MongoDB + PHP + OSX

Ich spiele gerade ein wenig mit Mongo DB. Da ich das die Tage sicherlich noch mal gebrauchen kann, mache ich mir hier mal ein paar wichtige Notizen zur Installation:

  • Der Aktuelle PHP Treiber ist nicht kompatibel zum aktuellen stable Release (0.8.0) auf der Mongo DB Seite. Deshalb muss ein daily-build von Mongo DB heruntergeladen werden. Am besten lädt man hier das Paket inkl. aller Tools und Treiber (beinhaltet auch den Source der PHP Erweiterung). Mongo DB also herunterladen und irgendwohin installieren (z.b. /opt/mongo).
  • Zum Compilieren des PHP Treibers benötigt man die Boost C++ Libraries. Beim Compilieren der Boost Libraries wurden die Namen der Bibliotheken derart angelegt, dass sie beim Compilieren des PHP Treibers von Mongo DB nicht gefunden werden konnten. Deshalb habe ich nach dem ./configure --prefix=/opt/boost von Boost die Datei Makefile editiert und die Zeile BJAM_CONFIG= nach BJAM_CONFIG='--layout=system' geändert.
  • Nachdem Boost Installiert wurde, lässt sich nun der Mongo DB Treiber compilieren. Bei mir befindet sich der PHP Treiber unterhalb des Verzeichnisses /opt/mongo/drivers_and_tools/mongo-php-driver. Ein phpize, ./configure --with-mongodb=/opt/mongo/ --with-boost=/opt/boost/, make, make install und der Treiber ist gebaut und installiert.

Eigentlich ganz einfach … aber ich vergesse es sonst garantiert wieder :-)

ORMs sind doof

Objektrelationale Abbildung (englisch object-relational mapping, ORM) ist eine Technik der Softwareentwicklung, mit der ein in einer objektorientierten Programmiersprache geschriebenes Anwendungsprogramm seine Objekte in einer relationalen Datenbank ablegen kann. Dem Programm erscheint die Datenbank dann als objektorientierte Datenbank, was die Programmierung erleichtert. […]

Inzwischen bringt ja so ziemlich jedes PHP Framework seine eigene ORM Implementierung mit, es gibt aber auch einige Framework-unabhängige ORM Implementierungen. Ich habe mir in den letzten Jahren immer mal wieder verschiedenste ORM Implementierungen angesehen — immer dann, wenn in mir der Wunsch nach einer objektorientierten Zugriffsweise auf meine Datenbanken aufkam. Leider jedoch konnte mich bisher keine ORM Implementierung überzeugen.

ORMs sind doof

Auch in mir kommt immer mal wieder der Wunsch auf objektorientiert auf meine Datenbanken zuzugreifen, da dies den Zugriff auf einzelne Datensätze — Objekte — erheblich vereinfacht. Jedoch — zu welchem Preis wird diese Vereinfachung erkauft?

Modellierung

Ich modelliere meine Datenbanken schon seit Jahren mit dem ER Modeller dbWrench. Das ist meiner Meinung nach super komfortabel. Ich sehe auf einen Blick all meine Tabellen und die Abhängigkeiten bzw. Verknüpfungen zwischen einzelnen Tabellen. Über die Funktion “Forward Engineering” kann dbWrench mein Datenbankschema in der Datenbank immer aktualisieren. Da ich bei MySQL den Tabellentyp InnoDB verwende, sind auch in der Datenbank sämtliche Verknüpfungen festgehalten und liessen sich z.b. über die INFORMATION_SCHEMA Tabelle leicht auslesen.

Nun ist es leider so, dass offenbar so ziemlich jede ORM Implementierung die Datenbankdefinition auf Ihre Weise bekommen möchte. Da muss man entweder seitenweise XML oder YAML Konfiguration, oder gar ellenlangen PHP Code schreiben — nur um der Anwendung eine Information bekannt zu geben, die eigentlich exakt so schon in der Datenbank vorhanden ist?

Abstraktion

Wie weit muss man die Datenbankzugriffe abstrahieren? Nun, es gibt da sicherlich die verschiedensten Anforderungen. Ich denke bei der Entwicklung von Unternehmenssoftware kann man die Anforderungen ziemlich genau spezifizieren. Man entscheidet sich zu einem gewissen Zeitpunkt für ein bestimmtes Datenbankprodukt. Normalerweise wird diese Entscheidung nicht nach wenigen Monaten oder Jahren über den Haufen geworfen — es sei denn es gibt sehr triftige Gründe dafür.

Deshalb bin ich der Meinung, dass die Abstraktion nicht so weit gehen muss, dass sämtliche Datenbankzugriffe abstrahiert werden und für beliebige Datenbanksysteme geeignet sind. Im Gegenteil: ich entscheide mich ja nicht für eine bestimmte Datenbank nur aus Kostengründen, sondern auch, weil diese vielleicht Features mitbringt, die ein anderes Datenbanksystem nicht unterstützt.

So erweitert z.b. MySQL den SQL Standard um eigene spezifische Befehle, die es in anderen Datenbanken nicht gibt, die aber sehr praktisch sind. Das ist kein Alleinstellungsmerkmal von MySQL. Beispiel: Hätte ich mich für Oracle entschieden, wäre ich doch dumm, würde ich zum Abbilden / Abfragen von Hierarchischen Strukturen nicht CONNECT BY verwenden — nur weil dies nicht Teil des SQL Standards ist und dies so mit keiner anderen Datenbank funktioniert.

Nur: keine ORM Implementierung kann auf diese einzelnen Datenbankfeatures eingehen — womit ich beim nächsten Punkt angelangt wäre.

Abfrage

Das grösste Manko aller (PHP) ORM Implementierungen ist meiner Meinung nach die Abfrage einer Datenbank. Ich gebe zu: ich mag SQL — es gibt mir das passende Werkzeug zum Abfragen einer relationalen Datenbank in die Hand — es wurde zu diesem Zweck entwickelt! Ich schreibe gern SQL, da es strukturiert und übersichtlich ausschaut und mich schnell zum Ziel führt. Ich gebe weiterhin zu: Ich nutze auch gern MySQL spezifische SQL Features — aus den oben genannten Gründen.

Nun ist es jedoch so, dass die ORM Implementierungen in der Regel den Zugriff soweit abstrahieren, dass — normalerweise — kein SQL mehr geschrieben wird. CONNECT BY und ähnliche Dinge wären damit Unmöglich. Heutzutage hat sich folgende Schreibweise zum Erstellen von Datenbankabfragen etabliert:

$dbo
->select(array(
‘media.media_id’, ‘media.media_name’, ‘member.member_name’, …
))
->from(‘media’)
->join(‘member’, ‘member.member_id = media.member_id’)
->where(‘media.category_id = ?’)
->order(‘media.media_id’)

Ich bin kein Fan einer solchen Schreibweise:

Es ist kein SQL ;-)
Es ist wesentlich mehr Aufwand als beim Schreiben von SQL erforderlich
Ich kann keine Datenbankspezifischen SQL Erweiterungen verwenden
Ich habe keine Kontrolle darüber, welchen SQL Code die ORM Implementierung daraus generiert
Es liegt in der Natur der Sache, dass ein derartiges Konstrukt niemals auch nur annähernd so performant sein kann wie ein simples SQL Statement übergeben an die Datenbank
Ich kann das Statement nicht per Copy / Paste zwischen meinem Datenbank Client und der Anwendung hin und her kopieren — praktisch, wenn man das ganze erstmal testen will
Wenn ich den Datenbanktreiber einer nicht-relationalen Datenbank hinterlege, weil ich mich z.b. entscheide statt MySQL MongoDB anzusprechen, wird diese Schreibweise ohnehin ad Absurdum geführt. (Nur als beispiel — ich weiss nicht, ob irgendeine PHP ORM Implementation überhaupt nicht-relationale Datenbanken unterstützt)

Natürlich bietet so ziemlich jede ORM Implementierung einen Fallback zur Herkömmlichen Absetzung von SQL Anfragen ohne ein Objekt-Mapping. Nur, wenn ich damit an einer Stelle in meiner Anwendung anfange: warum dann überhaupt eine derartige Abstraktion nutzen?

Fazit

Meiner Ansicht nach erkauft man sich den konsequenten Einsatz eines ORM zu einem zu hohen Preis. Deshalb habe ich den Einsatz eines solchen für mich immer wieder verworfen. Mein Wunsch wäre ein SQL -> Objektmapper. D.h.: Ich schreibe SQL, zurück bekomme ich Objekte, mit denen ich weiterarbeiten kann …