Welche Datenbank ist die sinnvollste für ein Lagerverwaltungsprogramm?

Hallo Leute, ich stehe vor ein Problem und zwar ich soll ein Lagerverwaltungsprogramm erstellen, und es soll möglich sein dass viele Clients gleichzeitig Zugriff auf die Datenbank haben. Ich möchte das Ganze mit Visual Studio 2010 und C# realisieren.

Welche Datenbank (siehe Anhang) ist für diese Anwendung die sinnvollste für riesige Datenmengen und gleichzeitige Zugriff durch Clients.

Vielen Dank im Voraus

Besserer Ansatz: Clients kommunizieren nicht direkt mit der Datenbank, sondern mit einem Service (Client-Server-Architektur).
Das ist eine Schicht mehr in der Architektur; macht die Umsetzung aber leichter und flexibler.
Änderungen an der Datenbank resultieren zB nicht anschließend in einem Update aller Clients etc etc....

Riesige Datenmengen ist relativ.
Wenn wir von wirklich riesigen Datenmengen reden wäre die Frage, welche Anforderungen noch so alles auftauchen.
Von den Datenbanken, die Du da zeigst, ist nur der SQL Server eine echte Datenbank. Der Rest ist ungeeignet (SqlCe) oder eine Krankheit (Access / ODBC).

Also Fuß vom Gas und erst mal die Anforderungen evaluieren.
Anschließend kannst Du Dich entscheiden ob es ein SQL Server (MSSQL Express, ProstgreSQL) oder eine NoSQL Datenbank (MongoDb, CouchDb..) wird.
Und dann spielt natürlich immer die Architektur der Entitäten, also das Datenbankmodell eine Rolle. Du überspringst mindestens 3 Schritte in einem regulären und korrekten Entwicklungszyklus.

Vielen Dank für die schnelle Antwort.

Gibt es ein Buch das sich speziell mit dem Thema befasst? Eventuell eine Buchempfehlung für sql Server, Clients. Um ein besseren Überblick und Verständnis dafür zu entwickeln?

Gibt es ein Buch das sich speziell mit dem Thema befasst?

Bestimmt 😉
Ich halt aber nichts von Büchern in der Software-Entwicklung (da sie oft veraltet sind, was bei Datenbanken jetzt aber weniger der Fall ist - außer Bücher über allgemeine Architekture etc) deswegen kann ich Dir hier nichts empfehlen.

Alles klar, kein Problem.

Hallo Jimmakos,

nimm am besten den Microsoft SQL Server, der ist gut in das Visual Studio integriert und auch für größere Datenmengen geeignet.

"Riesige Datenmengen" ist ein relativer Begriff, für den SQL Server würde das heißen das täglich mehrere Millionen Datensätze hinzukommen.

Es gibt das Buch "Datenbankprogrammierung in C#", das relativ gut die Datenbank-Grundlagen beschreibt.
Es fehlt aber bisher der wichtige Teil Entity Framework und andere ORM.

EDIT : Ich sehe gerade das in der aktuellen Auflage, die ich nicht kenne, auch LINQ und ADO.NET Entity Framework ausgiebig besprochen werden.

Grüße Bernd

Hallo Bernd

vielen Dank für den Tipp, ich habe versucht SQL Server2008 (integriert in Visual Studio 2010 Ultimate) zu starten aber ich kriege das irgendwie nicht hin. Folgende Meldung kommt (siehe Anhang)

Da steht doch da, dass Du das Installationsmedium von SQL2008 (der in VS2010 liegt) auswählen sollst (wobei VS normalerweise Express installiert).
Was erwartest Du nun von uns? Dass wir Dir sagen, wo bei Dir die Installationsdateien liegen? 🤔

Lad Dir einfach den SQL Express 2012 / 2010 runter und installier den...

Ich frage weil ich schon gesucht habe und es nicht finden kann.

Sonst würde ich hier nicht fragen. Ich habe auch im Log geschaut, finde es aber nicht.

