Αν και έχει σχέση περισσότερο με ύλοποίηση-σχεδιασμό, πιστεύω ότι ταιριάζει περισσότερο στην ενότητα για τις βάσεις.

Έχω μια εφαρμογή η οποία ουσιαστικά είναι ένα read-only reporting front end για χρήστες-πελάτες. Όλοι συνδέονται με μοναδικό user name, το οποίο προφανώς αντιστοιχεί με join σε πίνακα με ένα μοναδικό Primary key πελάτη ώστε να τραβάω τα πράγματα με απλά views κλπ...

Zητήθηκε λόγω δημιουργίας υποκαταστημάτων με αυτόνομα συστήματα και ξεχωριστές βάσεις, η ενσωμάτωσή τους στο συγχρονισμό, ώστε να χρησιμοποιείται η ίδια εφαρμογή από όλα τους πελάτες όλων των υποκαταστημάτων. Το πρόβλημα είναι ότι προφανώς κάθε βάση έχει δικό της primary key για τους πελάτες.

Πως θα μπορούσα να το αντιμετωπίσω καλύτερα?

Η πρώτη σκέψη ήτανε να κρατάω ένα field για κάθε πελάτη για το σε ποιό υποκατάστημα ανοίκει, και να το περνάω στις stored procedures. Εκει με ένα case, θα κάνω join και θα επιστρέφω αποτελέσματα από διαφορετικούς πίνακες, οι οποίοι θα κρατάνε ξεχωριστά τα στοιχεία για κάθε υποκατάστημα. ΔΕΝ μου αρέσει όμως πολύ...

Μια 2η σκέψη ήτανε να ξεκινήσει το identity auto number από πολύ ψηλά για κάθε υποκατάστημα και κάθε ένα να χρησιμοποιεί διαφορετικό "range" Ids. Κάτι σαν την αριθμοδότιση των ΙΡ διευθύνσεων. έτσι θα μπορώ να τα κρατάω όλα σε έναν πίνακα χωρίς αλλολοκαλυπτόμενα primary keys. Aν PK είναι πχ numeric(18,0), και κατά μέσω όρο κάθε υποκατάστημα έχει 1εκατ. πελάτες, μπορώ να δώσω πχ το 1000000... στο πρώτο, το 2000000... στο 2ο κ.ο.κ.

Έχετε τυχόν προτάσεις πάνω σε αυτό?

Ο συγχρονισμός γίνεται με linked servers, drop tables τοπικά, και select * into localserver.table from remoteserver.table . Ξέρω δεν είναι και πολύ efficient αλλά είναι αρκετά απλό, ειδικά μιας και τα δεδομένα είναι και θα παραμείνουνε read only. To κακό είναι ότι έτσι δεν μπορώ να κάνω insert από διαφορετικούς πίνακες στον ίδιο τοπικό γιατί μου βγάζει ότι ο πίνακας ήδη υπάρχει. (Γι αυτό τον κάνω drop πρώτα τοπικά). Μήπως έχετε να προτείνετε κάτι καλύτερο και για αυτό?

Ευχαριστώ εκ των προτέρων.

---

Simple Photography

ΓΜΤ! Έφραφα πόση ώρα και από βλακεία μου τα έχασα!

Περίληψη:

Μια λύση είναι φτιάξεις ένα "master" table όπου θα ρίχνεις όλες τις εγγραφές από τα remote tables. Αυτό το master table θα έχει επιπρόσθετα ως primary key ένα uniqueindentifier πεδίο που θα αποκτά τιμή μέσω default value NEWID(). Με αυτόν τον τρόπο δεν θα έχεις overlaps και θα είναι πιο καθαρή η λύση σου καθώς δεν σε περιορίζει χρονικά σε αντίθεση με το #2. Κάτι τέτοιο κάνει και το Merge Replication.

Αντί για SELECT ... INTO ... FROM ... θα κάνεις INSERT INTO ... SELECT ώστε να είναι έτοιμος ο πίνακας και να μην τον δημιουργεί κάθε φορά. Θα χρειαστεί μόνο ένα WHERE ώστε να κάνεις INSERT εγγραφές από μια ημερομηνία και μετά.

