[Sclot]

So...
Ich teste ja nun mittlerweile schon knapp 3 Monate mit C# rum...
So langsam müsste ich mich für eine DB entscheiden - unabhängig davon das ich Visual Studio 2005 benutze.

Was wäre denn für den kunden am "Besten" - Das die kosten beim MySQL wahrscheinlich weniger sein werden ist mir klar (zumindest die in der Anschaffung).
Aber wenn es um Performace geht, Datensicherheit, etc...?
Beim MSSQL gibts irgendwie tausend Tools dazu wofür kein mensch weiss wozu man die braucht.

Eine DB soll doch nur zuverlässig und schnell Daten speichern und abrufen können (wobei eine Report-Anbindung wohl auch eine nette Sache ist).


Ja...
Ich denke doch mal das einige von euch da sehr viel mehr Erfahrung haben als ich.

Sagt mal was zum Thema...

Danke.

[mepeisen]

Zitat von Sclot

Das die kosten beim MySQL wahrscheinlich weniger sein werden ist mir klar (zumindest die in der Anschaffung).

Das ist ein Trugschluss, zumindest im Enterprise-Bereich. Wenn man irgendwann einmal in die Verlegenheit kommt, in Richtung Datenbank-Cluster und Repliken zu denken, ist hier IMHO Microsoft im Preis-/Leistungsverhältnis vorne. Enterprise-Services lässt sich auch die MySQL Group gut bezahlen in Deutschland.

Ansonsten schlägt wohl das Argument der niedrigeren Anschaffungskosten bzw. Betriebskosten durch. Performance ist so eine geschichte. Ich fahre nach wie vor mit der Argumentation sehr gut, dass MySQL mit relativ überschaubare Datenmengen (mal in Millionen gemessen, denn Tabellen mit 10 oder 100 Datensätzen sind albern) und mit überschaubaren SQLs mit am besten zurecht kommt. Bei aufwendigeren Tabellen und vielen Joins respektive vielen Subselects kommt kein DB-System sofort gut zurecht. Man muss dann eigentlich immer alles speziell für das jeweilige DB-System tunen durch richtige Verwendung von Indizes und richtige Vorformulierung, so dass der Optimizer genau das tut, was er soll. Und pauschale Performance gibt es so nicht. Das ist übrigens der Grund, warum sich solche Performance-Vergleichstests immer massiv unterscheiden.

Der Vorteil von MySQL liegt ganz klar auch in der Betriebssystemfreiheit.

Zitat von Sclot

Beim MSSQL gibts irgendwie tausend Tools dazu wofür kein mensch weiss wozu man die braucht.

Naja, die wichtigsten Tools kenne ich. Aber prinzipiell nicht wirklich ein Argument für oder gegen MSSQL.

Zitat von Sclot

Eine DB soll doch nur zuverlässig und schnell Daten speichern und abrufen können (wobei eine Report-Anbindung wohl auch eine nette Sache ist).

Jein. Das ist aber die Diskussion über das "geeigneter". Das kommt immer auch auf die Anwendungsfälle drauf an. Fakt ist, dass Microsoft hier einen massiven Vorsprung hat, was aber enorm teuer ist. Der Vorsprung wird auch von Jahr zu Jahr eher größer, eben durch die engeren Verzahnungen von Betriebssystemen, Office, MS Project, Visual Studio, Datenbank. Die Verzahnung von all dem zu großen Gesamtprodukten, das generieren von Reports in Word usw. Diese Reporting-Funktionalitäten und die Integration von Workflows usw. in das Datenbanksystem, das sind alles Dinge, die zwar hübsch sind und einem in komplexen Systemen richtig gut unter die Arme greifen können, aber wenn man sie wirklich braucht, sind die sehr sehr teuer.

[Sclot]

Das is ja schon mal ein guter Anfang... werd mir mal noch was dazu überlegen

[FloB]

Zitat von Sclot

Beim MSSQL gibts irgendwie tausend Tools dazu wofür kein mensch weiss wozu man die braucht.

