Ankündigung

Einklappen
Keine Ankündigung bisher.

Suche PHP-Entwickler für einen Fussball Manager

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Suche PHP-Entwickler für einen Fussball Manager

    Hallo,

    ich suche einen PHP-Entwickler (Erfahrung in OOP und MVC) für die gemeinsame Entwicklung eines Fussball-Managers auf Web-Basis.
    Ein grobes Konzept besteht bereits, also wie sollen die Screens aussehen, welche Funktionen müssen gegeben sein usw.

    Mit der Umsetzung wurde ebenfalls schon begonnen und es kann auf einige prozedurale Skripte von mir zurückgegriffen werden. Das Umschreiben auf OOP im Rahmen eines MVC-Pattern gestaltet sich allerdings für mich deutlich komplizierter als angenommen, sodass ich hier Unterstützung suche.

    Aktuell wird auf kein MVC-Framework zurückgegriffen, allerdings bin ich offen für eine solche Umstellung (zum aktuellen Entwicklungsstand wäre ein Umstieg denke ich problemlos machbar).

    Ich würde mich freuen, wenn sich jemand an diesem Projekt interessiert.
    Da es sich um ein Freizeitprojekt handelt, läuft das Ganze völlig unentgeltlich.


  • #2
    Da es sich um ein Freizeitprojekt handelt, läuft das Ganze völlig unentgeltlich.
    Auch wenn sich jemand finden sollte, ist es nicht zwingend erforderlich eine funktionierende Seite auf OOP umzustellen. Der Gewinn ist marginal und wenn du dich nicht auskennst und mal etwas ändern willst, brauchst du jedes mal Hilfe, was wohl bei prozeduraler Programmierung, wie du es derzeit hast wohl nicht der Fall sein dürfte.
    Ich würde mir das gut überlegen und genau abwägen welchen Gewinn ich dadurch hätte.

    Das soll jetzt weder für noch gegen OOP sprechen sondern nur zum Nachdenken anregen.

    Kommentar


    • #3
      Die Umstellung auf OOP macht schon Sinn, da ich in gewissen Bereichen schon Performance-Probleme anhand von zu vieler Datenbank-Abfragen bemerkt habe. Dementsprechend würde ich die Arbeit mit Objekten an dieser Stelle für notwendig halten, weshalb eine Umstellung in meinen Augen schon notwendig ist.

      Kommentar


      • #4
        Zitat von Niko310391 Beitrag anzeigen
        Die Umstellung auf OOP macht schon Sinn, da ich in gewissen Bereichen schon Performance-Probleme anhand von zu vieler Datenbank-Abfragen bemerkt habe. Dementsprechend würde ich die Arbeit mit Objekten an dieser Stelle für notwendig halten, weshalb eine Umstellung in meinen Augen schon notwendig ist.
        Das ist ein Design-Problem deiner Anwendung. Das ist mit OOP auch nicht zwangsläufig gelöst.

        Kommentar


        • #5
          Wenn die DB lange braucht um die Daten zusammenzustellen, dann solltest du dort ansetzen. Das hat jedoch nichts mit der Programmmietsprache oder dem Programmierparadigma zu tun.

          Kommentar


          • #6
            Also das Ganze gestaltet sich wie folgt:

            Es soll eine Einzelspieler-Karriere möglich sein. Das bedeutet, dass ein User seine Karriere startet (wählt ein Team aus usw.) und kann innerhalb dieses Datensatzes dann selbstständig an Ingame-Tagen voranschreiten. Jeder Tagesübergang hat zig Aktionen (Trainingsfortschritt, Match-Simulation usw.). All diese Aktionen finden derzeit mit Datenbank-Selects / -Updates / -Inserts statt. Aufgrunddessen wird der Tagesübergang immer langsamer, umso mehr Aktionen dort stattfinden.

            Laut Google bin ich dementsprechend auf die objektorientierte Programmierung gestoßen. Mein Anliegen ist es hier, die Daten des Spielstandes einmalig in Objekte zu laden und im Spielstand selbst dann nur noch die Objekte zu aktualisieren und nicht mehr mit der Datenbank arbeiten. Erst, wenn der User seinen Spielstand speichern möchte, sollen alle Daten aus den Objekten in ein Savegame-Database-File geschrieben werden.

            Soweit ich das durch Google herausfinden konnte, soll dies mit der objektorientierten Programmierung soweit möglich sein. Kann das hier bestätigt werden?
            Wenn ja, bin ich auf dem richtigen Weg mit meiner Idee?

            Kommentar


            • #7
              Das ist auch mit Spaghetti-Code lösbar. Noch mal - das hat nichts mit OOP zu tun, dadurch wird es nicht besser oder gar schneller, nur anders programmiert.

              Soweit ich das durch Google herausfinden konnte
              Keine Ahnung wonach du gesucht hast.

              Kommentar


              • #8
                Soweit ich das durch Google herausfinden konnte, soll dies mit der objektorientierten Programmierung soweit möglich sein. Kann das hier bestätigt werden?
                Jein.
                PHP fährt sich ja mit jedem Request neu hoch, für jeden Request muss der Datenbestand erst wieder aufbereitet werden - ob das in Form von Objekten oder Arrays stattfindet ist recht egal.

                Deine Idee, die Daten nicht jedes mal aus der Datenbank holen zu müssen, ließe sich dann eher über einen zusätzlichen Cache lösen. Dort könntest du dann die aufbereiteten Datenstrukturen (Array oder Objekt) speichern und mit jedem Request dann wieder aus dem Cache laden.
                Beim "Speichern" würden diese Datenstrukturen dann auseinander genommen und in die korrekten Tabellen gespeichert werden.

                Wie schon gesagt wurde, OOP löst keine Performance-Probleme - das passiert höchstens als Nebeneffekt wenn z.B. umständliches Schleifenwirrwarr umgeschrieben wird und man dabei einen effizienteren Weg findet.
                Aber, ich würde auch zu OOP raten. Allein schon verbindliche Datenstrukturen zu haben hilft enorm die Übersicht zu behalten.
                Wenn die Zuständigkeiten der anderen Klassen auch richtig aufgeteilt wird, fällt es anderen Entwicklern auch einfach sich in den Code einzuarbeiten.
                Relax, you're doing fine.
                RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

                Kommentar


                • #9
                  Um die "Datenbankabfragegeschwindigkeit" zu erhöhen, würde ich dir empfehlen bei SQL Statements nur die benötigten Spalten abzufragen und vielleicht die Spalten zu verbessern.

                  Kommentar


                  • #10
                    jonah88
                    Sehr vage Aussage ohne die DB Struktur zu kennen und was meinst mit Spalten verbessern?

                    Kommentar


                    • #11
                      protestix Wenn du z.B. ein VARCHAR(250) hast für ein sha1() mit maximal 49 Zeichen. (Ein sehr übertriebenes Beispiel!)

                      Kommentar


                      • #12
                        Kein übertriebenes Beispiel.
                        Aber falsch gedacht, weil das genau gar nichts ausmacht.

                        Kommentar


                        • #13
                          Die Datenbank ist vernünftig strukturiert. Auch die Abfragen sind nicht mit SELECT * aufgebaut, sondern es werden nur die Spalten geholt, die auch wirklich erforderlich sind.
                          Vielleicht hat ja jemand Interesse sich dem Projekt mit anzunehmen.

                          Natürlich ist es ein langfristiges Projekt, aber das Grundgerüst (von den Funktionen her) muss ja zu Beginn noch nicht allzu groß sein. Vielleicht gibt es ja auch jemanden, der beim Start, also beim Strukturaufbau, seine Expertise mit einbringen könnte.

                          Kommentar


                          • #14
                            Aus Erfahrung hängt eine langsame "Datenbankabfragegeschwindigkeit" eher an folgenden Fehlern:
                            • zu vielen Zugriffen auf die Datenbank, also z. B. Abfragen in Schleifen etc.
                            • fehlende Indizes in den Tabellen
                            • unperformante joins
                            • falsches Tabellendesign (keine Normalisierung)
                            Hier wäre am ehesten mal anzusetzen.
                            There are 10 kind of people: those who understand binary and those who don't.

                            Kommentar


                            • #15
                              Leute, eure Vorschläge sind doch alle rein spekulativ. Keiner von euch weiß, woran es hakt und jeder gibt seinen Senf dazu, der dem TE vermutlich rein gar nichts bringt..

                              Kommentar

                              Lädt...
                              X