C/Side vs SQl Server

Hallo,

gibt es irgentwo eine Zusammenstellung welche vor und Nachteile die beiden Datenbanken haben.
Es handelt sich um ca 100GB DB und 120 User.
Vielleicht hat ja jemand mal eine Zusammenstellung von euch.

Hi!

Nun, ob es eine offizielle Gegenüberstellung gibt, weiß ich nicht.
Hier nur ein paar Aspekte:

Native Datenbank (C/SIDE):

- Proprietäre Blackbox
- Strategisch "tot"
- Technologisch veraltet
+ Geringe Hardware Anforderungen
+ Source Code (C/AL) wurde für C/SIDE entwickelt
+ Gute Perfromance bei kleinen DB (<= 50GB)
- Hohes Sperrpotential
+ billig

SQL Server:

+++ High End Datenbankumgebung
+++ Fantastillionen Features
+ DB der Microsoft-Zukunft
- Hohe Hardwareanforderungen
- Übersetzungsproblem C/AL nach SQL
- Schlechte Performance "out of the box", Tuning erforderlich, dann:
++ high Performance!
- teuer (je nach dem)

Vielleicht mag der eine oder andere ein paar Punkte ergänzen ...

Aber in eurem konkreten Fall (100GB und 120 User): SQL Server ist die richtige Wahl!
Unter C/SIDE gibt es kein vernünftiges Backup, um 100GB zu sichern und zu restoren benötigt man mehr als 24 Stunden; man muss auf Drittanbieterlösungen zurückgreifen (z.B. Snapshots via Storagesystem).
Da C/SIDE nur Tabellensperren kennt, werden sich 120 Concurrent-User mit Sicherheit gegenseitig ständig blockieren.

Aber wie gesagt: mit SQL Server funktionierts nur dann richtig, wenn man das System A) richtig dimensioniert und B) konfiguriert und optimiert.

Hi,

also bei bei 120 Usern seh ich den SQL-Server auch klar vorn, allerdings finde ich das der Native Server in stryks Liste etwas zu schlecht abschneidet.

Zum Thema "Strategisch tot": Das wurde schon Jahren behauptet und langfristig ist das sicher so, aber da man selbst in Nav 5.1 den Native Server noch verwenden kann - sollte man ihn nicht zu schnell beerdigen.

"Technologisch veraltet" - Das trifft wenn du so willst für das ganze Navision zu. Das nur auf den Native Server zu beziehen wäre etwas unfair. Ich meine die Entwicklungsumgebung bietet keine modernen Tools und die Sprache erlaubt kein OOP, kein SQL usw.

Der Vorteil des Native Servers ist meiner Meinung nach, das er absolut wartungsarm ist. Für kleine Projekte (also nicht für deins) ist das ein enormer Vorteil.

Grüße Steffen

aber da man selbst in Nav 5.1 den Native Server noch verwenden kann - sollte man ihn nicht zu schnell beerdigen.

Wo steht das? Ich dachte immer:
5.0 -> Übergang, man benutzt beides
5.1 -> Kennt nur noch Server

Moin zusammen,

da muss ich Natalie zustimmen, die 5.1 wird meinem Kenntnisstand nach keine Native-Datenbank mehr unterstützen.

Gruß, Marc

Doch wird 5.1 wird den Navtive Server untertsützen. Allerdings nicht mit dem rollenbasierten Client.

Diese Information ist aus dem Webcast von der Convergence 2007:
http://www.mibuso.com/dlinfo.asp?FileID=874

"Technologisch veraltet" - Das trifft wenn du so willst für das ganze Navision zu. Das nur auf den Native Server zu beziehen wäre etwas unfair. Ich meine die Entwicklungsumgebung bietet keine modernen Tools und die Sprache erlaubt kein OOP, kein SQL usw.

Also, das würde ich jetzt mal nicht als Nachteil werten. Für Kunden ist die Entwicklungsumgebung absolut klasse. Einfach zu bedienen. Eine überschaubare Anzahl von Objekttypen.

Da stimme ich mit MS überein, die in der Development I Schulungsunterlage schreiben:

It is actually somewhat difficult to create a severe bug in C/SIDE and this is good for everyone.

Ich sage immer so pauschal: zum Glück wurde NAV nicht von Anfang an von MS programmiert, sonst wäre es für Kunden sicherlich nicht so einfach Anpassungen selbst vorzunehmen. Und wenn man den SQL-Server einsetzt, muss man sicherlich genauer wissen, was man da im Code tut. Denn der Native-Server ist eigentlich immer performant, egal wie schlecht der Code geschrieben ist. Beim SQL-Server muss man sein Augenmerk vielmehr auf Schlüssel und korrekten, auf SQL-optimierten Code legen.

Hier nochmal eine kurze Gegenüberstellung von SQL-Server und Native-Server:

SQL
- SIFT: in Tabellen abgebildet
+ Locking: Record Level Locking
+ DaSi: Serverbasierend
+ Hochverf.: Cluster / Log-Shipping / Database Mirror
- Concurrency: Locks + Isolation Level

