SQL Welche DB für PHP Webprojekt

[VipE]

Ich bin gerade dabei ein neues Webprojekt zu starten.
Es soll eine Website sein wo sämtliche Fahrzeugdaten aufgelistet sind. Diese Fahrzeugdaten werden per SQL Skript laufend aktualisiert.

Mein letztes Webprojekt liegt nun 3 Jahre zurück (damals noch in in ASP.NET + MS SQL Server).

Dieses möchte ich mit PHP realisieren, allerdings bin ich nicht mehr uptodate welche DB sich dafür am besten eignen würde.
Würdet ihr MySQL oder den MS SQL Server vorziehen?

 

[DaFreax]

Also ich würde dir auf jeden Fall MySQL empfehlen wenn du das mit PHP realisieren willst. Mann kann auch sagen, dass PHP und MySQL ein unzertrennliches Paar sind

 

[NiThDi]

MySQL +1

 

[xSeppelx]

Kommt ganz auf die Daten an, ggf. kann auch was anderes sinnvoll werden.
Fahrzeugdaten können natürlich auch sehr komplex werden, dennoch denke ich das es sich in Grenzen halten wird (wobei du das am besten wissen müsstest) und deshalb sollte MySQL die richtige Wahl sein.

 

[[o.0]]

MySQL oder PostgreSQL, ist geschmackssache.

 

[AlbertLast]

Wie sehen die Daten den aus die du speichern willst?

Fahrzeug daten könnten schnell dokument artig werden,
wo dann nosql Geschichten gut sein könnten.

Bist du dir im aufbau nicht sicher würde ich zu postgresql raten weil du da beides machen kannst.

Wenn du eine einfach relationale db haben willst, geht auch mysql.

 

[VipE]

gut - hat sich wohl nicht viel geändert in den letzten 3Jahren^^
dann werd ich mal zu MySQL greifen - danke

 

[Cool Master]

Ich kann auch noch PHPMyAdmin im dne Raum werfen macht das administrieren deutlich leichter

 

[Daaron]

Ich kann auch noch PHPMyAdmin im dne Raum werfen macht das administrieren deutlich leichter

Thema verfehlt... Eine identische webbasierte Verwaltung gibts z.B. auch für PostgreSQL (ich glaub phpPgAdmin). Also vollkommen egal. Außerdem sollte man die Wahl der Datenbank nie davon abhängig machen, dass es eine bequem-noobige Verwaltungsoberfläche gibt.

Zum Thema selbst:
Mit MySQL macht man wenig falsch, MySQL hat aber ein riesiges Problem: Die Anzahl der Spalten einer Tabelle. Wenn eine Tabelle zu komplex wird, insbesondere wenn sie zu viele Varchar-Spalten enthält, dann stößt man recht zügig an die 64kB-Grenze von MySQL.
Wenn die Spalten-Deklarationen also zu komplex werden, dann ist von MySQL abzuraten, dann wäre PostgreSQL die bessere Wahl, das kann signifikant mehr Spalten pro Tabelle verwalten.

Außerdem: Wenn man MySQL einsetzen kann für ein Projekt, dann sollte man trotzdem eher darüber nachdenken, von MySQL selbst Abstand zu nehmen. MariaDB wäre die klügere Wahl. MariaDB ist vollkommen kompatibel zu MySQL, ist aber um einiges schneller als MySQL. Ob man an die Schwelle kommt, wo der Geschwindigkeitsvorteil spürbar wird, muss man natürlich vom Projekt abhängig machen.

Und wie shcon erwähnt... dann gibt es immernoch die NoSQL-Ansätze (wie z.B. Redis. das ist immerhin so schnell, dass es sogar große Pornovideo-Portale füttert), die für solche Projekte durchaus einen Blick wert sind, aber eine grundsätzlich andere Herangehensweise erfordern.

 

[Cool Master]

Thema verfehlt... Eine identische webbasierte Verwaltung gibts z.B. auch für PostgreSQL (ich glaub phpPgAdmin). Also vollkommen egal. Außerdem sollte man die Wahl der Datenbank nie davon abhängig machen, dass es eine bequem-noobige Verwaltungsoberfläche gibt.

Der TE hat ja schon geschrieben das er MySQL nehmen will genau ein Post über mir also ist das Thema nicht vefehlt...

 

[ice-breaker]