Da liegt bei dir nur ein großes Missverständnis vor.

Man startet den SqlServer nicht, das ist ein Dienst, der bei dir sehr wahrscheinlich schon läuft.

Du hast Recht der läuft schon.

👍

Hallo Bernd das von dir vorgeschlagene Buch ist echt gut! Werde mich die nächsten Monaten damit beschäftigen.

Guter Tipp! 👍 👍 👍

Aus der Liste, die oben gepostet wurde, würde ich bei großen Datenmengen unbedingt zu Oracle raten. Der SQL Server ist zwar einfacher/intuitiver in der Handhabung, hat aber gerade wenn die Tabellen sehr groß werden, häufiger mal Performanceprobleme (Stichwort Indexierung).

@Abt: Oracle als "keine echte Datenbank" zu bezeichnen ist wirklich daneben...

Wie sieht es mit der Kapazität der Datenbank (Oracle)? Gibt es da Grenzen im Gegensatz zu der SQL-Server?

Mallett hat den Hintergrund meines Posts nicht verstanden; statt dem nachzuhaken hat er diese Behauptung aufgestellt (bereits per PN geklärt)- lass ich so aber mal stehen.

Oracle wie auch SQL Server sind beides echte DBMS - selbstverständlich.
SQL Express hat in der aktuellen Variante ein Limit von 1GB Speicher, 10GB DB Größe und 1 CPU. Das Limit der Vollversion einer DB liegt glaub ich bei 524 PB, bei 8 CPUs und 2TB RAM.

Oracle bietet DB Größen bis 40 EB. Sollte also ein Weilchen reichen...

Sowohl SQL Server als auch Oracle sind nur in den kostenlosen Express-Versionen limitiert.
Die Limitierungen der Oracle XE (kostenlos) Version findest Du hier:

Oracle XE Licensing Limitations

Ok Leute das habe ich gefunden:

MySQL:

• Umsonst
• große Community
• Viele foren etc
• viele tutorials
• sie unterstütz quasi alles was man braucht
• gute tuning möglichkeiten

• die weitergehenden features wie Spiegelung archivierung etc sind vorhanden, aber nahezu unbekannt und es ist auch quasi unmöglich trainings dafür zu bekommen
• nicht jede komerzielle software unterstützt die datenbank.

MS-Sql:
+guter MS support

• Viele User / foren / community etc auch über weiterführende features
• viele Features zum tunen
• viele kommerzielle trainings
  +wird häüfig im mitelstand eingesetzt

• teure lizensen

Oracle

• extrem weit im enterprise markt verbreitet
• sehr vielle kommerzielle trainings
  +s ehr große community / Foren etc
• auch gute dokumentation der weitergehenden features
• sehr viele bücher von den unterschiedlichsten verlagen
• guter oracle support
• steht auf allen prozessorarchitekturen zu verfügung
• kostenlose testversion
  +wird von jedem kommerziellen softwarehersteller unterstützt

• die enterprise version kostet pro prozessor je nach reseller ~30.000 oder 500 euro pro user

Ich habe mich für Oracle entschieden.

Danke an alle. Ich muss mich da als erstes einarbeiten. =)

Danke für den Link: 👍 👍 👍

Deine Auflistung stimmt so definitiv nicht und ist seeehr Oberflächlich.
mysql ist gewiss nicht umsonst, siehe Kann man mySQL kostenlos in/für kommerzielle Anwendungen nutzen. Eine Alternative hierfür ist eher postegreSQL.

Seit SAP Oracle durch DB2 ersetzt hat schwinden die Marktanteile von Oracle.
Oracle is eher High-Enterprisebereich und MSSQL Querbeet fokussiert.

Für Anfänger und Projekte, für die sich die Maximalleistung von Oracle nicht lohnen, ist eher MSSQL zu empfehlen...
Der SQL Express reicht sowieso 90% der Anwendungen aus und wer riesige Datenberge benötigt wird bei Neuentwicklungen auch nicht unbedingt direkt auf Oracle gehen.
Da gibt es andere Datenbanken, die da ihren Erfolg haben (zB eben NoSQL Datenbanken)

