Zum Inhalt springen

Effektive Datenbankstruktur


mousepad

Empfohlene Beiträge

Hallo,

bisher mussten meine Datenbanken nicht superschnell sein. Jetzt jedoch, sollen viele Daten gespeichert werden und später mit diesen gerechnet werden.

Ich möchte Quotenverläufe bei betfair z.B. bei Pferderennen speichern. Alle 5 Minuten sollen von allen Pferden eines bestimmten Rennens die Quoten gespeichert werden. Zu JEDEM Zeitpunkt und JEDEM Pferd gehört eine "Quotentabelle", die z.B. so ausschaut:

QUOTE-BACK-LAY-UMSATZ

2.20 €4 €1,417

2.22 €97 €602

2.24 €231 €1,060

2.26 €380 €1,703

2.28 €116 €2,959

2.30 €322 €9,130

2.32 €180 €8,697

2.34 €625 €6,015

2.36 €63 €4,938

2.38 €80 €4,389

(d.h. ich kann z.B. bei einer Quote von 2.26 auf das Pferd wetten und es werden Wetten dieser Art im Umfang von 116 EUR angeboten(backen)

oder: jemand will zur Quote 2.30 wetten und ich kann als Buchmacher auftreten(layen).)

Dabei ist die Anzahl der verschiedenen Quoten sowie die Quoten selbst natürlich variabel.

Später sollen dann verschiedene Indikatoren berechnet werden, sodass meist Quoten/Volumen/Umsätze von einem bestimmten Pferd und einem bestimmten Zeitpunkt(oder mehreren aufeinanderfolgende) miteinander verechnet werden.

Wie gestalte ich nun die Datenbankstruktur, sodass zu jedem Zeitpunkt und Pferd eine "Quotentabelle" abgespeichert wird und die Berechnungen danach nicht zu lange brauchen?

Ich danke schon im vorraus,

mousepad

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo,

ich speichere die Daten bisher noch garnicht. Diese Daten können über einen Web Service von betfair abgefragt werden. Dabei erhält man alle "Quotentabellen" von allen Pferden eines Rennens als codierten String zurück.

Ich möchte es bei diesem Projekt eben gleich von Anfang an "richtig" machen, sodass das Berechnen von Indikatoren(s. mein erster Post) schnell geht.

Als Datenbank wollte ich eigentlich MySQL benutzen, weil ich damit schon Erfahrungen habe, diese mit C++ zu benutzen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Zu JEDEM Zeitpunkt und JEDEM Pferd gehört eine "Quotentabelle", die z.B. so ausschaut

Meinst du damit, dass du die Daten so erhältst, oder dass du dir in deiner DB wirklich für jeden Abfragezeitpunkt eine neue Tabelle erstellen willst?

Falls letzteres zutrifft klingt das für mich ziemlich falsch für Datenbanklayouts.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo,

wie sieht denn überhaupt die Struktur der gelieferten Daten aus?

Ich kann mir den Aufbau der Daten aus dem Webservice noch nicht so ganz vorstellen.

Für jedes Pferd eine Tabelle zu erstellen ist wie FinalFantasy schon gesagt hat natürlich völlig daneben. Daher müsste man eben wissen welche Daten ankommen und in welcher Struktur.

Vielleicht mal einen Beispieldatensatz?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Vielleicht mal einen Beispieldatensatz?

Steht doch im Ursprungspost!

Ich kenne mich weder mit Wetten noch mit dem Quotenzeug aus, deshalb kann ich kein sinnvolles DB-Layout vorschlagen, aber ein Datenbanklayout, welches immerwieder neue Tabellen anlegt, ist prinzipiell schonmal falsch.

Da mir aus dem ersten Post nicht ganz klar wurde, ob der Fragesteller sich damit nur auf das Format der eintreffenden Daten bezog, oder ob er darauf auch schon sein DB-Layout aufbauen wollte, habe ich nur mal darauf hingewiesen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Steht doch im Ursprungspost!

Das denke ich nicht. Denn hier steht weder etwas von einem Pferd (für jedes Pferd eine Tabelle) noch etwas von einem Rennen (für jedes Rennen und jedes Pferd eine Tabelle).

Wo steht der Name (oder Numemr) des Pferdes oder des Rennens.

Irgendwie muss ich diese Tabelle ja einem Pferd und einem Rennen zurodnen können.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Vielleicht könnte es in etwas so aussehen

.netter-albums-pictures-picture184-quote.png

Die Übertragungsnummer kann man zur Identifizierung des Laufs (Du bekommst ja alle 5 Minuten eine Tabelle) nutzen.

Ich weiß nicht ob Du alle Quotentabellen eines Rennens für ein Pferd speichern willst oder immer nur die Letzte.

So hast Du die Wahl alle zu speichern oder anhand der Übertragungsnummer "veraltete" Sätze gleich zu löschen und somit wieder Platz zu sparen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo,

danke für die Beiträge bisher. Ich möchte natürlich keine alten Daten wieder löschen. Was haltet ihr von folgenden Entwurf?

Tabelle 1: RENNEN mit den Spalten

Re_ID als INT AUTO_INCREMENT PRIMARY KEY

RENNEN

PFERD

Tabelle2: QUOTEN mit den Spalten

QUOTEN_ID als INT AUTO_INCREMENT PRIMARY KEY

RE_ID als foreignkey auf Re_ID

ZEIT_ID als INT

ZEIT als DATETIME

QUOTE

BACKVOLUMEN

LAYVOLUMEN

UMSATZ

mit einem Index über (QUOTEN_ID,ZEIT_ID). Ich würde ZEIT_ID einführen um jeweils den nächsten Zeitpunkt zu erwischen, da es ja stest zu leichetn Verzögerungen kommt und so ZEIT des nächsten Datensatzes nicht genau feststeht.

EDIT: Entschuldigung .NETter, ich habe deinen Beitrag übersehen und schau mir erst deinen Etwurf an.

Bearbeitet von mousepad
Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...