Das waere fuer mich ein Hinderrungsgrund. Denn je mehr Features da sind, desto Fehleranfaelliger sind diese. Und wenn man noch nicht mal weiss, was die bewirken ..

Aber ich kann das nicht so direkt sagen, da ich bis jetzt aktiv nur mit Mini-DBs mit MySQL gearbeitet habe.

[Jann Hendrik]

Zitat von FloB

Das waere fuer mich ein Hinderrungsgrund. Denn je mehr Features da sind, desto Fehleranfaelliger sind diese.

Stimmt - voll das Argument.

Nur weil es für Windows (im Vergleich mit anderen Betriebssystemen) am meisten Programme gibt (Word, Firefox, icq, ....) ist das Windows so fehleranfällig.

Coole Erklärung!

[Sclot]

Mittlerweile habe ich mich noch ein bissl näher mit der Thematik auseinandergesetzt.
Probleme machte die Benutzer-Authentifizierung im MSSQL - mann kann dort zwar sehr schön angeben ob SQl-Auth oder Domänen-Benutzer verwendet werden soll (was auch irgendwo praktisch ist) - aber so richtig funktionieren tut das ganze noch nicht (hab als nomaler Benutzer keine rechte auf meine Tabellen zuzugreifen).

Also am beispiel der Benutzer-Sachen würde ich ganz klar MySQL vorziehen, da ich da einfach mehr Hintergrundwissen habe und mir dort die "Bedienung" einfacher fällt.

Zum Thema Integration in VS.NET scheint MySQL auch nicht sehr viel hinter MSSQL her zu hinken, da es dort auch schon recht gute Lösungen gibt die das alles vereinfachen.

Zum Thema SQLITE...
Ich habe mit gestern mal das .NET Framework 3.5 mit der Beta2 vom Visual C# Express 2008 heruntergeladen und installiert.
Dabei ist mir aufgefallen das die einen Compact-SQl-Server mit ausliefern, bei dem die Datenbank wohl auch nur (wie bei SQlite) aus einer einzigen Datenbank-DATEI besteht.

Ist alles schon recht interessant irgendwo

[mepeisen]

Wie ich schrieb: Bei Standardlösungen und um einfach nur Daten zu speichern/ abzufragen, sind beide ebenbürtig.

Wo jedoch MS-SQL einen Vorsprung hat, sind Enterprise-Lösungen. Also insbesondere auch so Dinge, wie Report-Generierung, Team-Lösungen usw. Da gibt es auch mit den Visual-Studios in der Team Edition sehr viele Möglichkeiten, beispielsweise um ein ganzes Cluster aus Servern und Datenbanken zu designen und Code, sowie Datenbanken auf die Server auszuliefern usw. Wie gesagt aber sehr teuer.

Bzgl. der Rechte: Wenn mans einmal kapiert hat, ist auch hier MS dem MySQL durch Integration von AD und Konsorten voraus, was sich aber in erster Linie auf Cluster- und "Mehr-Server-Lösungen" oder verteilte Datenbanken bezieht.

[FloB]

Jann, es ist doch so. "Viele Koeche verderben den Brei", oder nicht?

Im allgemeinen steigt das Fehlerpotential durch mehr Anwendungen - einfach aus dem Grund, weil mehr Codezeilen vorhanden sind.

Wie das sich im Endeffekt auswirkt, ist die Frage.

Werden diese ganzen Tools standardmaessig geladen oder nur auf Demand? Koennen die Tools nur ueber Konsole oder z.B. auch ueber SQL-Query gestartet werden?
Wenn sie nicht standardmaessig geladen werden und wenn sie nur ueber Konsole mit der entsprechenden Berechtigung gestartet werden koennen, dann haben diese keinen Effekt - zum Thema Bugs.

[mepeisen]

Zitat von FloB

Jann, es ist doch so. "Viele Koeche verderben den Brei", oder nicht?

Im allgemeinen steigt das Fehlerpotential durch mehr Anwendungen - einfach aus dem Grund, weil mehr Codezeilen vorhanden sind.

