Microsoft SQL Server - warum ist der so fett?

[Django]

Hallo,

habe mir mal den Microsoft SQL Server aus dem MSDNAA angeschaut.
2 CDs - extrem aufgebläht - riesen Setup usw.

Dagegen ist MySQL gradmal 40MB gross incl. aller Werkzeuge und wird doch erfolgreich auf der ganzen Welt eingesetzt.

Kann mir jemand erklären was jetzt am MS SQL Server besonderes dran ist, das das so ein riesen Ding ist?

[peanball]

Weil er wirklich deutlich mehr kann als MySQL und weil sehr ausführliche Dokus zu allen Funktionen mit auf den CDs sind.
Außerdem sind Tonnen von Zusatzprogrammen zum Managen und als Funktionserweiterungen dabei.

MySQL ist "nur" ein Datenbankserver...

[The_Invisible]

Erazor;5269753']
MySQL ist "nur" ein Datenbankserver...

... der mehr kann als 95% der user überhaupt brauchen

mfg

[Mr.Gonzo]

... der mehr kann als 95% der user überhaupt brauchen

mfg

Du meinst eher, der mehr kann als 95% aller Webentwickler aus der Designer-Ecke, die von mehr auch maßlos überfordert wären.

[The_Invisible]

Du meinst eher, der mehr kann als 95% aller Webentwickler aus der Designer-Ecke, die von mehr auch maßlos überfordert wären.

für die zielgruppe kann sogar sqlite schon zuviel :D

mfg

[Django]

Du meinst eher, der mehr kann als 95% aller Webentwickler aus der Designer-Ecke, die von mehr auch maßlos überfordert wären.

Für welche Zielgruppe ist denn der MS SQL Server?

[nn23]

Unternehmen mit mehr als einem datenbank-server, ganzen clustern und datenbankgrößen bis zu ca. 1 Exabyte?

[peanball]

Dazu noch Data Mining, Reporting und sonstige lustige Sachen.

Mit der Version 2005 ist jetzt auch eine Message Queue (Service Broker) und Webservice-Endpoints mit drin. Die Datentransformationstools sind jetzt nochmal deutlich mächtiger.

Dazu noch die grundlegenden Funktionen einer anständigen Datenbank wie Trigger, Procedures, (verteilte) Transaktionen, u.s.w. Auf jeden Fall kein Vergleich zur reichlich unvollständigen MySQL Engine.

[Django]

Erazor;5271803']Dazu noch Data Mining, Reporting und sonstige lustige Sachen.

Mit der Version 2005 ist jetzt auch eine Message Queue (Service Broker) und Webservice-Endpoints mit drin. Die Datentransformationstools sind jetzt nochmal deutlich mächtiger.

Dazu noch die grundlegenden Funktionen einer anständigen Datenbank wie Trigger, Procedures, (verteilte) Transaktionen, u.s.w. Auf jeden Fall kein Vergleich zur reichlich unvollständigen MySQL Engine.

Aber für Webanwendungen sollte doch MySQL auf jedenfall reichen oder?

[mbee]

Aber für Webanwendungen sollte doch MySQL auf jedenfall reichen oder?

Kann man so nicht pauschalisieren: Auch Web-Anwendungen können hochgradig komplex sein bzw. hohe Anforderungen an ein DB-System stellen, weshalb neben MySQL ja u.a. auch PostgreSQL (IMO, zumindest früher das "bessere" MySQL), Oracle oder auch SQL-Server zum Einsatz kommen. Wird z.B. mit .NET entwickelt, bietet sich aufgrund der besseren Integration natürlich auch eher SQL-Server an.

[peanball]

Für ein billiges Guestbook, ein Blog oder sowas reichts sicher. Wobei man halt bei MySQL relativ viel Code für die Datenintegrität selbst ausprogrammieren muss. Da bieten andere Datenbanksysteme, wie die von mbee benannten deutlich mehr Möglichkeiten sowas deklarativ zu machen (also bei der Definition der Tabellen Zusammenhänge und Checks definieren).

Ich denke es ist insgesamt einfacher solche Bedingungen zu deklarieren als richtig auszuprogrammieren.

(Ich habe wirklich lange Zeit mit MySQL gearbeitet, wurde aber im letzten Jahr vom SQL Server 2005 verwöhnt ;))