Native
+ SIFT: integriert
- Locking: Table Locking
- DaSi: Clientbasiert / HotCopy
- Hochverf.: Nein
+ Concurrency: Versionsprinzip + Optimistic Concurrency

Ansonsten ist noch zu sagen, dass eine Native-DB erstmal auf 128GB beschränkt ist. Das kann man dann zwar von MS erweitern lassen, aber ist halt immer mit Aufwand verbunden.

Zur Hochverfügbarkeit will ich noch anmerken, dass es von MS eine Möglichkeit gibt, zwei Native-Server parallel laufen zu lassen und gewissermaßen ein Failover-Cluster einzurichten. Die Kunden, die das von MS zur Verfügung gestellt bekommen haben, lassen sich allerdings an einer Hand abzählen.

Gruß
Tim

Hi Tim,

ich habe ja gesagt, das "technologisch veraltet" nicht unbedingt als Minus angeführt werden sollte. Bei der Entwicklungsumgebung bin ich jedoch anderer Meinung. Was für den Kunden schön einfach ist, nervt jedoch wenn du ein großes Branchenmodul entwickeln/debuggen willst.

Grüße Steffen

forki hat definitiv recht.

Unter 5.1 wird es immer noch einen C/Side-Client geben und auch eine C/Side-DB.

Nur wer den neuen rollenbasierten Client einsetzen will, muß zwangsläufig auf SQL umsteigen. Ich meine auch, dass dann zwingend SQL 2005 verwendet werden muß, lass mich ab aber gerne belehren.

Hey, danke für die Info!

Gruß, Marc

Was für den Kunden schön einfach ist, nervt jedoch wenn du ein großes Branchenmodul entwickeln/debuggen willst.

Also ich habe schon 10 Jahre vor Navision programmiert. Und damit meine ich jetzt wirklich programmiert. Also C++ (auch OO), PHP (auch OO) und so weiter. Man kann ja die C/SIDE-Entwicklungsumbegung kaum als Programmierumgebung bezeichnen, so einfach wie das ganze zu bedienen ist. Und obwohl es so einfach gestaltet ist, kann ich nur sagen: auch bei großen Branchenlösungen bin ich noch nie an die Grenzen gestoßen. Das einzige was ich mir wünschen würde, wäre eine Erweiterung der Record-Referenzen, um Programmierungen dynamischer zu machen, aber letztendlich lässt sich doch (wie in jeder Programmiersprache) jedes Problem mit ner Schleife, ner Bedingung und ner Anweisung lösen.

Gruß
Tim

Hi Tim,

ich könnte noch ewig darüber diskutieren und würde gern auch andere Meinungen hören, allerdings will ich keinen Flame und das ist hier wohl sowieso der falsche Thread.

Grüße Steffen

SQL
- Concurrency: Locks + Isolation Level

Native
+ Concurrency: Versionsprinzip + Optimistic Concurrency

Nun, das sehe ich aber ganz anders: Es ist einer der HAUPTVORTEILE von SQL Server, daß hier ein differenziertes, (e)skalierbares Modell von Sperren zugrunde liegt. "Optimistic Concurrency" betrifft nur Verarbeitungen einzelnen Datensätze, bei Verwendung von Resultsets benötigt man höhere "Ebenen". Nativ kennt hier nur Tabellensperren und verursacht damit ERHEBLICH viele Blockadeprobleme!
SQL Server geht hier schon wesentlich schlauer mit Sperren etc. um ...

Was das Thema "Technologisch veraltet" angeht, so stimme ich dem zu, daß man dies auf ganz C/SIDE beziehen kann (vergleicht man andere IDE wie "Visual Studio" etc.), aber vor allem die Server-Technologie ist ein Fossil: DBMS Cache <= 1GB, max. 1 CPU, 32bit ... das war vor 10 Jahren aktuell, heute setzt man andere Maßstäbe an.

Nun, das sehe ich aber ganz anders: Es ist einer der HAUPTVORTEILE von SQL Server, daß hier ein differenziertes, (e)skalierbares Modell von Sperren zugrunde liegt.

Ich stimme dir voll zu, wenn es nicht um Navision geht. Mit Locks ist hier gemeint, dass es notwendig ist, im Navision-Code Locks zu programmieren. Sonst kann es nämlich zu Dirty-Reads kommen. Das kann dir bei der Native-DB einfach nicht passieren, da das Versionsprinzip immer für einen konsistenten Datenstand sorgt.

Genauso mit dem neuen Befehl FINDSET. Ich muss mich halt gleich festlegen, ob ich die Datensätze modifzieren will oder nicht und das per Parameter mitgeben. Darum muss ich mich beim Native-Server nicht kümmern und er ist trotzdem performant.

Das Sperrverhalten selber hatte ich ja schon in einem vorherigen Punkt ganz nach deiner Meinung bewertet. Das bezog sich dann wirklich auf das Sperrverhalten der DBs.

Gruß
Tim

Vielen Dank für euere Unterstützung