Mit MySQL macht man wenig falsch, MySQL hat aber ein riesiges Problem: Die Anzahl der Spalten einer Tabelle. Wenn eine Tabelle zu komplex wird, insbesondere wenn sie zu viele Varchar-Spalten enthält, dann stößt man recht zügig an die 64kB-Grenze von MySQL.

Mit dem Barracuda-Dateiformat für InnoDB aus dem Jahre 2008 (?) sollte das ganze gar kein Problem mehr sein. Mit dem dynamischen Row-Format wird dann für jede Varchar-Spalte nur noch ein 20 Bit Pointer innerhalb der Zeile gespeichert und der gesamte Inhalt des Varchars "extern".

MariaDB wäre die klügere Wahl. MariaDB ist vollkommen kompatibel zu MySQL, ist aber um einiges schneller als MySQL.

Oder XtraDB von Percona. Als Bonusgabe erhält man gleich die kostenlose HotBackup-Lösung Xtrabackup, von InnoDB (Oracle) direkt kostet das wiederum eine ganze Menge.

 

[Daaron]

Mit dem Barracuda-Dateiformat für InnoDB aus dem Jahre 2008 (?) sollte das ganze gar kein Problem mehr sein. Mit dem dynamischen Row-Format wird dann für jede Varchar-Spalte nur noch ein 20 Bit Pointer innerhalb der Zeile gespeichert und der gesamte Inhalt des Varchars "extern".

Das ändert nichts an dem 64k - Problem, du verschiebst es bestenfalls etwas. Diese Verschiebung kannst du auch erreichen, indem du Werte statt in Feldern des Typs VARCHAR eben in TEXT oder BLOB speicherst. Trotzdem habe ich bereits Tabellen erwischt, die zu breit waren. Es kommt aber sehr selten dazu.
http://dev.mysql.com/doc/refman/5.6/en/column-count-limit.html

Oder XtraDB von Percona. Als Bonusgabe erhält man gleich die kostenlose HotBackup-Lösung Xtrabackup, von InnoDB (Oracle) direkt kostet das wiederum eine ganze Menge.

Na ja, XtraDB und MariaDB schließen sich ja nicht aus. XtraDB ist nur eine Storage Engine, während MariaDB ein komplettes RDBMS ist (bei dem man, so wie ich das seh, XtraDB nutzen kann).

Fakt ist aber: Wenn man keinen eigenen Server hosten will landet man (im Linux-Umfeld) quasi immer bei MySQL oder ab und zu noch bei PostgreSQL. Ich habe noch keinen Hoster mit MariaDB gesehen.
Fakt ist außerdem: Für die meisten Anwendungsfälle reicht MySQL so wie es ist. Da muss man noch nicht einmal großartig an Einstellungen des Server rumdoktoren.

 

[ice-breaker]

Das ändert nichts an dem 64k - Problem, du verschiebst es bestenfalls etwas. Diese Verschiebung kannst du auch erreichen, indem du Werte statt in Feldern des Typs VARCHAR eben in TEXT oder BLOB speicherst. Trotzdem habe ich bereits Tabellen erwischt, die zu breit waren. Es kommt aber sehr selten dazu.
http://dev.mysql.com/doc/refman/5.6/en/column-count-limit.html

Bei 20 Bit pro Varchar-Zeiger minus 64 Bit für den durch InnoDB automatisch erstellten PK (wenn keiner angelegt wird) sind das immerhin mehr als 3000 Spalten. Selbst mit 64 Bit Spalten (Bigint) bleibt da noch eine ganze Menge übrig.
Zumal PostgreSQL an der Ecke genauso limiert ist: maximal 250-1600 Spalten je nach Datentypen, also eine ziemlich ähnliche Limitierung wie InnoDB. Unendlich gibt es eben nicht.

 

[Daaron]

Jo, Postgre hat nicht mehr Spalten, aber eben mehr Platz für Spalten. Auf die Weise muss man eben keine Pointer einsetzen.

 

[ice-breaker]

Äh, magst du mir diese Aussage auch erklären?
Laut dem About von der PostgreSQL-Seite gibt es ein Hard-Limit von 250-1600 Spalten in einer Tabelle, eben je nach Datentyp. Also haargenau das gleiche Verhalten wie bei MySQL, die 64KB werden auf X Spalten aufgeteilt. Würde man über den Wert kommen, hat man Pech, so wie bei PostgreSQL.

 

[AlbertLast]

Wo liegt der vorteil ob nun eine rdbms 250 oder 1k spalten kann?
ich mein wenn ich so was sehen würde gebe es wohl an einer anderen Stelle wohl Probleme.