Aber ich streit mich da nicht. Nur wird es für Nicht-ERP-Anwendungen nicht unbedingt nötig sein, Oracle zu nutzen.
ERP Systeme profitieren hier eben von besseren Transaktionssystem und bessere Umsetzungen von Trigger, Cursor und Co. Brauchen aber wie gesagt 99,9% der Anwendungen ohnehin nicht.
Ich muss mich selbst damit ab und zu rumschlagen und würde viel lieber MSSQL für die meisten Dinge mit ACID-Requirements Dinge nutzen.

Also, nicht, dass es falsch rüber kommt. Ich halte MSSQL durchaus für eine gute Datenbank und würde auch für die durchschnittliche Anwendung oder für Privatnutzer aus Gründen der Einfachheit dazu raten.

Speziell bei großen Datenmengen, um die es hier zu gehen scheint, oder bei kommerziellen Projekten, bei denen es verstärkt um Performance geht, würde ich heute überwiegend auf Oracle setzen. Quelle sind hier (teils schmerzliche) Erfahrungswerte.

Das hat auch nichts mit Maximallösung zu tun, die Lizenzkosten einer SQL Server Enterprise oder Business Edition dürften sicher auch um die 10.000 € liegen. Für die allermeisten Standardanwendungen sind aber ohnehin die Express-Versionen von Microsoft oder Oracle ausreichend.

Zu MySQL und dergleichen kann ich nichts sagen, würde ich mir aber für eine Anwendung, für die ich später Support leisten und vor einem Kunden meinen Kopf hin halten muss, erst recht nicht antun.

Also ich hab bisher sehr gute Erfahrungen mit Postgres mit NpgSql gemacht. Und im Gegensatz zu den meisten bisher genannten Alternativen ist es tatsächlich kostenlos.

Christian

Musst du dich unbedingt für eine Datenbank entscheiden? Wäre eigentlich besser, möglichst datenbankunabhängig zu bleiben und eine Zwischenschicht wie ORM zu verwenden. So ganz habe ich nicht verstanden, was du genau machen willst. Es macht schon einen Unterschied, ob es ein Spezialauftrag für einen Kunden ist, oder ob ihr das als eigenes Produkt für mehrere Kunden anbieten wollt. Wenn mehrere Kunden das verwenden sollen, wäre es auf jeden Fall besser, die Datenbank austauschen zu können. Wenn es nur um einen Kunden geht, lohnt sich der zusätzliche Aufwand einer Zwischensicht nicht. Kommt auch drauf an, wie stark du verschiedene Datenbankfeatures nutzen willst. Wenn die gesamte Anwendungslogik in deinem Programm bzw. in einem Application Server implementiert ist und die Datenbank wirkilch nur für die Ablage von Daten dient, sollte sich das DBMS relativ leicht austauschen lassen. Wenn du aber mehr Logik in der Datenbank implementieren willst, und sowas wie Trigger, Stored Procedures, Notification Services, Message Queues und sonst was nutzen willst, wirst du die Datenbank natürlich schlecht austauschen können.

Was sind für dich "riesige Datenmengen" und wer soll sich um die Datenbank kümmern? Oracle ist sehr mächtig, aber damit muss sich jemand auskennen, sonst kann das auch leicht mal schnell "kaputt gehen" und ist dann sehr langsam, und man sieht erstmal nicht warum. Wir hatten mal einen Kunden, der wenn ich mich recht erinnere Tabellen mit 15 Mrd Einträgen in der Oracle Datenbank hatte. Und die hatten extreme Performance Probleme, und irgendwann haben sie es dann doch auf die Reihe bekommen, aber deren Admins haben das nicht geschafft.