Das ist in dem Fall Quatsch. Es geht um Tool-Unterstützung und es gibt nur eine Hand voll Tools, die ernst zu nehmen sind. Im Grunde gibt es auch nur eins oder zwei Tools, um die Datenbank selbst zu verwalten. Erst mit Sachen, die MySQL schlichtweg selber nicht im entferntesten Unterstützt (Workflow-Abbilung, Report-Generierung, Delivery usw.) werdens mehr Tools.

Zitat von FloB

Werden diese ganzen Tools standardmaessig geladen oder nur auf Demand? Koennen die Tools nur ueber Konsole oder z.B. auch ueber SQL-Query gestartet werden?

Du mißverstehst da was. Und ansonsten: On demand.

[vvz-master]

Aufgrund langer Erfahrungen im DBMS-Bereich kann ich nur sagen, dass weder MS-SQL noch MySQL für einen "ernsthaften" Betrieb in Frage kommen.
Mit ernsthaft meine ich hier größere Datenmengen so ab 100MByte, die die DB verwalten soll.
Was gegen MySQL spricht: Erhöhter Konfigurationsaufwand für stabile Datenverwaltung, schlechte Unterstützung neuer SQL-Features (Trigger, Views waren lange Zeit ein Problem, OLAP-Funktionen fehlen fast vollständig).
Was gegen MS-SQL spricht: Relativ schlechte SQL-Konformität. Kann in Speziallfällen weniger als die Konkurrenz.
Meine Empfehlung für ernsthafte Projekte ist immer IBM DB2 oder ORACLE. Da ist m.E. auch der Support am besten. Ausserdem sind diese RDBMS am weitesten verbreitet.
Das einzige, was SQL-Server den anderen RDBMS voraus hat ist die DataMining-Komponente - da gibt es nix besseres.
Also stellt sich die Frage, wofür du ein DBMS einsetzen möchtest.

[mepeisen]

Zitat von vvz-master

Aufgrund langer Erfahrungen im DBMS-Bereich kann ich nur sagen, dass weder MS-SQL noch MySQL für einen "ernsthaften" Betrieb in Frage kommen.

Mit ernsthaft meine ich hier größere Datenmengen so ab 100MByte, die die DB verwalten soll.

Stellt sich mir wirklich die Frage, was du da für ernsthafte Datenmengen meinst. Die Aussage ist so pauschal einfach quatsch und daher kann ich nicht anders als zu behaupten, dass du entweder kaum Erfahrungen mit wirklich allen Systemen gesammelt hast also in einer eigenen Welt lebst oder schlichtweg keine Ahnung hast.



Einen ernsthaften Betrieb mit kritischen Daten bekommen beide Systeme, wie auch die von dir genannten, problemlos hin. Mit großen Anfragemengen und Datenmengen kommen sie auch zurecht. MySQL ist in einigen Bereichen noch jung und grün hinter den Ohren aber spätestens seit 5.1 auch bei richtig großen Datenmengen jenseits der Gigabytes relativ geschickt (Stichwort Partitioning).

Zitat von vvz-master

Was gegen MySQL spricht: Erhöhter Konfigurationsaufwand für stabile Datenverwaltung, schlechte Unterstützung neuer SQL-Features (Trigger, Views waren lange Zeit ein Problem, OLAP-Funktionen fehlen fast vollständig).

Das ist leider falsch. Insbesondere aufgrund des von dir angestellten Vergleiches. DB2 ist in einigen Bereichen einfach nur grauselig und weisst du was, ich gebe sogar zu, dass das nur mein persönlicher Eindruck ist und andere durchaus anders drüber urteilen. Es läuft darauf hinaus, dass man sich für wirklich ernsthaften Betrieb bei jedem der vier zur Diskussion stehenden Systeme als Spezialist einarbeiten muss. Nun kann man sagen "Ich warte erst bis sich das System bzw. die Version ein Jahrzehnt auf dem Markt bewährt hat, bevor ich es ernst nehme." OK, das wäre das Totschlag-Argument für MySQL. Manche werten sowas als Nachteil, ich persönlich nicht.