Αν κατάλαβα καλά το θέμα με τους πελάτες: Ενδέχεται να έχεις τον ίδιο πελάτη σε διαφορετικά υποκαταστήματα με διαφορετικό PK; Αν ναι, θα πρέπει να φτιάξεις ένα master table πελατών όπου κάθε πελάτης θα έχει unique name (βλ. Northwind -> CompanyName=Alfreds Futterkiste | Customer ID=ALFKI) και θα συνδέεται με έναν άλλον lookup πίνακα (one-to-many) που θα κρατάει τον κωδικό στο κάθε υποκατάστημα. Όταν θα τραβάς τον κάθε πελάτη, θα κάνεις lookup και θα αντικαθιστάς τον κωδικό με το global Customer ID του master πίνακα. Όμως ξέχνα το INSERT INTO ... SELECT, πλέον μιλάμε για transformation, SSIS ή DTS. Μπορείς να το υλοποιήσεις και με queries αλλά δεν είναι και τόσο scalable.

---

Vir prudens non contra ventum mingit

Oι πελάτες ανοίκουνε μόνο σε ένα υποκατάστημα (ευτυχώς.. :D )

Το πρόβλημα είναι ότι θα υπάρχουνε 2 πελάτες με το ίδιο PK, αλλά από διαφορετικά υποκαταστήματα.

Το "κακό" με το νέο master πίνκακα που λές έιναι ότι θα πρέπει να κρατάω το νέο PK και στους υπόλοιπους πίνακες οι οποίοι γίνονται join από την εφαρμογή για να βγούνε οι διάφορες αναφορές. Είναι πιο σωστό από το range που σκέφτομαι, αλλά θα μπερδέψει αρκετά τα πράγματα και ο συγχρονισμός θα πρέπει να γίνεται πελάτη-πελάτη και μπορεί να πάρει ΠΑΡΑ πολύ ώρα...

Βλέπω πιο σωστό το να φτιαχτεί το 2πλό ΡΚ που περιέγραψα στο 1. Δηλαδή να ψάχνω χρήστη με αυτό το ID από αυτό το υποκατάστημα... Το πέρασμα του υποκαταστήματος μπορεί να γίνει κατά το συγχρονισμό από κάθε βάση, οπότε γλυτώνεις και το overhead του να βάζεις πελάτη-πελάτη και να παίρνεις το τρέχον νέο ΡΚ και να εισάγεις τα υπόλοιπα στοιχεία με αυτό στους άλλους πίνακες... Χρονοβόρο...

---

Simple Photography

Μάλλον δεν έχω καταλάβει τι προσπαθείς να κάνεις... Θες στο τέλος της ημέρας, όλα τα υποκαταστήματα να συγχρονίζονται μεταξύ τους και να βλέπουν κοινά data;

---

Vir prudens non contra ventum mingit

Ναι αλλά όχι μεταξύ τους. Σε μια ξεχωριστή βάση που συγκεντρώνει διάφορα στοιχεία και τα χρησιμοποιεί για στατιστικά-αναφορές.

---

Simple Photography

Ωραία. Πάντως πιστεύω ότι πρόβλημα με τους υπόλοιπους πίνακες θα έχεις έτσι κι αλλιώς. Πχ αν έχεις έναν πίνακα Orders που βλέπει στο PK του Customers (FK CustomerID), πως θα αντιληφθεί ότι πλέον έχει γίνει composite το κλειδί;

---

Vir prudens non contra ventum mingit

Γι' αυτό λέει να κολλήσει σε όλους τους πίνακες στην reporting βάση από ένα CompanyID και να κάνει όλα τα κλειδιά του σύνθετα. Βέβαια θα πρέπει να ξαναδεί όλο το indexing από την αρχή με αυτό τον τρόπο.
Η πρόταση του Μάνου να γίνουν τα κλειδιά GUIDs μου άρεσε, αλλά έχει κόστος στη μετάπτωση και ίσως όχι αμελητέο, αφού ξαναορίζεις τα κλειδιά σου. Ίσως όμως να βελτιώνεται με staging πίνακες για τις αντικαταστάσεις... δεν ξέρω.