[MadMan2k]

naja immerhin reicht MySQL um Wikipedia zu versorgen...

[iDiot]

Wikipedia hat kaum Datenmengen, da alles Text ist. Soweit ich mich erinnern kann hat Wiki komplett um die 100GB.

[TheGamer]

Wikipedia hat kaum Datenmengen, da alles Text ist. Soweit ich mich erinnern kann hat Wiki komplett um die 100GB.

Eben und 100 GB sind klein. Bei grossen DMS Systemen inkl BlobStores siehts ganz anderst aus

[HellHorse]

Kann man so nicht pauschalisieren: Auch Web-Anwendungen können hochgradig komplex sein bzw. hohe Anforderungen an ein DB-System stellen, weshalb neben MySQL ja u.a. auch PostgreSQL (IMO, zumindest früher das "bessere" MySQL), Oracle oder auch SQL-Server zum Einsatz kommen. Wird z.B. mit .NET entwickelt, bietet sich aufgrund der besseren Integration natürlich auch eher SQL-Server an.
So wenig ich MySQL mag, so muss ich doch zugestehen dass diverse, grosse Web (2.0) Anwendungen (flickr, del.ico.us, digg, ...) es erfolgreich verwenden. Und so sehr ich PostgreS auch mag, es suckt wenn es um Replikation geht während das Standard MySQL Setup gar nicht ohne Replikation auskommt (InnoDB Master für IUD, MyISAM Slave für S (Textindices)).

Dagegen hat MySpace, welches auf SQL-Server setzt diverse Skalierungsprobleme (Ok sie scheinen auch nicht besonders clever zu sein, z.B. haben sie Caching erst verdammt spät eingebaut. Ok, auch Wikipedia unternimmt verdammt viel, dass ein Request die DB nicht berührt.).

[Muh-sagt-die-Kuh]

MySQL und PostgreSQL sind für "normale" Datenbanken vollkommen ausreichend...für die Verwendung in großen Unternehmensdatenbanken fehlen ihnen aber einfach einige Features...

[peanball]

MySQL und PostgreSQL sind für "normale" Datenbanken vollkommen ausreichend...
Kommt drauf an, wie viele der Integritätschecks du in deiner "normalen" Datenbank halten möchtest, um diese zu einem in sich konsistenten System zu machen, auch wenn du nicht mit dem vorgesehenen Client (z.B. deiner Webanwendung) drangehst.
Der normale PHP-Coder/Frickler-Ansatz ist ja, die Datenbank als dummen Datenspeicher zu betrachten und für die Integrität dann im Programm oder garnicht zu sorgen (ich spreche aus eigener Erfahrung ;))

[The_Invisible]

Erazor;5371889']Kommt drauf an, wie viele der Integritätschecks du in deiner "normalen" Datenbank halten möchtest, um diese zu einem in sich konsistenten System zu machen, auch wenn du nicht mit dem vorgesehenen Client (z.B. deiner Webanwendung) drangehst.
Der normale PHP-Coder/Frickler-Ansatz ist ja, die Datenbank als dummen Datenspeicher zu betrachten und für die Integrität dann im Programm oder garnicht zu sorgen (ich spreche aus eigener Erfahrung ;))

ja, auch das stimmt für 95% der User

deshalb verwende ich eigentlich als reinen datenspeicher nur mehr sqlite, auf den komfort von sql abfragen will ich nämlich nicht mehr verzichten

mfg

[Muh-sagt-die-Kuh]

Erazor;5371889']Kommt drauf an, wie viele der Integritätschecks du in deiner "normalen" Datenbank halten möchtest, um diese zu einem in sich konsistenten System zu machen, auch wenn du nicht mit dem vorgesehenen Client (z.B. deiner Webanwendung) drangehst.
Der normale PHP-Coder/Frickler-Ansatz ist ja, die Datenbank als dummen Datenspeicher zu betrachten und für die Integrität dann im Programm oder garnicht zu sorgen (ich spreche aus eigener Erfahrung ;))Ich kenne das auch aus Erfahrung....besonders solche Sachen wie nicht definierte Foreign-Key Constraints sind sehr spassig ;) Wie du bereits sagst, in einer fest definierten Umgebung ist das handhabbar, weicht man davon ab wirds grausig....