DB für CRM
-
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.)
-
Es muss ja nicht mal komplett datenbankneutral sein. Ich hätte oftmals auch keine Lust, auf datenbankspezifische Features zu verzichten. Aber man braucht eine Zwischenschicht für die Datenbankzugriffe. Dann kanns von mir aus eine Implementierung für den MS-SQL, für Orace und für PostgreSql geben. In der jeweiligen Schicht kann man dann auch spezielle Features benutzen, um die Performance usw. zu verbessern.
-
Ich verstehe das Problem nicht so ganz. Ich kenne SQL und weiss, was ich damit machen kann. Und meine SQL-Abfragen sind praktisch immer Datenbankneutral.
Welche Features nutzt ihr denn, welches sich mit Standard-SQL nicht abbilden lässt?
Mag sein, dass man mit speziellen Features noch mal ein wenig Performance raus holen kann, aber in der Regel ist das nicht so viel, dass es relevant wäre.
Die Datentypen sind in den Datenbanken unterschiedlich. Da hat man dann verschiedene DDLs für die einzelnen Datenbanken, aber der Applikation selbst sollte das nichts ausmachen.
-
Ich hab grad kein konkretes Beispiel. Geht auch nicht unbedingt um einfache Queries. Aber z.B. so Sachen wie Volltextsuche, temporäre Tabellen, hierarchische Daten vom Sql Server usw. Dann vielleicht ein bisschen Logik in Triggern und Stored Procedures implementieren. Kann sich durchaus lohnen.
-
tntnet schrieb:
Welche Features nutzt ihr denn, welches sich mit Standard-SQL nicht abbilden lässt?
* Clustered Indexes sind soweit ich weiss nicht Standard SQL
* Filtered Indexes ebenso
* Rekursive Common Table Expressions sind zwar IIRC Standard, werden aber nicht von allen DBs unterstützt
* Join Hints
* Optimizer Hints (Angabe von Indexen die verwendet werden sollen, "FAST TOP 1" etc.)
"WITH (NOEXPAND)" ist IIRC z.B. nicht Standard, auf MS-SQL Standard-Edition aber nötig wenn man möchte dass der Optimizer Indexe von Indexed-Views verwendet (die Enterprise-Edition hat das Optimizer-Feature "automatisch gucken ob es einen verwendbaren Indexed-View Index gibt" im Gegensatz zur Standard-Edition dann nicht gesperrt, wodurch die Notwendigkeit für "WITH (NOEXPAND)" dort dann wegfällt).
* XML Spalten (mit XML Indexen, XPath Queries etc.)
* Unterschiedliche Syntax die nötig ist wenn man performant aus einem Batch heraus viele Zeilen auf einmal einfügen will
* Unterstützte Parametertypen bei parametrisierten Prepared Statements (z.B. gibt es AFAIK DBs die Arrays unterstützen ala "WHERE x IN @param")Das sind so die Dinge die mir spontan einfallen. Einige davon mögen standardisiert sein, so genau kenne ich den Standard dann auch nicht. Einige davon sind es sicher nicht. Nützlich können sie in den verschiedensten Situationen alle sein.
Bei den etwas "spezielleren" Datentypen bzw. auch Funktionen gibt es auch immer wieder Dinge die auf verschiedenen DBs unterschiedlich funktionieren. Und da muss man nichtmal exotisch werden, ISNULL/COALESCE (T-SQL) vs. NVL (Oracle) vs. ISNULL (MySql - heisst gleich, tut aber anders als T-SQL ISNULL). Oder T-SQL's CONVERT.
-
@Mechanics
Klar muss es nicht der selbe Code sein. Ich wollte damit nur sagen: Wenn man seine Applikation "neutral" halten will, oder auch nur die 2-3 wichtigsten DBs unterstützen will, dann muss man die auch von Anfang an alle testen. Oder spätestens zu dem Zeitpunkt wo man ein 2. System unterstützen muss, eine Testbatterie aufbauen, mit der man möglichst 100% "SQL Coverage" hat. Weil man sonst nie sichergehen kann dass auch wirklich alle SQL Statements die in der Applikation vorkommen auch auf allen DBs laufen.Zumindest wenn man Entwickler hat die mehr als Standard SQL können, und z.T. gar nicht wissen was alles non-Standard Erweiterungen "ihres" Systems sind. Bzw. was alles Standard SQL Syntax ist die aber von alternativen Systemen unter Umständen nicht gefressen wird. Und wenn SQL - wie ich vermute - oft "on the job" gelernt wird, dann wird es sehr viele solche Entwickler geben. Denn was schert es mich, wenn ich Feature A mit SQL-DB X implementieren muss, was SQL-DB Y oder Z dazu sagen.
Wenn dagegen für jedes SQL Statement das ich schreibe ein Test geschrieben wird, weil es das Feature sonst nicht durchs Review schafft, dann schert es mich. Und dann kann man die Applikation auch mehr oder weniger "DB-neutral" halten.
Bzw. wenn trotz Test-Case erstmal nur eine DB supported werden muss, dann kann man später relativ problemlos Support für weitere DBs dazubasteln. Weil man einfach nur gucken muss dass alle Tests fehlerfrei durchlaufen. Die paar Bugs die dann trotzdem noch übrig bleiben, weil halt keine Testbatterie wirklich alle denkbaren Fälle abdecken wird, kann man dann in Revisions/Hotfixes beheben. Wenn es dagegen keine solche Testbatterie gibt, dann müsste man alles mit Hand testen. Und zu dem Zeitpunkt wo das 2. DB System dazukommt kann die Software leicht schon so gross sein, dass das ... ziemlich aufwendig würde.
