DB für CRM
-
Schönen guten Abend
Nun schon seit Samstag wühle ich mich durch diverse Foren und Beiträge und mit jedem Satz den ich lese weiß ich weniger was ich Brauche.
Folgendes soll entstehen. Ein CRM System für 5-50 Benutzer. Allerdings muss es auch mit 500 Benutzern zurecht kommen. Typischer weise wird die Nutzung so bei 5-20 Personen liegen.
Entwickelt werden soll das System in C#. So weit kein Problem (jedenfalls bisher).
Nun müssen allerdings "Unmengen" von Daten gespeichert werden. Und zwar in einer Datenbank. Die Frage die sich mir nun stellt, ist in welcher.
Was meine ich mit Unmengen von Daten. Ich denke da an ca. 250.000 Adressen im Normal-Fall. Und an Aktivitäten wie Emails und Briefe die schnell in die Mrd gehen können.
Was ist nun Wichtig.
1. Klar, die Kosten. Bei 5 Mitarbeitern ist oft nicht sooo viel Kohle über.
2. Backup-Möglichkeiten. Wartungspläne sollten leicht einzurichten sein.
3. Ausfallsicherheit.
4. Wenig administrativer Aufwand.Jetzt bin ich in dem Bereich kein ganz unbeschriebenes Blatt. Habe die letzten 1,5 Jahre eine CRM-Software betreut, die auf einem MS-SQL Server basierte. Auch dort waren bei 100 Mitarbeitern rund 400.000 Adresse und 9 Mrd Aktivitäten in der Datenbank. Wenn man nun nach einer bestimmten Aktivität gesucht hat, hat das schon mal 10 Sekunden gedauert. Das Empfinde ich als extrem lang. Klar, das kann auch am DB-Design und dem Quellcode liegen, aber dennoch wirkt ja erstmal der Server langsam. Außerdem sind die Lizenzkosten nicht ganz unerheblich.
Jetzt ist die Frage, was sind die alternativen. Habe gelesen das Oracle extrem schnell sein soll und es ähnlich SQL Server Express eine Kostenfreie Version geben soll, was für Kleinkunden sicher nicht uninteressant ist.
Auch DB2 und MaxDB wurden gelobt, allerdings scheint es hier keine Freie/Kostengünstige Version zu geben.
Nicht zu letzt läuft einem natürlich MySQL über den weg. Hier habe ich allerdings wenig gutes gelesen. Soll recht langsam sein und ein unausgereiftes Backup-System haben. Vorteil wäre hier natürlich, dass es auch unter Linux läuft.
Was wäre nun optimal. Ein DBMS, welches für kleinstkunden Kostenfrei/Kostengünstig ist und für Großkunden die Vorzüge von Enterprise-Systemen mitbringt (Dann natürlich mit entsprechenden Kosten). Das ganze sollte leicht einzurichten sein und wenig administrativen Aufwand haben. Schön wäre, wenn es auf Linux und Windows läuft.
Von der Performance muss es einfach möglich sein die 9 mrd Datensätze nahezu in Echtzeit zu durchsuchen. Ungefähr als wolle man in 9 mrd Emails alle mit dem Wort Hallo im Betreff finden.
Sehr wichtig ist außerdem, dass Wartungspläne ähnlich leicht eingerichtet werden können wie in MS-SQL.Nun, wie würdet ihr entscheiden, und warum? MS-SQL ist natürlich nicht raus nur weil es mir mal nach Bauchgefühl langsam vor kam.
Ich hoffe Ihr könnt für ein bisschen Klarheit sorgen
Wünsche allen dann noch ein frohes Fest und hoffe ihr denkt in eurer Freizeit nicht so viel an eure Arbeit wie ich.
So long..
wtfwpf
-
Ist es dein Ernst? Schon wieder ein CRM System, wo es doch schon dutzende davon gibt? Und ganz einfach ist das bestimmt nicht, in einem mittelmäßigen System stecken sicher hunderte Mannjahre Arbeit. Aber du bist ja anscheinend kein (kompletter) Anfänger, das müsste dir eigentlich klar sein. Also, wozu schon wieder ein CRM System entwickeln???
Oracle ist bei sowas sicher nicht schneller als der SQL Server. Die Datenbanken nehmen sich nicht viel. Es mag vielleicht schneller sein, wenn du von Systemen mit hunderten Prozessoren und tausenden Festplatten redest. Dann ist Oracle mit ASM usw. wahrscheinlich im Vorteil. Aber solche Datenmengen hast ja auch wieder nicht im Sinn. Andererseits gibts das auch für Linux im Gegensatz zum Sql Server.
MySql sollte für einfache Datenbanken auch schneller sein, als die großen. Die großen sind normalerweise nur schneller, wenn es wirklich um sehr große und komplexe Datenbanken geht, ansonsten sind die Standardfunktionen bei allen Datenbanken sehr ähnlich umgesetzt. Was Backup und Clustering angeht, kann gut sein, dass MySql da nicht ganz mithalten kann. Wenn man das kommerziell einsetzen will, muss man da übrigens auch Lizenzen kaufen.Wie schnell dann irgendwas geht, ist eine andere Frage. Eine relationale Datenbank ist nie die schnellste Variante. Jede einzelne Funktion könnte man für Spezialfälle (deutlich) schneller hinbekommen. Das Gesamtpaket aber eher nicht. Ob man 9 Mrd Emails in Echtzeit durchsuchen kann, weiß ich nicht. Ich hab in meinem Outlook Posteingang in der Arbeit 15 000 Emails und die Suchfunktion ist da nicht grad schnell, 10 Sekunden kommt denke ich gut hin. In den meisten Datenbanken kannst du für Textspalten auch einen Volltextindex anlegen. Das ist normalerweise ziemlich schnell, aber wie schnell das genau ist, kann ich so nicht sagen. Wir verwenden in der Arbeit Lucene für Millionen Datensätze (was PDM-artiges), da geht die Suche fast sofort. Der Index braucht im Arbeitsspeicher aber schon etwa 1GB für die Datenmenge. Wenn du das mit 1000 multiplizierst, wirds knapp.
Und natürlich solltest du dein System am ehesten so aufbauen, dass die Datenbank austauschbar ist. Zumindest Oracle und Sql Server, evtl. noch DB2 (wobei ich das fast schon exotisch finde, zumindest in dem Bereich). Viele Kunden haben schon eine Datenbank und evlt. auch jemanden, der sich da auskennt und sie betreut. Sie sind dann meist nicht so glücklich, wenn man denen noch eine Datenbank andrehen will.
-
Du kannst davon ausgehen dass sich relationale Datenbanken mit identischen Features von der Performance her nicht viel nehmen. Zumindest nicht wenn man sehr ausgereifte Produkte wie MS-SQL oder Oracle vergleicht. Von mir aus soll irgend ein System um Faktor 2 schneller sein als ein anderes, aber Faktor 2 macht aus 10 Sekunden 5 Sekunden - was immer noch nicht prickelnd ist.
Wo du 'was rausholen kannst, ist wenn du etwas daran änderst wie die DB organisiert ist, bzw. wie die Suchanfragen durchgeführt werden. Wenn du z.B. statt WHERE ... LIKE auf nen Table einen Lucene Index verwenden kannst, dann kann das extrem viel bringen. (Bzw. auch einen Volltext-Index der verwendeten Datenbank -- MS-SQL kann z.B. Volltext-Indexe.)
Wenn der Lookup einer einzelnen Aktivität 10 Sekunden braucht, dann läuft irgendwas schief. Das kann mMn. nur sein wenn es für die Suche keinen passenden Index gibt. (Etwas anderes ist es wenn man nicht eine Zeile als Ergebnis bekommt sondern 10.000 - dann kann so ne Suche schnell mal mehrere Sekunden dauern, auch wenn man passende Indexe hat. Alleine das Rauspicken der 10.000 Zeilen aus dem Table - vorausgesetzt es gibt keinen Covering Index - kann dann schon > 10 Sekunden dauern. Je nach Geschwindigkeit der Platten/SSDs halt.)
D.h. ich glaube nicht dass du mit einer Anderen DB viel gewinnen wirst. MS-SQL ist bei weitem nicht langsam. Wenn du 'was beschleunigen willst, dann musst du erstmal wissen warum es so langsam ist wie es ist, und dann gezielt etwas dagegen unternehmen. Das kann heissen auf eine andere DB umzusteigen (z.B. weil die aktuelle irgendwelche Features die man bräuchte nicht kann). Kann man aber erst sagen wenn man den Grund kennt. Und oft genug ist die Lösung nicht ne andere DB zu verwenden, sondern das bestehende System richtig einzusetzen.
-
@Mechanics
9 Mrd. Emails durchsuchen sollte mMn. mit vertretbarem Aufwand auf ner halbwegs "normalen" Hardware möglich sein. WENN man die geeigneten Tools verwendet. Lucene oder was auch immer. Wobei ich 9 Mrd. Emails bei ~~100 Benutzern seltsam finde. Das wären 90 Mio. Mails pro Benutzer. ... WTF?Aber unabhängig davon. Aus einem Index über 9 Mrd. Irgendwasse ein Irgendwas rauszupicken sollte noch gehen. Problematisch wird es nach meiner Erfahrung meist erst dann, wenn man zu viele Irgendwasse aus dem Index rauspickt und dann noch die dazugehörigen Zeilen aus dem Table laden möchte. Oder wenn die Suchkriterien derart sind, dass man sie nicht mit einem einzigen Index erschlagen kann. Wobei Lucene bei letzterem auch recht gut ist, aber halt auch nicht zaubern kann.
Mechanics schrieb:
Wenn man das kommerziell einsetzen will, muss man da übrigens auch Lizenzen kaufen.
Soweit ich weiss muss man nur aufpassen dass das eigene Produkt MySQL nicht benötigt (=auch ohne oder mit einer anderen DB funktioniert), und man MySQL nicht mit ausliefert.
-
Ich glaube, das mit den Emails war nur ein Beispiel zum Vergleich vom TE. Aber ich habs geschrieben, weil ich mit dem Vergleich eben nichts anfangen kann. Ich kenne kein System, wo ich 9 Mrd Mails schnell durchsuchen könnte. Ich kenne eben nur Outlook mit Exchange, und da dauert schon das Durchsuchen weniger tausend Emails zig Sekunden.
Ansonsten sind Mrd irgendwas schon eine halbwegs realistische Größenordnung bei einem CRM. Ich weiß nur nicht, ob das dann Objekte sind, die man Durchsuchen will. Wenn eine Aktivität z.B. eine Werbeaktion ist, die an 10% der Kunden ging, dann hat man nicht 25 000 Objekte, sondern 1, und 25 000 Verknüpfungen. Wie dann die Suche implementiert ist, ist eine andere Frage. Und die 25 000 Adressen muss man wahrscheinlich auch nicht holen, sondern vielleicht die ersten 100.
Ich glaub, bei CRM Systemen gibts andere Operationen, die länger als das Suchen dauern. z.B. Löschen war bei paar Systemen, mit denen ich gearbeitet habe, echt langsam.
-
Warum wieder CRM? Naja, weil der Kunde eins beauftragt hat.
Es ist zwar ein kundenspezifisches Projekt, allerdings wird es danach (hoffentlich) an weitere Kunden vertrieben.Geplante Entwicklungszeit ist ein Jahr mit einem Im Kern 8 Personen starken Team und 16 Entwicklern, die bei Engpässen aushelfen, eigentlich aber andere Projekte bearbeiten.
So wie die Spezifikation aussieht, würde ich gefühlt sagen, ein Entwickler könnte die in einem Jahr auch umsetzen. Da fehlt mir aber sicherlich auch noch die Erfahrung das richtig einzuschätzen.
Dem Auftraggeber ist die Datenbank erstmal egal. Wichtig ist nur, dass es wirklich flott geht. Das System, was der Kunde bisher einsetzt ist Extrem langsam. Die aktuelle Kunden-DB ist 4TB groß. Vorhanden ist Dort eine Windows Server Architektur.
Beauftragt bin ich nun, DBMS möglichkeiten zu evaluieren. Know how hat unsere Firma bisher nur in MS-Sql. Allerdings auch eher in kleinen Datenbanken um die 20 GB größe.
Der Projektleiter würde gerne auf eine Datenbank setzen, und dafür dann lieber die Features richtig ausnutzen.
In der damaligen Firma bin ich nicht mehr tätig und kann da nichts mehr Optimieren. Weiß nur noch von dort, dass die Suchen immer recht lange gedauert haben. Die Tabelle mit den Aktivitäten hatte dort ca 30 spalten und das Ergebnis einer Suchen waren meist zwischen 80 und 250 Ergebnisse.
Leider muss ich sagen, dass ich kein Muster-Student war und mir viel Know how fehlt. Deshalb muss ich jetzt in viele Arbeiten die ich mache extrem viel Zeit rein stecken und viel von Zuhause in der Freizeit machen, was anders wäre, wenn ich damals richtig aufgepasst hätte.
PS:
Sind keine 9 mrd Mails. Sind ca 50k Mails pro Benutzer. In dem alten System wurde das nicht unterschieden. Da waren auch Rechnungen drin, die durch eine SAP Schnittstelle erstellt wurden, da waren Telefonate drin, die eine TAPI-Schnittstelle automatisch rein gepumpt hat, alle Geschäftsbriefe, alle Termine, normale Notizen, alle Emails die Marketing rausgeschickt hat, Todos die entstanden wenn der Empfänger die Mail gelesen hat, wenn er einen Link in der Mail geklickt hat etc.
Hat Marketing ein Mailing an 100.000 Adressen verschickt hat das für 300.000 Einträge in der DB gesorgt. Alleine Akquiseaufgaben für Seller entstanden jeden Tag ca 2000 Stück, von denen nur 250 am ende benötigt wurde. Aber alles ist in der DB geblieben.Das System was wir jetzt bauen wird sehr ähnlich funktionieren. Also genau so viel Daten produzieren. Finde ich auch nicht ungewöhnlich für ein CRM. Wenn wir Datenübernahmen gemacht haben, waren die Datenbanken immer ähnlich groß.
PS2: Löschen war in dem System was ich betreut habe auch extrem langsam. Aber ein CRM soll ja nicht löschen.
PS3:
Wenn eine Aktivität z.B. eine Werbeaktion ist, die an 10% der Kunden ging, dann hat man nicht 25 000 Objekte, sondern 1, und 25 000 Verknüpfungen
Doch das werden 25000 Objekte. Jede Email wird ja anhand der Kundeninfo personalisiert rausgeschickt. Da kann man die nicht einfach verknüpfen.
-
wtfwpf schrieb:
Doch das werden 25000 Objekte. Jede Email wird ja anhand der Kundeninfo personalisiert rausgeschickt. Da kann man die nicht einfach verknüpfen.
Natürlich kann man das Verknüpfen. Dafür gibts Serienbriefe. Ich bin mir sicher, dass schlaue CRM Systeme das genauso machen. Ich bin mir jetzt nicht mehr 100% sicher (ist schon Jahre her), aber ich glaub, das CRM System mit dem wir hauptsächlich gearbeitet haben hat das auch so gemacht.
wtfwpf schrieb:
Geplante Entwicklungszeit ist ein Jahr mit einem Im Kern 8 Personen starken Team und 16 Entwicklern, die bei Engpässen aushelfen, eigentlich aber andere Projekte bearbeiten.
So wie die Spezifikation aussieht, würde ich gefühlt sagen, ein Entwickler könnte die in einem Jahr auch umsetzen. Da fehlt mir aber sicherlich auch noch die Erfahrung das richtig einzuschätzen.
Aber du bist auch nicht der, der das geschätzt hat? Da ihr zumindest ein so großes Team habt, hoffe ich doch, dass jemand bei euch auch in der Lage ist, das richtig einzuschätzen. Wenn ihr das alles im Detail versteht, könnte das machbar sein. Wobei ich persönlich da sehr skeptisch wäre. Zum einen, was den Umfang angeht (ich weiß nicht, ob ihr wirklich ein "richtiges" komplettes CRM schreiben wollt, aber wenn, dann gibts da oft sehr sehr viele Sachen, die man berücksichtigen muss). Zum anderen, ist ein Jahr schon sehr knapp, auch wenn mehrere Leute dran arbeiten. Vor allem kann man solche Projekte in der Anfangsphase schlecht parallel entwickeln. Da müsste das jemand schon bis ins letzte Detail geplant haben, halte ich für zumindest unwahrscheinlich.
Nur zum Vergleich, wir sind etwa 30 Entwickler in der Arbeit (+ x Leute QA) und wir machen auch ungefähr ein Release pro Jahr. Und wir entwickeln nicht jedesmal ein komplett neues System from Scratch, wir arbeiten alle an unserem System, das schon alle Entwickler kennen. Der Umfang der Änderungen ist wahrscheinlich überschaubarer als bei euch und auf jeden Fall viel besser einschätzbar, und trotzdem ist es jedesmal sehr knapp.
-
Natürlich kann man das Verknüpfen. Dafür gibts Serienbriefe.
Es gab halt Platzhalter die ersetzt wurde. Verknüpfen wäre sicher auch gegangen. Aber es wäre nicht so leicht gewesen, da man den Brief / die Mail vor ersetzen der Platzhalter hätte speichern müssen, und dann jedes Mal beim suchen hätte ersetzen müssen. Aber auch das bringt Probleme. Ändert ein Kontakt die Firmierung stimmen die Daten nicht mehr. Das es so gemacht wurde, wurde jedenfalls auch entschieden, da hab ich noch nicht an Computer gedacht.
Aber du bist auch nicht der, der das geschätzt hat?
Gott bewahre. Das ganze Projekt wurde in Arbeitspakete aufgeteilt, diese wurden dann an alle 24 C# Entwickler gegeben und diese haben für jedes Paket eine Schätzung abgegeben. Im Anschluss sind die Pakete an das Java Team gegangen (ich glaube noch mal ca.15 Entwickler), die nochmal geschätzt haben wie lange sie brauchen würden wenn sie das in C# machen müssten (Damit man auch nen pessimistischen Anteil hat). Daraus hat die Projektleitung dann iwie einen Mittelwert gebildet und dann so viele Entwickler drauf gesetzt, dass es in ein Jahr passt.
QA ist bei uns auch extra. Aber wir haben nur 3 Leute für QA und die müssen auch noch die anderen Projekte Testen. Das ist natürlich kritisch. Aber da drüber kann ich mir nicht auch noch den Kopf zerbrechen ^^Ende der zweiten Januar-Woche ist die Iteration zu ende und ich muss meine Ergebnisse vorstellen. Im Moment würde ich sagen, ich empfehle MS-Sql, weil wir da Leute haben die sich auskennen und wir uns nicht noch in ein neues DBMS einarbeiten müssen. Da der Fokus aber ganz klar auf dem Performance/Preis verhälltnis liegt, wüsste ich nicht, wie ich MS-Sql begründen soll im Vergleich zu Oracle oder MaxDB oder so.
-
Käme bei einem CRM nicht auch eine NOSQL-Datenbank in Frage, wie z.B. MongoDB: CRMs and Business Process Applications on MongoDB?
-
Klar kommt auch NoSQL in Frage. Habe ich NoSQL mit DB2 nicht schon im Spiel?
Zukunftssichere Vielseitigkeit mit NoSQL Graph Store und Datenbanksynchronisation und Support für IBM Mobile
Oder habe ich das hier falsch verstanden?
Ist MongoDB als Enterprise System nutzbar? Gibt es da Erfahrungen? Wie sieht es da aus mit Backup-Möglichkeiten?
MongoDB ist mir bisher nicht als klassischer Big-Player im Kopf. Auch mit Googlen habe ich jetzt erstmal auf Anhieb keine Enterprise-Anwendung finden können. Andererseits wird sie in deinem Link ja explizit als gut geeignet für CRM genannt.
-
Nein, DB2 ist ein klassisches Uralt-RDBMS. Die wollen nur auch ein grünes Häkchen in der Feature-Liste neben "NoSQL" haben.
MongoDB finde ich nicht allzu prickelnd:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/wtfwpf schrieb:
Im Moment würde ich sagen, ich empfehle MS-Sql, weil wir da Leute haben die sich auskennen und wir uns nicht noch in ein neues DBMS einarbeiten müssen.
Klingt doch nach einem sehr guten Argument. Abgesehen davon ist der MS SQL-Server auch mit C# und der restlichen Microsoft-Toolchain sehr bequem zu verwenden.
Ich persönlich bin großer Postgres-Fan für sehr viele Anwendungsfälle, aber in deinem Fall klingt der SQL-Server doch ziemlich passend. Hast du irgendwo besondere Bedenken?
Ich verstehe das Performance/Preis-Argument wohl nicht ganz; Oracle ist sehr sehr sehr teuer und die Preise von MaxDB werden auch nicht ganz ohne sein. Zudem ist mir letzteres auch nicht gerade als Speed demon bekannt.
-
Ich würde auch zum Sql Server tendieren. Bzw., ich würd versuchen das möglichst datenbankunabhängig zu machen, aber mit dem Sql Server anfangen. Oracle und DB2 sind wohl kaum billiger als der Sql Server.
Bei einem CRM seh ich den Vorteil von einem NoSql System jetzt nicht. Jedenfalls würde ich damit jetzt nicht anfangen, das ist etwas, wo man sich erst einarbeiten und das ganze evaluieren muss und das ist für so eine "Spielerei" nicht zielführend, wenn man so wenig Zeit hat.Habt ihr schon Erfahrung mit Projekten solcher Größenordnung? Ich kann mir schlecht vorstellen, dass das Aufteilen in Arbeitspakete bei neuen Projekten auf die Weise funktioniert. Es gibt eine Kernfunktionalität und es gibt viel, was darauf aufbaut. Bis die Kernfunktionalität steht, werden viele erstmal warten müssen. Oder irgendwas mit Schnittstellen und Mockups schreiben, was sie dann wieder umbauen werden müssen, wenn die anderen fertig sind. Und dann wird man feststellen, dass vieles so wie man das gedacht hat, nicht funktioniert, weils z.B. eben zu langsam ist.
-
Habe jetzt nur den ersten Artikel gelesen. Finde den hervorragend geschrieben. Der Artikel ist echt fesselnd. Frage mich allerdings wie das Wort "Zeitgeist" in diesen Artikel gekommen ist.
Jedenfalls finde ich die Begründung absolut einleuchtend. Sehe die Problematik schon wenn ich nur Grob über das Schema nachdenke. Ein CRM besteht ja quasi aus Verknüpfungen.Klingt doch nach einem sehr guten Argument. Abgesehen davon ist der MS SQL-Server auch mit C# und der restlichen Microsoft-Toolchain sehr bequem zu verwenden.
Klar. Hinzu kommt, dass sowohl wir, als auch der Kunde bereits Lizenzen für die Enterprise-Version haben.
Ich persönlich bin großer Postgres-Fan für sehr viele Anwendungsfälle, aber in deinem Fall klingt der SQL-Server doch ziemlich passend. Hast du irgendwo besondere Bedenken?
Auch in dem Artikel ist ja Postgre SQL genannt. Was macht Postgre SQL denn für dich so vorteilhaft?
Habe bei MS-Sql bloß bedenken weil ich mal gesehen habe wie lange es gedauert hat, die 9 mrd Einträge zu durchsuchen.Alles in allem scheint das Thema der richtigen Datenbank komplexer als ich dachte. Gefühlt würde ich sagen, dass das Thema der Performance noch garnicht an der Reihe ist, da noch viel zu viele Informationen fehlen. Es kommt mir fast so vor, als könne man die Zeit der Recherche besser in das Evaluieren von Anforderungen und die Userbehaviour Analyse stecken als in DBMS.
Ich verstehe das Performance/Preis-Argument wohl nicht ganz
Naja, wir möchten natürlich viele Kunden erreichen. Heißt, für Kleinkunden wäre es schön, wenn die DB kostenfrei wäre und unter Linux läuft. Wenn der Kunde für die Software zahlt und dann noch 10.000€ investieren muss um Windows Server / SQL Server 2014 Lizenzen + einen Admin der das einrichtet zu erhalten ist das ein Grund Abstand zu nehmen. Wenn der Kunde aber weiß, das ganze geht mit Debian und einer anderen DB Kostenfrei so das er "nur" den Admin zum aufsetzen benötigt, lässt er sich vermutlich eher auf einen Kauf ein.
Mittelständigen ist das weniger wichtig. Dort sind die 10k€ für auch noch über wenn man die Software kauft. Mal abgesehen davon dass vermutlich eh schon ein Admin im unternehmen ist.
Bei Großkunden ist dann auch noch mehr als die 10k€ über. Allerdings ist wichtig, dass das System auch noch mit 50mrd Datensätzen in akzeptabler Zeit umgehen kann.
Optimal wäre also eine DB die Staffel-Lizenzen hat. Sagen wir mal 500€ für Kleinstkunden, 5k€ für Medium-Enterprise Ansprüche und 50k€ für Real-Enterprise Ansprüche.
Das ist, was ich mit Performance/Preis Verhältnis meine.Habt ihr schon Erfahrung mit Projekten solcher Größenordnung?
Kann ich schwer sagen. Bin selbst noch nicht lange da. Seit ich da bin haben wir eher an kleinen Projekten gearbeitet (so 20 Manntage). Aber soll Mitte letzen Jahres auch ein Projekt gegeben haben, bei dem alle 24 C#-Entwickler 7 Monate an einem Projekt gearbeitet haben, was hätte 6 Monate dauern sollen. Also ganz unerfahren scheint die Projektleitung nicht zu sein.
Es wird so funktionieren, dass es ein Kernstück gibt was AddIns läd. z.B. ein Adressen-AddIn. Dieses wird sich um fast alles was es benötigt selbst kümmern.
Dann wird es ein ToDo AddIn geben, dies Benötigt quasi nur Adressen. Heißt es kann ohne das Adressen-AddIn nicht arbeiten, da es keine Adressen anfragen kann.
Insgesamt wird es 6 AddIns geben die den Kern abbilden, die immer da sein müssen und standardmäßig ausgeliefert werden.
Ist jetzt etwas vereinfacht ausgedrückt. Aber im Prinzip gewährleistet dieses Vorgehen, dass alle 7 Teile parallel entwickelt werden können sobald die Schnittstellendefinition steht.
Ob das Konzept aufgeht kann ich nicht sagen. Für mich ist das alles recht neu, da ich nur Kleinprojekte und Wartung eines Großprojektes kenne.
-
wtfwpf schrieb:
Alles in allem scheint das Thema der richtigen Datenbank komplexer als ich dachte.
Nicht nur das, wahrscheinlich werden noch sehr viele ähnlicher Fragen aufkommen.
Naja, halt uns mal auf dem Laufenden!
-
wtfwpf schrieb:
Auch in dem Artikel ist ja Postgre SQL genannt. Was macht Postgre SQL denn für dich so vorteilhaft?
Kurz: Der Slogan "The world's most advanced open source database" stimmt, die Codequalität und Doku sind sehr sehr gut und Postgres ist extrem zuverlässig.
Habe bei MS-Sql bloß bedenken weil ich mal gesehen habe wie lange es gedauert hat, die 9 mrd Einträge zu durchsuchen.
Und warum glaubst du, dass ein anderes RDBMS beim selben Schema, den selben Daten und der selben Anfrage bei Größenordnungen von 9 Mrd. Records signifikant schneller wäre?
Bei Großkunden ist dann auch noch mehr als die 10k€ über. Allerdings ist wichtig, dass das System auch noch mit 50mrd Datensätzen in akzeptabler Zeit umgehen kann.
Glaube ich nicht. Großkunden haben dann eben eine Instanz pro Tochterfirma oder Niederlassung oder …
Optimal wäre also eine DB die Staffel-Lizenzen hat. Sagen wir mal 500€ für Kleinstkunden, 5k€ für Medium-Enterprise Ansprüche und 50k€ für Real-Enterprise Ansprüche.
Dann nehmt eben SQLite für Kleinkunden und SQL Server für alles größere.
-
Und warum glaubst du, dass ein anderes RDBMS beim selben Schema, den selben Daten und der selben Anfrage bei Größenordnungen von 9 Mrd. Records signifikant schneller wäre?
Naja, weil es vielleicht einfach besser ist. Möglicherweise gehen andere DBMS anders mit Daten um, sind anders organisiert, oder oder oder. Würde ich ein DBMS entwickeln, und da wären 9 mrd Einträge drin, würde es sich wohl dumm und dusselig suchen, einfach weil ich keine Ahnung von Optimierung habe.
Denke mal ich werde MS-Sql vorschlagen. Der vorteil ist einfach, dass sich die Mitarbeiter gut damit auskennen. Wenn die DBMS sich nicht viel nehmen, und Oracle vllt 5% schnelle wäre, dann braucht man auch einen der sich gut genug auskennt um die 5% rauszuholen. Und da sich keiner auskennt, ist die Wahrscheinlichkeit größer das man es langsamer baut. Bis wir da das know how haben, haben wir die hälfte vermutlich vermurkst. Und aufrüsten müssten wir auch noch. Wo wir doch schon mehr VMs laufen haben als Mitarbeiter im Unternehmen sind.
-
Auch Enterprise-Software-Hersteller kochen nur mit Wasser. Manche auch mit lauwarmem und großer Marketing-Abteilung.
wtfwpf schrieb:
Denke mal ich werde MS-Sql vorschlagen. Der vorteil ist einfach, dass sich die Mitarbeiter gut damit auskennen.
Gute Idee.
Wo wir doch schon mehr VMs laufen haben als Mitarbeiter im Unternehmen sind.
Das ist nicht allzu ungewöhnlich.
-
wtfwpf schrieb:
Und warum glaubst du, dass ein anderes RDBMS beim selben Schema, den selben Daten und der selben Anfrage bei Größenordnungen von 9 Mrd. Records signifikant schneller wäre?
Naja, weil es vielleicht einfach besser ist. Möglicherweise gehen andere DBMS anders mit Daten um, sind anders organisiert, oder oder oder. Würde ich ein DBMS entwickeln, und da wären 9 mrd Einträge drin, würde es sich wohl dumm und dusselig suchen, einfach weil ich keine Ahnung von Optimierung habe.
Datenbanken können nicht zaubern. Gibt aber dennoch genügend Entwickler die glauben das wäre doch so. Bzw. die so arbeiten als wäre es so. Wenn die dann die DB entwerfen und die Applikation dazu entwickeln, dann kann man froh sein wenn die Suche nur 10 Sekunden dauert - egal mit welcher Datenbank. Wenn die Entwickler aber wissen "wie man es richtig macht", dann wird eine schnelle Suchfunktion auch kein unerreichbares Ziel sein. Wiederrum egal mit welcher Datenbank. Notfalls muss man eben andere Tools ala Lucene dranknoten.
wtfwpf schrieb:
Denke mal ich werde MS-Sql vorschlagen.
Würde ich an deiner Stelle vermutlich auch.
-
[quote="hustbaer"]
wtfwpf schrieb:
Datenbanken können nicht zaubern.
Da ist mir grad eine Software eingefallen, über die es mal eine Kurznotiz in der c´t gab. Die wird als Datenbanktreiber angesprochen und fungiert als Proxy zur richtigen Datenbank. Dabei führt sie Statistiken über die Anfragen und kann sie mit der Zeit optimieren. Da stand was von bis zu Faktor 1000. Das Teil war glaub ich sauteuer.
Wohl auch so ein Tool, um ganz schlecht programmierte Datenbankanwendungen nachträglich zu verbessern. Wobei ich mir auch nicht so ganz vorstellen kann, wie das funktioniert. Der Proxy müsste zumindest zusätzliche Indexe anlegen können, und ob er das kann/darf ging da nicht so wirklich hervor.
-
Ich stimme nman voll und ganz zu. PostgreSQL ist grossartig. Es ist einfach in jeder Hinsicht besser als MySQL. Es ist kostenlos und auf allen relevanten Plattformen verfügbar.
Sqlite ist für kleine Sachen auch sehr gut geeignet. Es ist halt sehr einfach zu administrieren.
Wenn beim Kunden MS-SQL im Einsatz ist, ist das allerdings das Killerargument. Keine andere Datenbank ist so viel besser oder schneller als MS-SQL, dass sich ein Umstieg wirklich lohnen würde.
Ansonsten: immer schön Datenbankneutral programmieren. Dann kann man die Datenbank später zur Not auch austauschen.
-
tntnet schrieb:
Ansonsten: immer schön Datenbankneutral programmieren. Dann kann man die Datenbank später zur Not auch austauschen.
Ich glaube dazu muss man mindestens Tests (Unit-Tests, Integrationstests, ...) mit einer zweiten DB machen. Sonst stehen die Chancen wohl sehr schlecht dass man später noch einfach umsteigen kann.
(OK, ein Tool das alle SQL Statements prüft und meldet sobald ein non-Standard Feature verwendet wird würde vermutlich auch reichen - weiss nicht ob es so etwas gibt.)