Bei unserer Software ist die Datenbankanbindung eher nebensächlich, wir arbeiten im Maschinenbaubereich. Da ist aber wichtig, dass man die Datenbank austauschen kann. Wir haben nur große Kunden, und die haben alle eine IT Abteilung und irgendeine Datenbank, und da wärs ganz schlecht, wenn wir vorschreiben würden, was für eine Datenbank die verwenden sollen. Praktisch müssen wir nur Oracle (die meisten Kunden) und den SQL Server (grob geschätzt 20%) unterstützen, nur ein Kunde hat DB2, sonst kenne ich nichts.

Speziell bei großen Datenmengen, um die es hier zu gehen scheint, oder bei kommerziellen Projekten, bei denen es verstärkt um Performance geht, würde ich heute überwiegend auf Oracle setzen. Quelle sind hier (teils schmerzliche) Erfahrungswerte.

Also bei uns im Betrieb nutzen wir MSSQL-Compact für unser PIM-System. Die Datenbank dient dabei nur Kommunikations-Einheit, mit der zwischen den verschiedenen Modulen Daten verschoben werden. Probleme gibt es theoretisch, wenn mehrere Millionen Datensätze verschoben werden sollen, was wir aber bisher nur bei Performance-Tests erreicht haben. Kunden erreichen sehr selten gerade einmal die Million Datensätze. By the way: Ein Datensatz ist in dem Fall die zusammen gefasste Menge von einer ganzen Reihe Tabellen, ich rede hier von einem kompletten Export-Test.
Und über Performance reden wir, wenn einige 10.000 bis ein paar 100.000 Datensätze auf einen Schlag bewegt werden sollen, vorher lohnt das nicht, da Optimierungen nur geringe Verbesserungen bringen würden, die kaum auf fallen.
Ob der MSSQL-Server schneller ist, kann ich nicht sagen, aber langsamer wird er wohl eher nicht sein.

Und der Größen-Unterschied bei den Voll-Versionen von MSSQL zu Oracle (524 PB zu 40 EB) ist zwar groß, aber mal ehrlich: Wie lange dauert es, zumindest einen TB voll zu kriegen?
Für uns reicht das NTFS-bedingte Limit von rund 4 GB bisher noch völlig aus. Wir schauen gerade, wie wir für die Zukunft einfach erweitern, aber 4 GB sind nur 4 GB und das ist heutzutage verdammt wenig. Der Platz, den eine gekaufte Version von MSSQL bietet, das ist das 131*10^15 fache von den winzigen 4 GB (Einheiten im Vergleich). Die 40 EB muss ich gar nicht erst nach rechnen um zu wissen, dass das utopisch ist. Ich mein, welche riesigen Server-Berge bräuchte man, um das Daten-Volumen überhaupt anbieten zu können?

Was ich sagen will: Ich halte es für Blödsinn, sich bei den beiden Varianten Gedanken über ein Limit zu machen.
Vielleicht denkt Google darüber nach, oder die NSA, oder sonst wer, die ja auch genug Speicher-Kapazität anbieten können, wobei ich mir da auch nicht sicher bin.

Meine Meinung daher:

MSSQL oder Oracle, nimm das, was einfacher ist.
Meine Wahl wäre MSSQL, einfach weil ich es kenne und wenn Coder007 jetzt noch sagt, dass Oracle mächtig aber schwierig ist, fällt diese Datenbank-Server sofort raus, da in der Regel nur ein kleiner Teil von den Möglichkeiten des Servers wirklich genutzt wird.
Dennoch wäre es sinnvoll, die Möglichkeit eines Wechsels in der Software zu bieten, wie Coder007 ja schon beschreibt. Das ist sowieso immer sinnvoll, da du nie weißt, was in der Zukunft passiert.

Wo es vielleicht einen Unterschied gibt, der interessant wäre:
Wann fällt eine größere Zahl Verbindungen zur Datenbank auf und Welche bietet da die bessere Performance?
Wobei ich da auch nicht glaube, dass bei einem Lagerverwaltungsprogramm so viele Clients gleichzeitig darauf zugreifen, dass das Probleme geben könnte.