Speziallösungen sind sicherlich in konkreten Fällen ein Argument, so man sie denn braucht, das war aber nicht die Frage des Autors. Da muss man sich aber immer fragen, was man konkret will. Will man sowas gar nicht, wieso ist dann MySQL oder MS-SQL gegenüber einer anderen Lösung schlechter?

Zitat von vvz-master

Was gegen MS-SQL spricht: Relativ schlechte SQL-Konformität. Kann in Speziallfällen weniger als die Konkurrenz.

Bedingt richtig. Du verschweigst jedoch, dass hier jedes System (auch DB2) gehörige Mängel mit der Ansi-Konformität (die sprichst du doch an) von Haus auf aufweisen.

Zitat von vvz-master

Meine Empfehlung für ernsthafte Projekte ist immer IBM DB2 oder ORACLE. Da ist m.E. auch der Support am besten. Ausserdem sind diese RDBMS am weitesten verbreitet.

Mit Support bei MySQL direkt kenne ich mich wenig aus, da ich bisher immer zufrieden war und bei Problemen prompt in einigen Foren Rat bekommen habe. Bei IBM sieht es sicherlich mit Support beim Betrieb besser aus (auch wenn das ne Stange Geld kostet). MySQL und MS-SQL haben eine sehr große und starke Community. Sowas werte ich immer auch mit zum Support und daher haben die in meinen Augen beide deutlich die Nase vorn. Wie gesagt persönliche Einschätzung.



Ist die Frage, was man nun als "ernsthafte Lösung" bezeichnen will.

• Ist es der Großrechnerbetrieb? Klar hat die IBM dort Vorteile in der ihr eigenen Welt alleine durch einige Jahrzehnte Vorsprung. Der Klassiker hat sich dort bereits bewährt, als es MySQL noch gar nicht gab.
• Ist es die Performance? 99% der Performance-Probleme entstehen nicht durch ein langsames Datenbanksystem oder zu große Datenmengen, sondern durch "falsche" Programmierung und "falsches" SQL. Performance-Vergleiche sind Humbug wenn man entsprechende Fallbeispiele nicht vorher auf jedem Datenbanksystem entsprechend tunt. Und trotzdem wird bei Fallbeispiel A das Datenbanksystem A deutlich schneller sein und plötzlich bei Fallbeispiel B das Datenbanksystem B. Und das behaupte ich einfach mal durch meine jahrelange Erfahrung als Entwickler. Alleine durch unterschiedliche Arbeitsweisen der Optimizer wird man es nie schaffen, dass SQL A immer von einem zum anderen Datenbank-System optimal abgearbeitet wird. Ich kann hunderte Beispiele nennen, wo man im SQL merkwürdige Handstände machen muss, nur damit man DB2 dazu bringt, einen Index zu benutzen, den MySQL mit selbigem Select sofort von Haus aus nutzt.
• Ist es die Tool-Unterstützung? Für den IT-Betrieb und für die Entwicklung gibt es von allen die erforderlichen Tools. Man nenne mir ansonsten mal konkrete Problemstellungen
• Ist es die Datenmenge? Klar, zu alten MySQL- oder MS-SQL-Versionen würde ich allzugroße Datenbanken nicht zumuten wollen. Aber wir leben nicht in 2000 oder 2002, sondern wir leben in 2007...

Ich denke, dass man sich damit anfreunden sollte, dass es stark auf die Problemstellung ankommt. Denn alle sind gut. Erst bei irgendwelchen Speziallösungen kann man was vergleichen. Der einzige wirkliche pauschale Vergleich aufgrund der Ebenbürtigkeit wären Plattformunabhängigkeit und Kosten.

[WarrenFaith]

Ich kann hunderte Beispiele nennen, wo man im SQL merkwürdige Handstände machen muss, nur damit man DB2 dazu bringt, einen Index zu benutzen, den MySQL mit selbigem Select sofort von Haus aus nutzt.

Das trifft es auf den Punkt. Es ist selbst innerhalb von einem DBS nicht sicher, ob ein Query die Indexe nutzt oder nicht. So muss man sich immer genau anschauen wie der SQL-Interpreter und Optimizer arbeiten, damit man weiß was die beste Lösung ist.