Seite 2 von 2 ErsteErste 12
Zeige Ergebnis 16 bis 23 von 23
  1. #16
    Community-Forum Benutzerbild von Benrath
    Registriert seit
    Mai 2003
    Beiträge
    16.551
    Likes
    1671
    Zitat Zitat von parats' Beitrag anzeigen
    Ich würde an deiner Stelle ohnehin request/response in jeweils einer Tabelle speichern und danach von den Daten mit SQL abstrahieren. Vorteil wäre, dass Du dich an Datenmodellen versuchen kannst, ohne immer gleich im Code zu bastlen. Funktioniert das nämlich sauber, bleibt dir der Kopf für eine Baustelle.

    Du willst am Ende doch nur Informationen für eine Relation von Start - Ziel über den zeitlichen Verlauf haben.
    Da verstehe ich nicht ganz was du mir sagen möchtest. und bei Schaf auch nicht ganz

    Den Request permutiere ich ja über die n Flughäfen als Origin und Destination. Und setzt da noch Abflug und Rückflugdatum.
    Das kann ich problemlos in einer (Haupt)-Tabelle speichern und dort wird dann ne ID in der DB vergeben. Das sind dann n Requests pro z.B. Tag.

    Pro Request und Id in dieser Tabelle hab ich k offers. Und die müssten dann ja immer wieder auf diese Tabelle speichern.

    Und dann hab ich teilweise noch g segmente etc pro offer.

    kann immer die Id des Requests und der offers in die jeweilige Tabelle reinschreiben, damit die mit der Haupttabelle der Requests verbunden sind


    Muss mir wohl einmal von der DB den Maxwert der ID Spalte der Request liste holen, dann die neuen Requests reinschreiben. Dann hol ich mir die Request wieder zurück aber nur wenn die ID über dem Max counter ist. Dann hab ich nur wieder die neuen, die ich abfrage möchte
    Geändert von Benrath (23. Mai 2020 um 21:47 Uhr)
    "Wenn ihr nicht wisst wovon ihr redet, sprecht von einem System."


    "Wenn jeder an sich denkt, ist an alle gedacht !"

    "wollen wollen ist die höchste Form der Unterdrückung"


  2. #17
    Tippspielmeister 2012
    Tippspielmeister 2019
    Benutzerbild von parats'
    Registriert seit
    Mai 2003
    Ort
    Hamburg
    Beiträge
    14.351
    Likes
    418
    Okay, dann zerteilst Du ja schon alles, soweit so gut. Ich würde dir persönlich empfehlen dann das Ganze zu kapseln. Die Applikation erzeugt request/response und schreibt in die DB einfach als bulk insert ohne technische Schlüssel 1:1 die Inhalte in die Tabellen - im Prinzip eine reine staging Umgebung.

    Den Rest würde ich immer relational erledigen, da hier die Stärken voll ausgespielt werden.
    Also Normalisierung, schlüsseln und Erstellung deines Datenmodells mit Dimensionen und Fakten.

    Versuche idealerweise keine unnötigen roundtrips von der Applikation zur DB. Das heißt bspw. Rückgabewerte von technischen Schlüsseln haben in der Applikation nichts verloren. Ich hoffe ich habe dich soweit richtig verstanden und mich auch einigermaßen verständlich ausgedrückt, damit zumindest mein Kernpunkt rüberkommt. Ich habe als ETLer aber auch einen fetisch für mehrstufige Ladeprozesse und Datenkapselung. Macht vor allem die Fehlersuche deutlich einfacher und bei Erweiterungen, kann man recht modular arbeiten.

  3. #18
    Community-Forum Benutzerbild von Benrath
    Registriert seit
    Mai 2003
    Beiträge
    16.551
    Likes
    1671
    Zitat Zitat von parats' Beitrag anzeigen
    Okay, dann zerteilst Du ja schon alles, soweit so gut. Ich würde dir persönlich empfehlen dann das Ganze zu kapseln. Die Applikation erzeugt request/response und schreibt in die DB einfach als bulk insert ohne technische Schlüssel 1:1 die Inhalte in die Tabellen - im Prinzip eine reine staging Umgebung.
    Die raw response speichere ich zur Zeit als einzelne Datei (pickle Format) und gar nicht in der DB. Da wüsste ich auch gar nicht wie ich dieses super verschachtelte Ding, siehe oben, reinspeichern sollte.


    Zitat Zitat von parats' Beitrag anzeigen
    Den Rest würde ich immer relational erledigen, da hier die Stärken voll ausgespielt werden.
    Also Normalisierung, schlüsseln und Erstellung deines Datenmodells mit Dimensionen und Fakten.
    Das versuche ich ja und fange mit der obersten Tabelle als die Requests an, dann die offers weil n pro request. etc.
    Dann hängen die Folgetabellen über den FK in die oberen Tabellen. Andersrum bräuchte ich wohl Zwischentabellen? weil das keine 1 zu 1 Beziehungen sind


    Zitat Zitat von parats' Beitrag anzeigen
    Versuche idealerweise keine unnötigen roundtrips von der Applikation zur DB. Das heißt bspw. Rückgabewerte von technischen Schlüsseln haben in der Applikation nichts verloren. Ich hoffe ich habe dich soweit richtig verstanden und mich auch einigermaßen verständlich ausgedrückt, damit zumindest mein Kernpunkt rüberkommt. Ich habe als ETLer aber auch einen fetisch für mehrstufige Ladeprozesse und Datenkapselung. Macht vor allem die Fehlersuche deutlich einfacher und bei Erweiterungen, kann man recht modular arbeiten.
    Naja genau das würde ich jetzt zumindest einmal anfänglich tun. Weil ich doch irgendwie aus der DB wissen muss, wo die ID gerade steht. SElbst wenn ich die ID bei mir setze würde, müsste ich doch einmal wissen wo die ID gerade steht.


    Danke auf jeden Fall für die Inputs, hilft mir viel

    Also zumindest stand jetzt läut die Sache und ich kann wiederholend die Requests machen und er geht den den ID counter hoch. Muss halt einmal die Max ID einlesen und das speichern. und Schieb die Requests einmal zwischen DB und Python hin und her.
    Geändert von Benrath (01. Juni 2020 um 16:55 Uhr)
    "Wenn ihr nicht wisst wovon ihr redet, sprecht von einem System."


    "Wenn jeder an sich denkt, ist an alle gedacht !"

    "wollen wollen ist die höchste Form der Unterdrückung"

  4. #19
    Community-Forum Benutzerbild von Benrath
    Registriert seit
    Mai 2003
    Beiträge
    16.551
    Likes
    1671
    Nur so als Update. Bin doch eurem Rat gefolgt die Daten in die DB zu schieben ohne dass ich was hin und herschieben muss.
    Nutze jetzt die IATA codes (FRA, DUS, etc) und das Datum des Hin und Rückflugs als IDs. Pro Offer hab ich schon ne ID im Request.

    Das macht das ganze wohl robuster, weil ich jederzeit ohne Probleme aus den einzelnen Request files die DB wieder füllen kann.
    Vorher hatte ich die Parameter der Requests irgendwie speichern müssen. Das wäre wohl eher doof gewesen.
    "Wenn ihr nicht wisst wovon ihr redet, sprecht von einem System."


    "Wenn jeder an sich denkt, ist an alle gedacht !"

    "wollen wollen ist die höchste Form der Unterdrückung"

  5. #20
    Tippspielmeister 2012
    Tippspielmeister 2019
    Benutzerbild von parats'
    Registriert seit
    Mai 2003
    Ort
    Hamburg
    Beiträge
    14.351
    Likes
    418
    Das passt doch und vor allem danke fürs aktuell halten.

  6. #21
    Benutzerbild von Kuint
    Registriert seit
    Feb 2005
    Beiträge
    2.740
    Likes
    927
    Zitat Zitat von Benrath Beitrag anzeigen
    Danke.
    https://github.com/Benrath/amadeus

    Macht es Sinn das einmal alles ins Master File zu schieben?
    was zum fick bin ich lesend ? und zu deiner frage, ja es wuerde sinn machen das ganze von einer main.py oder so zu starten und die anderen dateien als module reinzuladen. dann laesst sich das ganze auch besser lesen. das ganze koennte in etwa so ausehen. falls du diesen weg gehst pack in den ordner eine leere datei __init__.py rein sonst spackt es rum mit den ganzen imports.

    PHP-Code:
    import amadeus_api_utils as aau # modul welches sich um das api zeuchs kuemmert
    import db_utils as db # modul welches sich um das db zeuchs kuemmert

    def foo():
        
    '''
        wenn du willst kannst du auch hier noch funktionen haben
        '''

    if __name__ == '__main__':
       
    data aau.get_flights()
       
    db.save_flight_to_db(data
    da dein code nicht sehr gross ist kannst du alles in die main.py packen und die funktionen im if __name__ == '__main__': block ausfuehren, wurde dir all deine wiederholungen ersparen.

    PHP-Code:
    import pandas as pd
    import sqlite3 

    def db_stuff
    (foo):
        
    '''
        store foo in db
        '''

    def get_data_from_api():
        return 
    '12-18 zwiebeln'
        

    if __name__ == '__main__':
        
    db_stuff(get_data_from_api())
        print(
    'done'
    wenn du das ganze noch erweitern moechtest schau dir argparse an damit du das ganze mit argumente ueber das terminal steuern kannst.


    edit:
    bis du inder?

    PHP-Code:
    import os
    from os import path
    from datetime import datetime
    from datetime import timedelta 
    kann durch ersetzt werden

    PHP-Code:
    import os
    import sqlite3
    from datetime import datetime
    timedelta


    sqlite3
    .Error
    os
    .path() 
    Geändert von Kuint (06. Juni 2020 um 22:39 Uhr)
    Zitat Zitat von Shihatsu Beitrag anzeigen
    ich geb zu das du was diese sache angeht ein dummer bauer bist - siehe dein abgang. ganz ehrlich, du hast noch nie was dümmerres und verbohrteres von dir gegeben als gerade eben. und du gibst dir manchmal schon viel mühe.

  7. #22
    Community-Forum Benutzerbild von Benrath
    Registriert seit
    Mai 2003
    Beiträge
    16.551
    Likes
    1671
    äh Danke für deinen hilfreichen Beitrag. Ich bin nicht Inder, sondern mache zum ersten mal was in Python. Finde das mit dem Import kack äußert nervig und hab da meinen Code auch noch nicht gesäubert, weil ich teilweise einzelnen Befehle von Bedarf zu Bedarf hinzugefügt habe.
    "Wenn ihr nicht wisst wovon ihr redet, sprecht von einem System."


    "Wenn jeder an sich denkt, ist an alle gedacht !"

    "wollen wollen ist die höchste Form der Unterdrückung"

  8. #23
    Benutzerbild von Kuint
    Registriert seit
    Feb 2005
    Beiträge
    2.740
    Likes
    927
    wenn du probleme mit dem import hast kannst du dir dies mal durchlesen https://docs.python.org/3/tutorial/modules.html sollte dir das ganze naeher bringen und ja es kann nervend sein.
    Zitat Zitat von Shihatsu Beitrag anzeigen
    ich geb zu das du was diese sache angeht ein dummer bauer bist - siehe dein abgang. ganz ehrlich, du hast noch nie was dümmerres und verbohrteres von dir gegeben als gerade eben. und du gibst dir manchmal schon viel mühe.

Seite 2 von 2 ErsteErste 12

Forumregeln

  • Es ist dir nicht erlaubt, neue Themen zu verfassen.
  • Es ist dir nicht erlaubt, auf Beiträge zu antworten.
  • Es ist dir nicht erlaubt, Anhänge hochzuladen.
  • Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
  •