Native oder SQL Datenbank ?

Hallo an alle,

hab da gleich noch eine wichtige Frage für die Vorentscheidung bzgl. der Einführung von NAV 5.xx und der Entscheidung für oder gegen MS SQL-Server in unserem Unternehmen. Ich hab in diesem Thread bereits eine Aussage dazu gefunden, aber vielleicht kann man da ja doch ein wenig was dazu sagen...

Wie Natalie schon schrieb:
Navision kann (ab der Version 2.50) sowohl mit dem MS SQL-Server als auch mit der nativen Datenbank betrieben werden.
Beides hat seine Vor- und Nachteile und kann nicht pauschal beantwortet werden.

Wir haben bei unserem derzeitigen System jede Menge IMPORT / EXPORT Schnittstellen im Laufe der Zeit geschaffen um diverse Daten zu exportieren (meist für Excel) und zu importieren (Artikel, Rabatte, Nettopreislisten udgl.) - gerade bei einer großen Menge an Artikelneuanlagen oder Preisänderungen spart dies bei unserem derzeitigen System jede Menge Zeit und Aufwand.

- Gibt es diesbezüglich bei einem der beiden Datenbanksysteme Vorteile?

- Wie schauts mit der ODBC / N-ODBC Anbindung aus, sind die Möglichkeiten Abfragen via Access oder Excel zu machen hier datenbankunabhängig?

- Wird auch für eine ODBC / N-ODBC Abfrage eine Lizenz benötigt?
Für einige Mitarbeiter (zB im Lager) wäre es vermutlich ausreichend
eine Abfrage via Excel oder Access zu erstellen weil dort nichts erfasst sondern nur aktuelle Artikelbestände angezeigt werden müssten. Könnte man anstatt dort eine vollwertige Version zu installieren auch eine parallele Abfrage via ODBC / N-ODBC machen (die upgedatet werden kann!) auch wenn nun alle Lizenznehmer gleichzeitig eingeloggt sind?

Vielen Dank für eure Hilfe.

lg

Grundsätzlich läßt sich eine solche Frage nie ohne weitere Daten beantworten. Insgesamt ist es eine Frage der Benutzeranzahl, Datenbankgröße, gewünschten Skalierbarkeit/Wartbarkeit, Backupstrategien, Nutzung von Reporting und Analyse, Skills der Administratoren etc.

Speziell zu deiner Frage:

Import/Export: Der SQL Server stellt sehr gute und rasend schnelle, von NAV unabhängige Mechanismen für Datenim- und -exporte zur Verfügung. Wir reden hier über Unterschiede im Bereich von durchaus mehreren 100%. Allerdings ohne die (direkte) Möglichkeit der Implementierung einer Geschäftslogik. Ansonsten bleibt halt der Weg über die NAV Mechanismen.

Die Frage bezüglich der Datenbankunabhängigkeit verstehe ich nicht ganz. Mit beiden Systemen kannst du per ODBC auf die Datenbank zugreifen. Ob damit allerdings eine Benutzerlizenz "verbraucht" wird kann ich die ad-hoc nicht beantworten, würde aber tippen: pro Connection eine Lizenz.

Hey fb,
kann mich SilverX nur anschließen, es sind einige Parameter für die Entscheidung zu berücksichtigen. Meiner Meinung nach, sollten die notwendigen Schnittstellen nur eine kleinere Rolle spielen, außer du hast noch eine Application die ebenfalls mit SQL arbeitet - der Datenaustausch ist wesentlich einfacher. So wie es aber aussieht, denkst du mehr an Excel / Access und da bleibt der Zugriff per ODBC gleich. Zu deiner Lizenzfrage, es wird bei jedem ODBC-Zugriff eine Lizenz benötigt. Folgende Punkte sollten bei der Datenbankwahl berücksichtigt werden:
SQL-Server Lizenzkosten, SQL-Server-Administratorwissen, Hardware-Hunger des SQL-Servers, Sortierung von Code-Felder beim SQL-Server;
Du siehst, keine pauschale Antwort möglich, lass Dich einfach von dem NSC deines Vertrauens beraten!

Zum Punkt Sortierung: Bei sauber programmierten Lösungen ist maximal eine Gewöhnungsphase für die Anwender zu kalkulieren. Im Fall einer unsauberen Programmierung ggf. Anpassungsarbeit.

Du könntest ein wenig Licht ins Dunkel bringen, wenn du ein wenig zur Anzahl der Benutzer, Datenbankgröße, Budget für höhere Hardwarekosten usw. schreiben würdest. Auch die zu bewegenden (Import/Export) Datenmengen sind hierfür interessant.

Hallo Carsten, hallo Uwe,

besten Dank für eure Hilfe. Schlussendlich steht eben die Frage dahinter ob wir einen SQL-Server + Lizenzen (was ja doch etwas mehr kostet) überhaupt brauchen...

User / Lizenzen: ca: 20
Datenmenge gesamt: < 5 GB
Skalierbarkeit: sollte gegeben sein, allerdings nicht in extrem großem Umfang
Import / Export: < 20.000 Datensätze pro Table (ART, KRE, DEB, RAB...)

Die Info bzgl. ODBC Abfragen und Lizenzen ist für mich ebenfalls interessant und wichtig - danke. Uwe hat die Sachlage bereits sehr gut erkannt, eine andere SQL Appication ist derzeit nicht geplant, hauptsache geht es wirklich um Abfragen in MS Programmen wie Excel und Access.