Jimmakos82, lass dich nicht von Unterschiedenen leiten, die in den Zahlen vielleicht groß aus sehen.
Bevor du wegen dieser Entscheidung Probleme bekommst, geht viel Zeit ins Land, wenn das überhaupt passiert.

Ich hab mein leben lang mit MSSQL gearbeitet und würde prinzipiell immer wieder zu MSSQL tendieren. In letzter Zeit arbeite ich auch mit Oracle und würde immer wieder zu MSSQL tendieren 😃

Also beide Systeme haben ihre Vor- und Nachteile. Wie schon erwähnt, ist der MSSQL Express für die meisten kleinen Systeme vollkommen ausreichend. In deiner Auflistung Jimmakos82 ist bei MSSQL ein Negativpunkt die Lizenzkosten!? Also bitte, konfiguriere mal ein Oracle Enterprise mit Tuning Advisor, Fremd DB Listener, Replikation usw... Für den Betrag kauf ich mir mehrere MSSQL Enterprise Lizenzen und das einmalig und nicht pro Jahr. Wenn Oracle nicht langsam ihr Lizenzmodell ändert, haben die bald keine Kunden mehr. Das Oracle so verbreitet ist, hat allein historische Gründe und immer mehr Firmen wenden sich von Oracle ab. Und das nicht nur im DBMS Bereich.

Auch der Punkt, dass Oracle mehr im Enterprise Bereich unterwegs ist und ja größere Datenmengen "beherrscht" ist ein weit verbreiteter Irrglaube. Habe schon Datenbanken in MSSQL mit mehreren TB verwaltet. Geht alles. Alleine das Datenbankschema zählt. Passt das nicht, muss man sich nicht wundern, wenn man Performance Probleme hat.

Aber wie gesagt, Oracle hat auch interessante Vorteile, wie z.B. Materialized Views, oder alleine das Package System. PL/SQL ist auch ehrlich gesesagt dem TSQL um längen vorraus (IMHO). Das Backup und Recovery finde ich bei Oracle besser gelöst als bei MSSQL, aber das kommt auch nur zum Tragen, wenn man hier von großen Mengen spricht. Zudem kann Oracle auch unter Linux betrieben werden, was bei Großkunden gut ankommt.

Desweiteren muss ich Coder007 etwas wiedersprechen 😃. Datenunabhängigkeit ist natürlich was gutes, und man sollte dies ggf. bei der Entwicklung in Betracht ziehen. Nur kenne ich persönlich nicht ein Produkt, welches dies wirklich durchzieht. Heutzutage entscheiden Controller und Gremien welche Software für ein Unternehmen gekauft wird (ich gehe hier jetzt mal von Investitionen in ≥ 6 Stellig ein). Sobald da ein Produkt kommt, mit "Ich kann mit jeder DB" ist dies meist sofort raus, weil das Denken herrscht "Oh, dann ist das darauf ja nicht spezialisiert". Weil die Entscheider nicht die Technik kennen, den interessieren die Funktion und was es kostet (alles schon erlebt). Und wenn man die Leute mit der Software überzeugt hat, ist das Geld für ein ggf. anderes DBMS auch meist da. Und spätestens, wenn man bei einer Entwicklung an DBMS spezifische Fearures ran geht (z.B. FILESTREAM im MSSQL) ist man eh raus aus der Nummer. Ich würde auf Datenbankunabhängigkeit verzichten.

Von der administration her nehmen sich ehrlich gesagt beide nichts. Man kann bei beiden System was "kaputt" machen, wenn man was verkonfiguriert. Das ist kein Argument. Man muss schon das System kennen auf dem man arbeitet, sonst nützt es nichts.

