Alex: Sind PHP und mySQL eine gute Lösung?

Hallo zusammen!

Ich habe jetzt zu ersten mal das Vergnügen eine größere Datenbank ins Internet zu stellen. Meine Frage an euch:

Sind PHP (evtl. Perl/CGI) in Zusammenarbeit mit mySQL eine ideale Lösung für eine Datenbank mit ca. 30000 Datensätzen.

Vielen Dank, Alex

  1. Hi,

    Sind PHP (evtl. Perl/CGI) in Zusammenarbeit mit mySQL eine ideale Lösung für eine Datenbank mit ca. 30000 Datensätzen.

    30.000 Datensätzchen sind ein kleines Frühstück für 'ne anständige DB, MySQL eingeschlossen. Welches DBMS für Dich am günstigsten ist, hängt jedoch nur bedingt von der Menge ab. Die Komplexität der Daten (Tabellenstrukturen, DB-Layout) und der zu erwartenden Abfragen sind entscheidend.

    PHP kann sehr gut mit Datenbanken. Allerdings schränkst Du Dich gegenüber z.B. Perl in den Möglichkeiten ein - es ist zwar alles leichter, aber Sonderwünsche, die über die Grundfähigkeiten von PHP hinausgehen, lassen sich kaum umsetzen. Andere Sprachen bieten mehr, erfordern aber oft auch etwas mehr Arbeit.

    Jedes DB-Layout muß in Struktur und Statements optimiert werden. Achte z.B. auf sinnvolle Indizes.

    Cheatah

    1. Hallo Cheatah,

      30.000 Datensätzchen sind ein kleines Frühstück
      Jedes DB-Layout muß in Struktur und Statements optimiert werden. Achte z.B. auf sinnvolle Indizes.

      Vielen Dank für die überzeugende und nützliche Antwort.

      Gruß
      Alex

    2. Hi

      30.000 Datensätzchen sind ein kleines Frühstück für 'ne anständige DB, MySQL eingeschlossen.

      Nur mal intressehalber ...

      • wann fängt für Dich ein "Mittagessen" an?
        (Möchte jetzt keine Uhrzeit, sondern eine Datensatzanzahl  ;-)

      • ab wann eine "unverdauliche" Mahlzeit

      (Bleiben wir mal im PC-Bereich und gehen nicht zu den Mainframes)

      Amit

      P.S.: Ich verzweiel hier gerade!
      "Nur" 14 Mio Datensätze (selektiert ca. 2 Mio) auf einer 4*800 PIII mit 1 GB RAM Maschine bearbeiten ist einfach ... dachte ich.

      1. Hi,

        • wann fängt für Dich ein "Mittagessen" an?

        jedes DBMS hat einen eigenen Magen ;-) aber eigentlich wird es erst ab ein paar hunderttausend Datensätzen "nahrhaft".

        • ab wann eine "unverdauliche" Mahlzeit

        Wenn's unverdaulich ist, suche ich mir ein DBMS mit einem robusteren Magen *g* Einige Millionen Datensätze müßten das allerdings schon sein.

        Natürlich hängt's auch immer vom DB-Layout ab, und von den möglichen/nötigen Verknüpfungen. Wenn nur eine Tabelle da ist, aus der ich Datensätze einer bestimmten Eigenschaft auslese, erwarte ich von einem ordentlichen DBMS auch bei widerlich hohen Datenmengen nicht mal ein müdes Arschrunzeln; bei Joins über sieben Tabellen mit Subselects, GROUP BYs etc. rechne ich schon mit einigen Stunden Optimierungsaufwand.

        (Bleiben wir mal im PC-Bereich und gehen nicht zu den Mainframes)

        Wo ist der Unterschied? Ein DBMS hat immer die gleichen Aufgaben.

        P.S.: Ich verzweiel hier gerade!

        Würde ich auch, wenn ich nur "SELECT * ROM" schreiben könnte, weil mir eine Taste ehlt ;-) (SCNR)

        "Nur" 14 Mio Datensätze (selektiert ca. 2 Mio) auf einer 4*800 PIII mit 1 GB RAM Maschine bearbeiten ist einfach ... dachte ich.

        Das ist schon eine ganze Menge, die natürlich auch einen entsprechenden Datentransport mit sich bringt. Wenn Du Oracle benutzt, beschreibe mal bitte die Datenstruktur, das Statement und welche Indizes es gibt; vielleicht kann ich Dir bei der Optimierung helfen. Bei anderen DBMSsen habe ich leider keine bis wenig Erfahrung in der Richtung.

        Vielleicht kannst Du auch die Ergebnismenge reduzieren. Brauchst Du wirklich 2 Mio Zeilen?

        Cheatah

        1. Hi,

          Mahlzeit!

          Ich arbeite mit den MS SQL-Server 7.0.

          Bin gerade dabei ein paar Statistiken zu machen.
          Ziemlich simple Statements. Select, count und avg

          Der Statistik Server hat 5 relevate Tabellen.

          und ja, ich habe die Daten schon (auf 760166 Datensätze <- das ist DIE Zahl, wenn die nicht rauskommt ist alles Falsch!  ;-) reduziert.
          Das ist die Zahle für einen Monat. Seit 1994 wird mitgeschrieben.

          Thx für Deine angebotene Hilfe, aber ich glaube, das sollte ich lieber selbst hinbekommen.

          War ja nur intressehalber, was Du unter einem "Nicht-Frühstückchen" hälst.

          Amit

          1. Hi,

            Thx für Deine angebotene Hilfe, aber ich glaube, das sollte ich lieber selbst hinbekommen.

            die Einstellung gefällt mir :-)

            Chea "Und von MS-SQL habe ich eh keinen Schimmer... *g*" tah

    3. Hi,

      PHP kann sehr gut mit Datenbanken. Allerdings schränkst Du Dich gegenüber z.B. Perl in den Möglichkeiten ein - es ist zwar alles leichter, aber Sonderwünsche, die über die Grundfähigkeiten von PHP hinausgehen, lassen sich kaum umsetzen. Andere Sprachen bieten mehr, erfordern aber oft auch etwas mehr Arbeit.

      kannst Du mir das ein bischen erlaeutern?

      Jan
      --

      1. Sup!

        Hmmm... PHP soll ja schon extra für Webseiten gemacht sein, es könnte also sein, daß es unter PHP nicht möglich ist, zu forken, einen Raw-Socket zu öffnen oder sowas. Vielleicht gibt es auch nicht ganz so viele Module wie für Perl. Wer weiß, wer weiß... zu irgendwas muß Perl ja gut sein, und irgendwohinein müssen die Perl-Entwickler ja die ... 15 Jahre Arbeit gesteckt haben? Möglicherweise gibt es in PHP auch keine Threads, keine objektorientierte Programmierung, bla bla bla...

        ... auf jeden Fall kann man von Perl aus auch Oracle und PostGreSQL Datenbanken benutzen, und PostGreSQL und besonders FREMDSCHLÜSSEL und das geniale "contraint cascade" sind ein Segen. Hugh!

        Gruesse,

        Bio

        1. Hoi,
          jor, des kann PHP alles auch. und nu?

          Jan
          --