---

Νατάσα Μανουσοπούλου

Μου φαίνεται πιο ανώδυνο να το κάνω με composite ΡΚ, αφού και τα οφέλη δεν είναι και τόσο μεγάλα και άμεσα με τη χρήση ενός identity unique PK.

Με το indexing προς το παρόν δεν θα έχω πρόβλημα, μιας και η εφαρμογή είναι read-only, οπότε δεν θα υπάρχει overhead με ενημερώσεις του index, επειδή η μηχανή θα πρέπει να ενημερώνει σύμφωνα με το composite key.

Μόνο κατά το συγχρονισμό θα υπάρχει ένα μικρό overhead.

Το κακό είναι ότι έτσι θα χρειαστούνε αλλάγές σε όλες τις SP.

Αυτό μπορεί να αποφευχθεί, αν γίνει όπως είπατε, αλλά με αντικατάσταση του υπάρχοντος ID πελάτη με το GUID, αλλά θα υπάρχει πρόβλημα γιατί το υπάρχον ID εμφανίζεται σε εναφορές και είναι γνωστό(δεν μπορεί να αλλάξει) για κάθε πελάτη... Οπότε πρέπει να γίνουνε αλλάγές και στο dal για να φέρνει το υπάρχον ID από άλλο πεδίο, οπότε το πράγμα μπερδεύεται ακόμη περισσότερο...

Ενώ ένα απλό επιπλέον πεδίο με το companyID στο ΡΚ μπορεί να χρησιμοποιηθεί transparently από τις SP στο join χωρίς να αλλάξει τίποτα στην ίδια την εφαρμογή, ενώ οι αλλαγές στις SP θα είναι αρκετά απλές...

Σκέψεις?

---

Simple Photography

Μα το γνωστό ID έχει νόημα όσο αναφέρεται σε ένα υποκατάστημα. Όταν θα έχεις πολλά υποκαταστήματα πλέον ο ίδιος πελάτης θα έχει διαφορετικό ID ανά υποκατάστημα και κατά συνέπεια θα υπάρχει inconsistency αφού αυτός που θα διαβάζει το report θα συναντά ας πούμε τον κωδικό 1360 και την μία θα αναφέρεται στον πελάτη A ενώ την άλλη στον B.

Αυτό πάντως είναι ένα σχεδιαστικό πρόβλημα της βάσης. Ο χρήστης δεν θα πρέπει να έρχεται ποτέ σε επαφή με το φυσικό κλειδί που προσδιορίζει κάθε εγραφή. Γι αυτό και στο παράδειγμα της Northwind έχεις άλλο ID για τα database operations (surrogate key) και άλλο unique πεδίο για χρήση από τους ανθρώπους (natural key)

---

Vir prudens non contra ventum mingit

Σωστό αυτό που λές. To natural key υπάρχει και είναι το user name που χρησιμοποιείται από κάθε πελάτη και είναι μοναδικό σε όλες τις βάσεις.

Για λόγους που δεν έχουν διευκρυνιστεί, θέλουν να εμφανίζεται όμως και το ΡΚ στις αναφορές, μάλλον για λόγους ευκολίας χρήσης, κυρίως με κάποια εργαλεία που δεν είναι άμεσα συνδεδεμένα μεταξύ τους και με την κεντρική βάση κάθε υποκαταστήματος.

Εφ'όσον όμως οι τρέχουσες αναφορές απευθύνονται μόνο σε πελάτες, δεν υπάρχει ιδιαίτερο πρόβλημα, καθώς για περαιτέρω απευθύνεται κατευθείαν στο υποκατάστημά του ( το οποίο είναι ουσιαστικά ξεχωριστή εταιρεία) και όχι στα άλλα.

---

Simple Photography