Gibt es da für den Import von Daten nach NAV 5.xx (zB Artikelstammdaten) eigentlich gewisse "MUSS-Felder" welche befüllt werden müssen und Vorgaben wie die Daten aufbereitet sein sollten? Bzw. muss man in NAV 5.xx bei Artikeln die eingespielt werden sollen ein Minimum an Feldern (zB Art.Nr. usw.) vorab anlegen damit ein einspielen möglich wird? Ich denke da als reiner Anewnder ja eher Excel-stereotypisch an CSV Dateien mit Trennzeichen udgl...

Oder ist das für den Import dann eine rein programmiertechnische Angelegenheit wie Daten aufbereitet werden müssen? Wie siehts da aus wenn ich Nachhinein beim Artikelstamm zB weitere Felder ergänzt werden sollten?

Es geht hier nicht nur um die einmalige Portierung von unserem derzeitigen System, aufgrund relativ häufiger umfangreicherer Änderungen am Sortiment wäre ein Import sicher ca. 1-2 x Monat erforderlich...

Vielen Dank für eure Antworten.

lg

Zum Thema SQL-Server Lizenzen - wenn du auf den SQL-Server nur für NAV benötigst gibt es spezielle Lizenzen wo nur das Datenbank funktioniert aber welche VIEL günstiger ist als die "normale" SQL-Server Datenbank-Lizenz. Wie dass in Beträgen genau aussieht kann ich dir nicht nennen.

mfg
Jürgen

Habe zum Thema SQL Server Runtime License einen interessanten Blog-Eintrag gefunden

SQL - Server Runtime License

mfG

Hallo fb,
bei einer DB mit < 5 GB und nur 20 Usern lohnt sich meiner Meinung nach keine SQL-DB. Da würde ich die gute "alte" Native-DB nutzen - solange es sie noch gibt! Muss-Felder sind generell in Navision nur die Primery-Felder der jeweiligen Tabelle, also bei Artikeln wäre das die Artikelnummer (CODE). Ansonsten kannst du alle Felder nachpflegen, falsche Werte in Optionsfeldern bzw. Feldern mit Relationen zu anderen Tabellen werden mit einem Abbruch des Dataports "bestraft". Datensätze die bereits angelegt sind, werden durch den nochmaligen Import aktualisiert (kann man in den Properties des Dataports einstellen - auch der Feldtrenner). Muss beim Import jedoch eine Datenbereinigung oder -pflege stattfinden, mußt du im "OnAfterImport-Trigger" die Daten ggf. ändern/erweitern. Solltest du grundsätzlich einen Wert vergessen, wird dir Navision dies zur gegebener Zeit (z.B. beim Zubuchen) "mitteilen".

Hallo SilverX,
kann deiner Aussage über die Sortierung nicht ganz zustimmen, wenn du eine Native-DB auf SQL portierst und du z.B. verschieden lange Debitornummern hast, wird die Sortierung autom. auf alphanummerisch umgestellt und muss über die Fieldpropertie für den SQL-Server auf Integer umgesetzt werden - solange du ohne Vornullen arbeitest kein Problem

Habe zum Thema SQL Server Runtime License einen interessanten Blog-Eintrag gefunden

SQL - Server Runtime License

mfG

Was der Kamerad hier allerdings schreibt, ist nicht ganz richtig:

1) Die "Runtime" Lizenz beinhaltet keinerlei technische Restriktionen und funktioniert wie jede andere SQL Server "Version" - oder anders gesagt: das Produkt ist identisch. Die Lizenz gibt ledeiglich das "Recht" nur ein NAV System damit zu nutzen. Welche weiteren DB allerdings zum "System" gehören ist im Prinzip Verhandlungssache ...

2) Auch die RT beinhaltet die 32bit und 64bit Version. Das Produkt "SQL Server" besteht aus BEIDEN Komponenten, man kann weder eine 32bit noch 64bit Version separat kaufen! Es liegt am Käufer, welche Version er nutzen möchte.

Noch ein Hinweis zu den Preisen (wenn ich mich Recht erinnere):

120 EUR pro User SQL Server 2005 STD (CAL und Server)
220 EUR pro User SQL Server 2005 EE (CAL und Server)

D.h. also im aktuellen Fall z.B. 20 x 120 EUR = 2400 EUR; beinhaltet Server und CAL; zum Vergleich: regulär gekauft liegt der Preis - meine ich - bei etwa 5000 EUR inkl. 25 CAL ...

Gruß,
Jörg

Hallo fb,
bei einer DB mit < 5 GB und nur 20 Usern lohnt sich meiner Meinung nach keine SQL-DB. Da würde ich die gute "alte" Native-DB nutzen - solange es sie noch gibt! Muss-Felder sind generell in Navision nur die Primery-Felder der jeweiligen Tabelle, also bei Artikeln wäre das die Artikelnummer (CODE).

Hallo Uwe,

wird wohl auch die Native werden, danke für die Info. Im Artikelstamm ist also die Artikelnummer ein Primary Feld? Uns wurde gesagt, dass die Artikelnummer jederzeit auch nachträglich geändert werden kann?

Moin!

Im Artikelstamm ist also die Artikelnummer ein Primary Feld? Uns wurde gesagt, dass die Artikelnummer jederzeit auch nachträglich geändert werden kann?

Das eine muss das andere ja nicht ausschließen.

Gruß, Marc

... die Artikelnummer ein Primary Feld? Uns wurde gesagt, dass die Artikelnummer jederzeit auch nachträglich geändert werden kann?

Hallo FB,
es gibt in Navision grundsätzlich wenig Felder, deren Inhalt du nachträglich nicht mehr ändern kannst. Code-Felder sind in der Regel so definiert, dass eine Änderung (RENAME) auch eine Änderung in den dazugehörigen Tabellen beinhaltet (Customer -> Customer Ledger Entries) - wenn es sauber programmiert ist ; bei Standardtabellen kann man davon ausgehen, nur bei Individualanpassungen sollte das geprüft werden.