Was mich mal interessieren würde Jimmakos82, was du denn von der DB erwartest? Ich kenne soviel Produkte, die MSSQL oder Oracle nutzen, aber deren Features gerade mal zu 10% ausnutzen. Viel Datenvolumen sagt ja nichts aus. Brauchst du Hochverfügbarkeit? Brauchst du 100%ige Sicherheit vor Datenausfälle? Und die alles entscheidenden Fragen sind, mit wie viel Transaktionen pro Sekunde rechnest du? Wieviel IO pro Sekunde? Denn da gibt es wirklich unterschiede zwischen MSSQL und Oracle.

Also die Rede ist von etwa ca. 100 Clients die Daten mit der Datenbank tauschen werden und zwar in der Hauptgeschäftszeit. Es werden Aufjedenfall eine Menge an Daten sein. Ich möchte nicht irgendwann das die Datenbank zusammenkracht oder am Volumen versagt.

Hi Jimmakos82,

Ich möchte nicht irgendwann das die Datenbank zusammenkracht oder am Volumen versagt.

ich glaube, du hast da falsche Vorstellungen. Alle genannten Datenbanken sind jeden Tag bei tausenden Unternehmen im produktiven Einsatz. Wenn da etwas schief geht, liegt es nicht an der Wahl des falschen Datenbank-Systems, sondern an unsachgemäßer Bedienung.

Die Maximalgröße des (kostenlosen) SQL-Server Express ist wie oben schon erwähnt begrenzt, aber es geht auch um die richtige Wahl der Indizes und viele andere Sachen mehr.

Also die Rede ist von etwa ca. 100 Clients die Daten mit der Datenbank tauschen werden und zwar in der Hauptgeschäftszeit.

Das beantwortet zwar nicht die Fragen von Khalid, aber es klingt, als würden eine Menge Kunden von der DB abhängig sein. In dem Fall würde ich mich an deiner Stelle erstmal mit den Grundlagen zu Datenbanken, SQL und weiterführenden Themen beschäftigen. Bitte fasse das nicht als Unterstellung auf, aber wer gerade zum ersten Mal den Datenbank-Dialog im VisualStudio gesehen hat, ist wirklich nicht in der Lage, ein solches Projekt umzusetzen.

Christian

Bei 100 Clients würde ich auch nicht direkt auf die DB gehen, sondern einen Service dazwischen schalten, der evtl. auch ein Caching und horizontale Skalierung und Co direkt übernimmt.

aber wer gerade zum ersten Mal den Datenbank-Dialog im VisualStudio gesehen hat, ist wirklich nicht in der Lage, ein solches Projekt umzusetzen

Und genau deswegen hab' ich Oracle oben erst gar nicht erwähnt, da Oracle für Anfänger mit Sicherheit nicht das richtige DBMS darstellt.
Vieles in Oracle ist nicht ganz so einfach/intuitiv gelöst, wenn man zB mit einem ORM wie dem Entity Framework arbeitet. Hier gibt es einfach teilweise Fehlermeldungen, die unter MSSQL deutlich klarer sind.

Ich würde Dir also wie MrSparke echt empfehlen sich die Grundlagen anzueignen und - fürs erste - auch von Oracle etwas Abstand zu nehmen.
Du wirst weder bei MSSQL noch bei Oracle auch nur annähernd an die Grenzen kommen und Du wirst mit Gewissheit nicht alle Features nutzen - egal von welchem Produkt.
Aber MSSQL ist eben in der .NET-Welt deutlich weiter verbreitet und Du wirst am Anfang mit Sicherheit sehr viel Fragen haben; und bei Oracle auf nicht ganz so viele offene Ohren stoßen.

Mach Dir also das Leben nicht unnötig schwer.
Eigne Dir die Grundlagen an, PLan es sauber und dann mach Dich ran ans Geschäft.

Und bevor das ganze nun noch in einer elendig langen Diskussion endet und das Thema sich unnötig wiederholt mach ich hier zu.
Sofern Du dann wieder spezifische Fragen zu Deinem Vorhaben hast, kannst Du gern ein neues Thema eröffnen. Aber hier ist jetzt eigentlich alles gesagt.