mir ist nur der bereich data warehousing bekannt wo zu mindesten man annährend bei der anzahl von 250 spalten kommt.

An sich sind andere aspekte aus meiner Sicht wichtig,
will man nur ein Knopf drücken und alles funktioniert ist man bei mysql richtig,
weil apache, php und mysql in mehren geschnürten fertig packeten gibt wie xampp.

Will man rdbms was nosql(array,hstore und json) kann und wo man OHNE Konfiguration das schnellste haben will
muss man pg nehmen, mysql ist default config ist so eingestellt das min werte genommen werden, pg geht hier eine andere Philosophie daher ist es schneller wenn man beide unkonfiguriert lässt.

Zu verachten sollte man auch nicht das Forks wie MariaDB durch weg besser in meinen augen sind als die orginal mysql version.

 

[character]

Sogar ziemlich aktuell: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

Also wir verwenden aufe Arbeit nur Postgres und bei normalen Privatprojekten mache ich das auch so.

MySQL ist meiner Meinung nach erst seit kurzem sinnvoll einsetzbar (wobei ich mich nur auf die beiden bekannten Engines beziehe). Allein, dass man sich früher effektiv zw. Transactions (InnoDB) und integrierter Full Text Search (MyISAM) entscheiden musste, fand ich bescheuert. ACID compliant ist es selbst mit InnoDB anscheinend immer noch nicht.

Mit Postgres kann man sogar im NoSQL-Stil Key-Value-Paare abspeichern.

Ich wüsste also überhaupt nicht, warum ich in einem normalen Projekt ohne extrem spezielle Anforderungen MySQL Postgres vorziehen sollte (was natürlich nicht heißt, dass es mit MySQL nicht auch irgendwie funktioniert).

 

[Daaron]

mir ist nur der bereich data warehousing bekannt wo zu mindesten man annährend bei der anzahl von 250 spalten kommt.

Ich bin hingegen bereits ans 65k-Limit bei MySQL gestoßen.
Die Ursache ist hier aber in einer Design-Schwäche von Contao (einem CMS) zu suchen. Wenn man sehr viele Addons installiert hat kann die Tabelle tl_modules extrem breit werden. Außerdem sind die meisten Inhalte in tl_modules VARCHARs (meist so bei ~120 Zeichen) und die Standard-Einstellung für Contao-Datenbanken ist MyISAM, keine Ahnung wieso DAS so ist....

Ich wüsste also überhaupt nicht, warum ich in einem normalen Projekt ohne extrem spezielle Anforderungen MySQL Postgres vorziehen sollte (was natürlich nicht heißt, dass es mit MySQL nicht auch irgendwie funktioniert).

Der große Vorteil an MySQL: Es steht halt überall zur Verfügung. Die meisten Hoster bieten standardmäßig nur MySQL an.
Außerdem: Viel wirklich nützliche Software baut auf MySQL auf. So unterstützen z.B. weder Magento noch osCommerce etwas anderes als MySQL. Auch einige Open Source CMS haben entweder keinen oder nur mittelprächtigen Support für etwas anderes MySQL. Selbst Hosting-Tools wie Plesk oder ISPConfig zielen auf MySQL ab.

Für die üblichen Aufgaben eines Webentwicklers ist deshalb MySQL (oder einer der Ableger wie MariaDB) die richtige Wahl.

 

[character]

Das mit den Tools ist natürlich richtig. Wenn ein Tool MySQL braucht, dann verwende ich eben MySQL. Dann stellt sich die ganze Frage, welche DB man verwenden soll, aber nicht, da sie sowieso durch das Tool entschieden wird.

Das Verbreitungsargument ist genau das gleiche wie bei PHP vs. Python/Ruby/etc. und meiner Meinung nach irrelevant. Wenn ich mich für eine Technologie entschieden habe, suche ich mir einen entsprechenden Hoster. Nicht andersrum. Das funktioniert genauso wie mit Speicherplatz, Traffic, Availability, etc..

Dafür gibt es ja einen Markt mit Alternativen. Zumal die Liste der Postgres- (und eben auch Python-/Ruby-/etc.-) Hoster ja auch extrem lang ist. Ob nun 1000 oder 100 Hoster in Frage kommen, ist dann irgendwie auch egal.

So oder so: Mit MySQL macht man in der Regel auch nichts falsch. Ich bevorzuge aber Postgres.