Trade Statistik Sheet

      Was spricht dafür?

      Es muss dann halt jeder Access installiert haben(ist nicht gratis meines Wissens). Nachdem jeder was anderes will - Spreadsheet oder nicht, Standalone Anwendung oder nicht, Programmiersprachen, Betriebssystem, R, wasweisich - finde ich sqlite als kleinsten gemeinsamen Nenner nicht so schlecht. Mir fallen auch noch 5 andere Mini-Datenbank-Systeme ein, mangels konkretem Projekt ist es halt schwer zu sagen, welche die am besten geeignetste wäre. Ich persönlich würd auch lieber was anderes verwenden(db4o, aber damit beschränkt man sich auf java und .net Leute).

      Purri schrieb:

      Fehlt noch was wichtiges?

      Wie wäre es, den ursprünglich angestrebten Ausstieg noch mit anzugeben ? Dann könnte man das Tool gleich noch mit dazu missbrauchen, die Optimalität von Ein- und Ausstieg zu bestimmen. (Ich glaube, Investoxx kann das auch.)

      Aber das kann man natürlich auch als optional annehmen und muss nicht zwingend in die Grundausstattung.



      Ich werde übers Wochenende mal ne Liste erstellen mit allen Performance-Kennzahlen plus -darstellung und -berechnung, die mir (und Google) so einfällt, dann könnt Ihr das ab Montag gerne ergänzen.
      Hallo,

      hier untenstehend mein Vorschlag. Ist denke ich recht einfach und selbsterklärend, ein Table mit Informationen über die gehandelten Instrumente, die von den einzelnen Trades referenziert werden. Die Tables können ja individuell erweitert werden (Screenshot Daten etc.), aber sowas könnte man als kleinsten gemeinsamen Nenner verwenden.

      Aufgrund der schwachen Typisierung von SQLite müsste man sich noch auf ein gemeinsames Datums/Zeit-Format (und Margin-Typen/Symbol-Typen) einigen, um untereinander kompatibel zu bleiben.

      Fehlt noch was wichtiges?

      Quellcode

      1. CREATE TABLE [Symbols] (
      2. [Symbol] TEXT PRIMARY KEY NOT NULL,//Symbolname
      3. [QuoteCcy] TEXT NOT NULL,//Währung, ISO-Code
      4. [SymType] TEXT NULL,//Typ, z.B. FX/Bond/Future etc.
      5. [MinTickSize] FLOAT NOT NULL,//kleinste Preisänderung, z.B. EUR/USD 0.00001
      6. [SigDigits] INTEGER NOT NULL,//Signifikante Nachkomma-Stellen, z.B. EUR/USD 4
      7. [PriceMultiple] INTEGER NULL,//für Futures
      8. [MarginType] TEXT NULL,//Prozent oder Fix-Betrag
      9. [MarginValue] FLOAT NULL,//Margin-Anforderung
      10. [Exchange] TEXT NULL //Börsenplatz/Broker
      11. );
      12. CREATE TABLE [Trades] (
      13. [Id] INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
      14. [Symbol] TEXT,//Symbolname, Foreign Key
      15. [Quantity] INTEGER NOT NULL,//Positionsgrösse, negativer Wert für Short-Position, positiv für Long
      16. [EntryPx] FLOAT NOT NULL,//Einstiegspreis
      17. [EntryDT] TEXT NOT NULL,//Einstiegs-Zeitpunkt, würde vorschlagen ISO-String, UTC
      18. [ExitPx] FLOAT NOT NULL,
      19. [ExitDT] FLOAT NOT NULL,
      20. [InitialStopPx] FLOAT,//Anfangs-Stop Preis
      21. [PnL_Cash] FLOAT NOT NULL,//PnL in Konto-Basiswährung
      22. [Brokerage] FLOAT,//Kommission
      23. CONSTRAINT [FK_Trades_Symbol_Symbols_Symbol] FOREIGN KEY ([Symbol]) REFERENCES [Symbols] ([Symbol])
      24. );
      Mit Datenbanken habe ich noch keine praktische Erfahrungen (in Bezug zum programmieren)... Mir ist es egal... SQLite ist ja auch Lizenzfrei: de.wikipedia.org/wiki/SQLite

      Hab ein Artikel gefunden wo ein bisschen auf die Technik eingegangen wird. Da wir mit unserer Projekt eher nicht in die Situation kommen, wo mehrere Treats parallel auf die Datenbank zugreifen müssen, ist SQLite ne vernünftige Lösung: ordix.de/ORDIXNews/1_2004/unix_linux_2.html
      ich raube, also bin ich....

      Purri schrieb:


      Oder gibts andere gute Gründe für MySQL?
      Meines Erachtens nicht. Ne Lite-Version würde völlig ausreichen für normale Trader. (Außer man hat 1,000,000 EAs laufen wie Henrik und scalpt auf allem, was nicht bei 3 auf dem Baum ist 24/7. 8o )

      Purri schrieb:

      Dann sollten wir als ersten Schritt ein einheitiches Table-Design erstellen. Ich mach morgen wenn ich Zeit hab einen Vorschlag.
      Super :thumbup: !



      @Fisch

      "3. Finde ich die Idee mittels SQL Statement die Menge der Trades auf eine Untermenge einzu schränken sehr gut. (Beitrag von Krümel Post 82)"

      Nee, der Vorschlag kam schon vorher von Purri, ich hab ihn nur aufgegriffen ! ;) Ehre, wem Ehre gebührt !

      oldschuren schrieb:

      Könnte mir ein loses ToolSet vorstellen. Ein Dreh- und Angepunkt sollte es geben. Die Datenbank. Wenn wir uns auf eine festlegen mit den Daten die darin gespeichert werden sollen, kann jeder mit interesse Tools schreiben, die darauf zugreifen können. MySQL ist frei, gibt gut dokumentierte Schnittstellen zu allen möglichen Programmen und ist bestimmt auch leistungsfähig genug für das Projekt.

      Darauf könnten die anderen Tools alle zugreifen wie:

      - Datenimport von xxx-Tradehistorie >> in die Datenbank
      - Datenexport von Datenbank >> in XML, CRV, andere Datenbankformate, Steuererklärung ect.
      - Auswertungen von allgemeinen Kennzahlen bis zu umfangreichen grafischen Darstellungen der Trades
      Gute Idee. Dann sollten wir als ersten Schritt ein einheitiches Table-Design erstellen. Ich mach morgen wenn ich Zeit hab einen Vorschlag.

      Ad MySQL: wenns nach mir ginge, würd ich eher SQLite nehmen, damit kommen ebenfalls alle gängigen Sprachen zurecht. Hab irgendwie keine Lust eine riesen Datenbank-Umgebung extra für so ein Mini-Projekt zu installieren und konfigurieren. Oder gibts andere gute Gründe für MySQL?
      Da ich ein großer Anhänger des KISS Gedankens bin, könnte ich mich mit dem unten zitierten Stand schon sehr anfreunden.
      Denn wenn es Möglichkeiten zur Weiterentwicklung gibt, muss man nicht schon jetzt alle zukünftige Wünsche klären.

      Wir sollten, Krümels Vorschläge erst einmal zu Ende diskutieren. Ich meine das Sachliche, nicht die Tools wie DB und Sprachen etc...
      Danach das womit und wer! :)
      "Erfahrung ist das, was Du bekommst, wenn Du nicht bekommst, was Du willst." Randy Pausch
      1. Ich wäre dafür, dass TSS (Trade Statistik Sheet) in der einfachsten Ausbaustufe die grundlegenden Auswertungen im Standard ohne Programmierung, also fest eingebaut liefert. Also zum Beispiel was MT4 DetailStatement liefert mit Erweiterungen .....
      2. Sollte die Bedienung für den durchschnitlichen Nichtprogrammierer möglich sein
      3. Finde ich die Idee mittels SQL Statement die Menge der Trades auf eine Untermenge einzu schränken sehr gut. (Beitrag von Krümel Post 82)
      4. Wenn diese 3 Bedingungen erfüllt sind, ist es für die große Menge der Anwender ausreichend.

      5. Schnittstellen zu den einzelnen Plattformen werden sich aus den Anforderungen der User ergeben.
      6. Handische Eingaber der Trades sollte auch möglich sein. KISS
      7. Mittels Modulen weiter Auswertungen zukünftig zu schaffen finde ich auch sehr gut. ( Muss dann beim Entwurf der Tools berücksichtigt werden)

      Welche DB und Sprache müssen die Profis entscheiden.

      Zu den Fragen von Krümel:
      Einiges steht schon oben.
      Wenn man z.B. MT4 Auswertung umsetzt, hat man schon einenen Standard, der natürlich ergänzt wreden kann.
      Geschlossene Anwendung finde ich nicht so gut. Wenn man z.B. die Informationen zu den Trades erweitern möchte, sollte das ohne große Diskussionen mit der Community auch für "nur A"nwender möglich sein. (zum Beispiel eine Spalte bei der Traderefasung zu ergänzen). Die Möglichkeit der weiteren Entwicklung (Auswertungen, etc ... ) für Programmierer, sollte auf jeden Fall möglich sein. Das kann sehr viel Kreativität freisetzen. (Natürlich auch Probleme bereiten.)
      Windows würde mir reichen.
      Ein System auszuwerten würde mir reichen.
      Teilkomponeneten wie z.B. Excel können auch Geld kosten. Hatten wir schon geklärt.

      Ergänzungen .... Muss nachdenken... also später.
      "Erfahrung ist das, was Du bekommst, wenn Du nicht bekommst, was Du willst." Randy Pausch
      Wehe, wenn das hinterher ne Code-Schlacht in 20 verschiedenen Programmiersprachen wird, @oldschuren ! Dann benenn' ich mein erstes Magengeschwür nach dir !

      hi hi... Neben Python, Perl, .netFramework 1,2 und 3 muß noch Ruby-Runtime installiert sein und Windows Scripting Host laufen. Sonst geht gar nix... :D
      ich raube, also bin ich....

      oldschuren schrieb:

      Könnte mir ein loses ToolSet vorstellen. Ein Dreh- und Angepunkt sollte es geben. Die Datenbank. Wenn wir uns auf eine festlegen mit den Daten die darin gespeichert werden sollen, kann jeder mit interesse Tools schreiben, die darauf zugreifen können.
      Darauf könnten die anderen Tools alle zugreifen wie:

      - Datenimport von xxx-Tradehistorie >> in die Datenbank
      - Datenexport von Datenbank >> in XML, CRV, andere Datenbankformate, Steuererklärung ect.
      - Auswertungen von allgemeinen Kennzahlen bis zu umfangreichen grafischen Darstellungen der Trades

      Stimmt :thumbup: , das ist ne gute Idee, finde ich. Hat auch den Vorteil, dass nicht einer alleine die ganze Coding-Arbeit machen muss/darf/... Teile und herrsche funktioniert doch immer wieder gut :P . Da muss man mE nur aufpassen, dass die verschiedenen Teilprojekte irgendwie noch in der Gesamtheit handhabbar sind und man nicht abschließend auf 30+ (mehr oder weniger, in der Regel leider weniger ^^) getesteten und nichtdokumentierten Teilprogrammen sitzt, die irgendwas machen, von dem keiner (oder nur noch der jeweilige Coder) weiß, wie sie jeweils eingesetzt werden und inwieweit sie mit den anderen Teilprogrammen interagieren.

      Wehe, wenn das hinterher ne Code-Schlacht in 20 verschiedenen Programmiersprachen wird, @oldschuren ! Dann benenn' ich mein erstes Magengeschwür nach dir ! :S
      Könnte mir ein loses ToolSet vorstellen. Ein Dreh- und Angepunkt sollte es geben. Die Datenbank. Wenn wir uns auf eine festlegen mit den Daten die darin gespeichert werden sollen, kann jeder mit interesse Tools schreiben, die darauf zugreifen können. MySQL ist frei, gibt gut dokumentierte Schnittstellen zu allen möglichen Programmen und ist bestimmt auch leistungsfähig genug für das Projekt.

      Darauf könnten die anderen Tools alle zugreifen wie:

      - Datenimport von xxx-Tradehistorie >> in die Datenbank
      - Datenexport von Datenbank >> in XML, CRV, andere Datenbankformate, Steuererklärung ect.
      - Auswertungen von allgemeinen Kennzahlen bis zu umfangreichen grafischen Darstellungen der Trades
      ich raube, also bin ich....

      oldschuren schrieb:











      Ich z.B. kenn mich mit dem ganzen Web-Zeugs relativ wenig aus. Von Ruby hab ich auch keinen Schimmer (obwohl es sicher interessant ist, es gibt einige Projekte im Finanz-Bereich die damit arbeiten). R ist ebenfalls Fehlanzeige. Ich mach fast alles in c# weil ich persönlich damit meistens am schnellsten ans Ziel komme. Bis jetzt sieht es so aus, als ob alle Interessenten mit verschiedenen Tools arbeiten würden.

      Wird wahrscheinlich ein Problem. Da einen gemeinsamen Nenner finden wird schwer.

      Vielleicht sollten wir erstmal zusammentragen, was außer Datenimport und eventuell Einspeisung in eine Datenbank überhaupt rauskommen soll ?

      Ich bin z.B. relativ leidenschaftslos bezüglich der Programmiersprache, da ich schon mit vielen gearbeitet habe (mit Ruby nun mal ausnahmsweise nicht, aber so dramatisch anders wird es nicht sein).




      • Soll es eine abgeschlossene Applikation sein oder sollen Benutzer auch noch eigene Sachen dazuprogrammieren können (in was auch immer, meinetwegen auch in Vatical ) ohne an den Originalquellcode ranzumüssen (ne Art Konfiguration, z.B. über Templates wie ne Ausgabe aussehen soll) ?
      • Sollen Grafiken erstellt werden ? Wenn ja, was für welche (Histogramme, Liniencharts, Barcharts,....) ? Sollen die exportiert werden können, wenn ja, in welchem Format ? Sollen Ergebnisse ausgedruckt werden können ?
      • Reicht es, wenn das Programm unter Windows läuft (ich schätze mal, die meisten von uns hier arbeiten vorwiegend damit) ?
      • Last but not least: was soll alles an Performancekennzahlen berechnet werden ? Wie kann man die optimal darstellen ? (Tabellen, Grafiken, ...)
      • Sollen mehrere "Systeme" miteinander verglichen werden können (das würde z.B. erfordern, 2 statt nur eine Linie in ne Grafik zu malen).
      • Soll alles kostenlos sein oder können Teilkomponenten Geld kosten (Bsp: R ist kostenlos versus Excel kostet Geld) ?
      • ... könnt Ihr gern ergänzen.... :) (sollt Ihr sogar !)

      Aber solange die Frage nach dem "Was" nicht zumindest umfassend ('vollständig' kriegt man es meiner Erfahrung sowieso nicht hin, es gibt immer Sonderwünsche im Anschluss ;) ) beantwortet ist, ist es nicht sonderlich zielführend, das "Wie" zu diskutieren. Bevor die Liste von mir nicht mindestens doppelt solang und dreimal so ausführlich ist, kann man sich das Coden auch sparen, denn dann wird mit Sicherheit nur ne halbgare Lösung rauskommen, an der keiner Spaß hat.

      Just my 2 cent (Hey, diesen coolen Spruch wollte ich schon immer mal irgendwo hinschreiben. 8) )
      Ich z.B. kenn mich mit dem ganzen Web-Zeugs relativ wenig aus. Von Ruby hab ich auch keinen Schimmer (obwohl es sicher interessant ist, es gibt einige Projekte im Finanz-Bereich die damit arbeiten). R ist ebenfalls Fehlanzeige. Ich mach fast alles in c# weil ich persönlich damit meistens am schnellsten ans Ziel komme. Bis jetzt sieht es so aus, als ob alle Interessenten mit verschiedenen Tools arbeiten würden.

      Wird wahrscheinlich ein Problem. Da einen gemeinsamen Nenner finden wird schwer.
      ich raube, also bin ich....
      Ich würd mal sagen, dass man folgendes - bei den einen Anbieter besser beim anderen schlechter - aus der Tradehistorie extrahieren könnte:

      Art(CFD,Spot,Futures,Aktie),Basiswert, TradeIN(Level), Datum, Zeit, Menge, ursprünglicher Tickwert(interpoliert über ne Kursliste), erster StoppLoss(Level), TP(Level), TradeOUT(Level), Datum, Zeit, Gebühren(SpreadxPipe-/Punktwert bei CFD und Spot), Fikus(+ evt. Wechselkursschwangkung), Ergebnis, Kontostand

      Damit könnten weiteren Sachen berechnet werden...
      ich raube, also bin ich....