Πιστεύω ότι έχει να κάνει με το implementation της database στον SQL Server...
Κι εξηγώ:
Η native database του Navision δεν είναι όπως αυτή του SQL Server (σε ότι αφορά τη σχέση των clustered / non-clustered indexes). Όταν στον SQL Server υπάρχει ένα clustered index πχ MachineNo και προσθέσεις ένα non-clustered index πχ MachineComponentΝο, τότε τo non-clustered index "κάθεται" πάνω στο clustered με αποτέλεσμα τα leaf pages του index να περιέχουν τον συνδυασμό non-clustered index key + clustered index key (MachineΝο+MachineComponentNo) για κάθε κλειδί.
Στη native database του Navision, απ' ότι έχω καταλάβει, τα indexes κρατούνται ξεχωριστά για κάθε συνδυασμό κλειδιών, δηλ, για κάθε ομάδα primary + secondary key/keys. Μάλιστα, είναι πολύ σπουδαία η κατάλληλη επιλογή κλειδιών για διαδικασίες όπως αναζήτηση εγγραφών, reporting, κλπ που πολλοί πίνακες του Navision είναι φορτωμένοι με πληθώρα εναλλακτικών συνδυασμών κλειδιών που χρησιμοποιούνται ανάλογα με το τι θες να κάνεις.
Που είναι το πρόβλημα λοιπόν; Ο τύποι που έκαναν το port της database, όρισαν το primary key σε κάθε πίνακα στον SQL Server (που από default γίνεται και clustered index) και κατόπιν όρισαν τα non-clustered indexes αλλά με χαζό (για να μην πω τίποτε άλλο) τρόπο.
Φαντάσου, κάτι σαν:
CREATE TABLE MachineComponent(
MachineComponentΝο int PRIMARY KEY,
MachineComponentNAme varchar(100),
MachineNo int FOREIGN KEY ...
...)
CREATE NONCLUSTERED INDEX x
ON MachineComponent(MachineComponentΝο, MachineNo)
CREATE NONCLUSTERED INDEX y
ON MachineComponent(MachineComponentΝο, MachineComponentName)
CREATE NONCLUSTERED INDEX z
ON MachineComponent(MachineComponentΝο, MachineComponentType, MachineComponentName)
κλπ
Κανένας άνθρωπος που ξέρει περί SQL Server δεν θα έβαζε το MachineComponentΝο μέσα στα x, y και z indexes γιατί ξέρει ότι το MachineComponentΝο "εννοείται" κατά κάποιο τρόπο αφού το non-clustered index θα πέσει πάνω στο clustered. Και φυσικά, δεν υπάρχει κανένας κανόνας που να λέει ότι θα πρέπει υποχρεωτικά το clustered index field να είναι και primary key μιας και συνήθως για clustered indexes είναι καλύτεροι υποψήφιοι κλειδιά που χρησιμοποιούνται για αναζήτηση σε ranges τιμών, για ταξινόμηση, κλπ.
Το αποτέλεσμα αυτού του λανθασμένου σχεδιασμού είναι non-clustered indexes με πολύ λιγότερα non-cluster keys ανά leaf-page (αφού το μέγεθος του κλειδιού είναι για παράδειγμα MachineComponentΝο+MachineComponentΝο+MachineNo αντί MachineComponentCode+MachineNo)
πράγμα που σημαίνει πολύ περισσότερα I/O opperations καθώς και μη αποτελεσματική αξιοποίηση των clustered indexes. Όλα αυτά μπορείς εύκολα να τα διαπιστώσεις αν εξετάσεις τα indexes σε μια SQL Server database του Navision.
Τώρα, δεν γνωρίζω για ποιόν λόγο έγινε ότι έγινε, ενδεχομένως να μπορείς να βάλεις χέρι και να αρχίζεις να αλλάζεις τα indexes στον SQL Server κατά το δοκούν... Δεν το έχω δοκιμάσει και δεν ξέρω αν θα παρουσιαστεί κάποιο πρόβλημα όπως για παράδειγμα στην περίπτωση που θα ορίσεις νέα συμπληρωματικά κλειδιά για κάθε πίνακα, μέσα από το περιβάλλον ανάπτυξης του Navision. Ελπίζω να λυθούν αυτά τα προβλήματα στην έκδοση 4 γιατί η εντύπωση που μου δημιουργήθηκε από όλη αυτήν την ιστορία είναι "Α, είναι προϊόν Microsoft, πρέπει να παίζει οπωσδήποτε με SQL Server, φτιάξτο τώρα να τρέχει και αργότερα το σενιάρουμε"!
Vir prudens non contra ventum mingit