Marki Mark: Welche Datenbank auf eigenem Server für Community-Projekt verwen

Hallo Leute,
ich stehe davor, einen eigenen Server auf Debian-Basis oder Windows-Basis anzuschaffen und frage mich nun, auf welche Datenbank ich setzen sollte?

Es wird sich um ein Community-Projekt handeln, wo User-Daten und -Beiträge gelesen und geschrieben werden.

Es wird Wert auf eine gute Administrationsmöglichkeit gelegt. Es dürfte ruhig etwas komfortabler als mit phpmyadmin (MySQL) gehen, etwa in Form einer Windows-Oberfläche.

Was könnt ihr mir da empfehlen mit Blick auf Kosten und Zukunftssicherheit/Skalierbarkeit sowie genannte Admin-Freundlichkeit?

Was ist mit PostgreSQL, MSSQL, etc.?

Grüße
Mark

  1. Hi,

    was genau meinst Du mit

    [...] gute Administrationsmöglichkeit [..] etwas komfortabler als mit phpmyadmin (MySQL) gehen, etwa in Form einer Windows-Oberfläche.

    IMHO ist phpMyAdmin zum Administrieren einer MySQL-Datenbank gut geeignet, auf ne Windows-Oberfläche pfeiff ich ;)

    Deine komplette Community wirst Du wohl nicht so einfach mit "irgendeinem" Tool administrieren können.

    Oder verstehe ich da was falsch?

    Gruß, Samoht

    --
    fl:| br:> va:) ls:< n4:( ss:) de:] js:| mo:}
    "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
    (Kristian Wilson, Nintendo, 1989)
    1. Deine komplette Community wirst Du wohl nicht so einfach mit "irgendeinem" Tool administrieren können.

      als "irgend ein tool" eignet sich Drupal, phpBB oder TYPO3 ganz gut

      1. als "irgend ein tool" eignet sich Drupal, phpBB oder TYPO3 ganz gut

        :)

        ... wenn die Community noch nicht besteht... dann durchaus. Wobei das nicht herauszulesen war.

        Da phpMyAdmin als Referenz genannt wurde, bezog ich mich auf die Möglichkeit eine Community mit dessen Hilfe (oder ähnlichem) zu administriern, was sehr umständlich wird.

        Gruß, Samoht

        --
        fl:| br:> va:) ls:< n4:( ss:) de:] js:| mo:}
        "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
        (Kristian Wilson, Nintendo, 1989)
        1. Da phpMyAdmin als Referenz genannt wurde, bezog ich mich auf die Möglichkeit eine Community mit dessen Hilfe (oder ähnlichem) zu administriern, was sehr umständlich wird.

          oft schadet es nicht, direkt in der datenbank herumfuhrwerken zu können - besonders um leichen oder accounts von spambots zu löschen ;)

          1. Der Meinung bin ich nicht. Soetwas sollten automatisierte Scripte machen, bzw. auch nur über das Administrations-Tool.

            Wie gesagt - die größe der Community ist entscheidend. Ich würde keinen Studentenjobler irgendwie an die DB lassen, nur um tote Accounts zu löschen. *g*

            Scripte Scripte Scripte :P

            Und wie bei dem anderem Posting von mir schon gesagt - mit phpMyAdmin in der DB inhaltlich rumzuwerken ist äußerst blöde, wenn die Codierung z.B. UTF-8 ist.

            1. Und wie bei dem anderem Posting von mir schon gesagt - mit phpMyAdmin in der DB inhaltlich rumzuwerken ist äußerst blöde, wenn die Codierung z.B. UTF-8 ist.

              was ist bei utf8 genau das problem?

              1. Das phpMyAdmin nicht utf-8 abspeichert, sondern die inputfelder irgendeinen standard-iso code verwenden.
                Und somit jegliche eingabe von umlauten und sonderzeichen in der Tabelle fürn a.... sind :(

                Mußte mal testen. UTF-8 Feld und mit phpmyadmin ein ä reinschreiben...

                1. echo $begrüßung;

                  Das phpMyAdmin nicht utf-8 abspeichert, sondern die inputfelder irgendeinen standard-iso code verwenden.
                  Und somit jegliche eingabe von umlauten und sonderzeichen in der Tabelle fürn a.... sind :(
                  Mußte mal testen. UTF-8 Feld und mit phpmyadmin ein ä reinschreiben...

                  Das geht einwandfrei. Mir ist auch noch nicht zu Ohren gekommen, dass der PMA an Kodierungsproblemen Schuld gewesen ist. Es waren bisher immer Fehler beim Auslesen und Schreiben durch andere Client-Anwendungen, die nicht beachtet hatten, dass sie eine Kodierung aushandeln müssen und dann gemäß dieser Kodierung zu kommunizieren haben.

                  echo "$verabschiedung $name";

                2. Mußte mal testen. UTF-8 Feld und mit phpmyadmin ein ä reinschreiben...

                  also ich bin zufrieden und kann problemlos 产品 (chinesisch für produkte) reinschreiben ;) auch ein ä stellt kein problem dar

  2. Nun ja - was bedeutet Admin-Freundlichkeit?

    Eine Communityseite sollte für Admins Scripte zur Verfügung stellen, die ihren Ansprüchen gerecht wird.

    Wenn es darum geht wirklich an der DB rumzuschreiben, ist es eigentlich egal welche DB man benutzt.

    Je nach Aufwand und Größe des Projektes - welche ich nicht einschätzen kann - sind mySQL Server immer geeignet.

    Was im speziellen willst du denn groß an der DB administrieren? Community + Nachrichten, Foren und all das hat doch wenig mit der DB zu tun.

    Die Datenbank Entscheidung sollte darauf basieren, mit wie vielen Anfragen ihr in einer bestimmten Zeit rechnet und wie groß und wie verschachtelt diese Anfragen sein werden. Was für Ergebnisse zurückgeliefert werden müssen und wie zeitkritisch die ganze Sache ist.

  3. ... was ihr sagt ist alles richtig, natürlich werden Admin-Skripte bereitgestellt.

    ich dachte nur, es wäre schön, zusätzlich auch mal wie unter einer Win-Oberfläche Zellbereiche in Tabellen markieren, en bloc editieren und mit Copy&Paste bearbeiten zu können.

    Aber klar ist phpmyadmin nicht gerade schlecht für ein Webbasiertes Tool.

    Zur Komplexität der Abfragen: Also ein paar verschachtelte Joins sind schon zu bewältigen.

    Ich dachte einfach, wir könnten in diesem Thread die einzelnen Datenbanken diskutieren mit Blick auf die Faktoren Kosten und Schnelligkeit.

    Kostet z.B. MySQL nicht auch etwas außer bei Open-Source-Projekten?

    Gruß
    Mark

    1. Zur Komplexität der Abfragen: Also ein paar verschachtelte Joins sind schon zu bewältigen.

      Das schafft MySQL locker ;)

      Interessant wirds dann wohl eher erst bei Nested-Sets und anderen Aufgaben. Clusterfähig ist MySQL auch, von daher sehe ich da kein Problem diese...

      Auch was die Größe der Datenbank angeht, gibt es andere Datenbanken wie auch Oracle, die bestimmte Werte besser speichern....

      Kostet z.B. MySQL nicht auch etwas außer bei Open-Source-Projekten?

      ... kostenfreie Datenbank zu empfehlen.

      PHPAdmin ist wirklich nur zum Einstellen der DB gut, sobald man characters einfügen will, sollte man auf den Zeichensatz achten. Von daher -> Adminscripte benutzen und alles schön im UTF-8 Stil belassen :D

      1. Moin!

        PHPAdmin ist wirklich nur zum Einstellen der DB gut, sobald man characters einfügen will, sollte man auf den Zeichensatz achten. Von daher -> Adminscripte benutzen und alles schön im UTF-8 Stil belassen :D

        Wie kommst du denn auf die schräge Idee?

        PHPMyAdmin achtet bestens auf die Einhaltung von Zeichencodierung - im Gegensatz zu vielen selbstgeschriebenen Datenbankabfragen. Aus dieser Differenz resultiert, dass aufgrund des unzureichenden Encoding-Handlings im eigenen Script dann in PHPMyAdmin die Fehler offen zutagetreten.

        Kreidest du das jetzt PHPMyAdmin als Fehler an?

        - Sven Rautenberg

        --
        "Love your nation - respect the others."
        1. Kreidest du das jetzt PHPMyAdmin als Fehler an?

          Öhm ... ja?

          Ich benutz die aktuellste version. Hab Zeichensatz für alle meine DBs immer auf UTF-8.

          Wenn du jetzt aber per phpMyAdmin dort in die Felder z.B. ein Varchar Feld mit Umlauten füllst, wird es dir nicht korrekt angezeigt.

          1. Moin!

            Kreidest du das jetzt PHPMyAdmin als Fehler an?
            Öhm ... ja?

            Ich benutz die aktuellste version. Hab Zeichensatz für alle meine DBs immer auf UTF-8.

            Wenn du jetzt aber per phpMyAdmin dort in die Felder z.B. ein Varchar Feld mit Umlauten füllst, wird es dir nicht korrekt angezeigt.

            Benutzt du in deinem eigenen Skript als allererstes Query nach dem Verbindungsaufbau "SET NAMES utf8"?

            Wenn nein, dann erklärt das alles.

            - Sven Rautenberg

            --
            "Love your nation - respect the others."
            1. Nein, da meine Scripte alle in UTF-8 gespeichert sind.

              1. Hi Jurik,

                Nein, da meine Scripte alle in UTF-8 gespeichert sind.

                Das hat damit nichts zu tun. SET NAMES definiert, mit welchem Charset die Datenübertragung erfolgt, Zitat:

                SET NAMES indicates what character set the client will use to send
                  SQL statements to the server. Thus, SET NAMES 'cp1251' tells the
                  server “future incoming messages from this client are in character
                  set cp1251.”

                Wenn du deine Daten also fehlerhaft an den Server überträgst, dann merkst du von deinem Fehler nichts, sofern du beim Auslesen wieder denselben Fehler machst. Aber du kannst es schlecht PhpMyAdmin ankreiden, dass es die von dir falsch gespeicherten Daten nicht korrekt anzeigen kann. ;-)

                Viele Grüße,
                  ~ Dennis.

              2. Moin!

                Nein, da meine Scripte alle in UTF-8 gespeichert sind.

                Siehst du, das ist genau das Problem.

                Die Datenbankverbindung hat nämlich auch ein Encoding. Das ist standardmäßig aber auf ISO-8859-1 gesetzt. Und dann paßt es nämlich nicht.

                Die Datenbank kriegt von deinem Skript die Bytes, die in UTF-8 z.B. einen Umlaut darstellen. Aber aufgrund der vereinbarten (oder eben nicht vereinbarten) Encoding-Definition der DB-Verbindung interpretiert die Datenbank diese Bytes so, als ob sie ISO-8859-1 sind. Ein Umlaut besteht aus zwei Bytes, das macht zwei ISO-8859-1-Zeichen, die werden von ISO nach UTF-8 gewandelt und in der DB abgespeichert. Im DB-Feld steht dann z.B. "A-Tilde Currency" - UTF-8-codiert, d.h. man kann innerhalb der Datenbank damit gar nichts anfangen als Umlaut, weil es ja kein Umlaut ist.

                Das stört innerhalb deiner Verarbeitungskette skriptseitig aber nicht, denn der Rückweg läuft genauso ab: "A-Tilde Currency" wird aus der DB ausgelesen, gewandelt in ISO-8859-1, und das ergibt dann wieder genau die Bytes, die du skriptseitig als UTF-8 interpretierst, die dann einen Umlaut ergeben.

                Da PHPMyAdmin aber das Umlauthandling korrekt vornimmt, siehst du natürlich den Mist, den dein Skript in die DB reingeschrieben hat, und kannst Texte darin auch nicht ordentlich bearbeiten.

                Liegt aber ausschließlich an deiner mangelhaften Anbindung der Datenbank, nicht an PhpMyAdmin.

                - Sven Rautenberg

                --
                "Love your nation - respect the others."
              3. echo $begrüßung;

                Nein, da meine Scripte alle in UTF-8 gespeichert sind.

                Nun, wenn du zwar UTF-8-kodierte Daten zum MySQL-Server sendest, der aber für Clientverbindungen sehr wahrscheinlich in deinem Fall Latin1 als Default-Wert eingestellt hat, und du diesen nicht neu verhandelst (mysql_set_charset() oder zur Not SET NAMES), dann haben wir ja die Stoßstelle. Die von dir gesendeten UTF-8-kodierten Daten werden vom MySQL-Server als Latin1 interpretiert und auch so behandelt. Aus einem UTF-8-Umlaut werden nun 2 Latin1-Zeichen. Rückwärts bekommst du diese 2 Latin1-Zeichen genauso wieder zurück, du interpretierst sie aber als UTF-8. Somit sieht für dich die Welt in Ordnung aus. Wer jedoch wie der PMA korrekt ausgehandelt UTF-8 mit dem MySQL-Server spricht, bekommt die zwei Zeichen jedes einzeln in UTF-8 kodiert präsentiert. Du siehst keinen Umlaut und denkst, dass das ein Fehler ist. Du schreibst mit dem PMA einen Umlaut. Wenn du ihn wieder mit dem PMA abfragst, solltest du ihn richtig angezeigt bekommen. Wenn du diesen nun mit deinem Client abfragst, kodiert MySQL ihn gemäß Default-Verbindungskodierung (= Latin1) um, du denkst aber, es wäre UTF-8 und siehst nur einen ungültigen Code.

                Nun hast du aber ein Problem. Wenn du denkst, einfach mysql_set_charset("utf8") oder SET NAMES utf8 in dein Script einzubauen, beseitigt das Problem, das du mit dem PMA hast, dann irrst du dich leider. Denn in deiner Datenbank stehen bereits jede Menge falsch interpretierte Zeichen. die erstmal in eine richtige Kodierung gebracht werden müssen. Eine Möglichkeit wäre:

                • Sicherungskopie der Datenbank erstellen; umkopieren in eine neue Datenbank reicht
                • Export der Daten mit dem PMA [1]
                • Umkodieren der Export-Datei mit einem Editor von UTF-8 nach Latin1 [2]
                • Importieren mit dem PMA, dabei aber UTF-8 als Kodierung einstellen [3]
                • Wenn der PMA nun alle Umlaute richtig anzeigt, deine Applikation mit mysql_set_charset("utf8") oder SET NAMES utf8 ebenfalls, dann ist alles gut gelaufen.

                [1] Deine UTF-8 gesendeten aber als Latin1 interpretierten Daten werden dabei doppelt UTF-8-kodiert ausgegeben.
                [2] Die doppelte UTF-8-Kodierung ist nun nur noch eine einfache.
                [3] Deswegen kann man sie nun als UTF-8 einlesen.

                echo "$verabschiedung $name";

            2. Vielen Dank für die Aufklärung an alle drei :)

  4. Es wird Wert auf eine gute Administrationsmöglichkeit gelegt. Es dürfte ruhig etwas komfortabler als mit phpmyadmin (MySQL) gehen, etwa in Form einer Windows-Oberfläche.

    Bin durch Zufall gerade über http://www.turboajax.com/products/turbodbadmin/ gestolpert und musste an Dich denken... Ohne jegliche Wertung, scheint noch in einem frühen Stadium zu sein... Möglicherweise interessant...

    Gruß, Samoht

    --
    fl:| br:> va:) ls:< n4:( ss:) de:] js:| mo:}
    "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
    (Kristian Wilson, Nintendo, 1989)
  5. yo,

    Was ist mit PostgreSQL, MSSQL, etc.?

    ich denke für dich sollte im vordergrund stehen, wer die Datebank später verwalten soll und über welche skills derjenige verfügt. was nützt dir ein oracle server, wenn niemand damit erfahrungen hat ? ist die aufgabe eventuell neu zu besezten, dann hat man bei der auswahl des dbms wieder größerer spielraum.

    Ilja