pkanavos wrote:

Όσο για το αν χρειάζεται ή όχι να χρησιμοποιήσει κανείς τη βάση του MS CRM ... πες πως θέλεις να τραβήξεις δεδομένα από αυτή και να φορτώσεις ένα data warehouse. Η να φορτώσεις μαζικά δεδομένα στο CRM από ένα άλλο σύστημα. Θα προτιμούσες να το κάνεις αυτό μέσω ενός γρήγορου DTS ή ενός Web Service το οποίο θα ήταν πολλές φορές αργότερο?

Προσωπικά, είχα νιώσει το σοκ, όταν βρέθηκα να δουλεύω σε μια εφαρμογή που δεν είχε foreign keys - δεν πίστευα ότι μπορεί να τα καταφέρει. Όπως πολύ σωστά αναφέρεις, αλλά είχε αναφερθεί και η Νατάσα προηγουμένως, το ερώτημα είναι τι γίνεται με τα bulk imports. Στην περίπτωση του MS CRM, έχει από μόνο του bulk import tools. Οπότε δεν χρειάζεται κάποιος να το σκεφτεί δεύτερη φορά. Σε τρίτες εφαρμογές που θέλουν να κάνουν κάτι παρόμοιο, το ζήτημα είναι τι μπορεί να γίνει.

Ξαναλέω το ότι δεν υπάρχουν τα foreign keys στην βάση, δεν πάει να πει τα δεδομένα δεν είναι κανονικοποιημένα, δεν υπάρχουν look-up πίνακες και οι πίνακες των οντοτήτων δεν έχουν σχέσεις μεταξύ τους. Απλά υπεύθυνοι να τηρηθούν αυτά είναι το data layer και όχι η βάση. Σίγουρα οι βάσεις χωρίς foreign keys δεν είναι μια συνηθησμένη περίπτωση. Αλλά δεν είναι και ένα ακατόρθωτο practice. Και DTS μπορείς να χρησιμοποιήσεις, και bulk inserts μπορούν να γίνουν. Αυτό που είναι απαραίτητο, είναι ότι ο προγραμματιστής που υλοποιεί αυτά, δεν μπορεί να είναι κάτω του μέτριος.

Δεν μπορώ να καταλάβω, γιατί αυτή η αμετακίνητη θέση ότι πρέπει σώνει και καλά η βάση να έχει foreign keys που να υλοποιούνται και να τηρούνται από τη βάση δεδομένων. Είναι σαν να υποστηρίζεις ότι ο σωστός τρόπος για να γίνει μια μεγάλη εφαρμογή είναι C++ και ας είναι ο χρόνος που απαιτήται πολλαπλάσιος από ότι θα ήθελε κάποια άλλη γλώσσα προγραμματισμού. Δεν υπάρχουν ταμπού στο τι πρέπει να γίνει και τι να μην γίνει για να έχουμε μια επιτυχημένη εφαρμογή. Υπάρχουν best practices - και τα best practices στις εφαρμογες CRM, ERP, HRM είναι ότι αυτές χρησιμοποιούν βάσεις που δεν έχουν foreign keys. Έτσι δουλεύει το SAP, Peoplesoft, MS CRM και κανείς δεν ξέρει ακριβώς πόσα ακόμα. Έτσι κατορθώνουν perfomance, αποδεύσμευση της απόδοσης της εφαρμογής από την βάση δεδομένων, έτσι έχουν σχεδιαστεί να δουλεύουν και δουλεύουν.

Τι ωφελεί να εμένει κάποιος ότι πρέπει να έχουμε βάσεις δεδομένων που οι ίδιες υλοποιούν τα foreign keys; Αφού έχουμε παραδείγματα εφαρμογών στην παραγωγή που δεν είχουν foreign keys και όμως αυτές είναι επιτυχημένες, όσο στην λειτουργικοτητά τους όσο και στο intergration με τρίτες εφαρμογές!

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Βαγγέλη δε νομίζω κανείς να αφορίζει κάποια λύση. Όσοι εκφραστήκαμε για το "κατά" του να μην υπάρχουν constraints στη βάση, το κάναμε με επιχειρήματα. Επίσης, δεν είπαμε Γιώργο ότι σώνει και καλά η χρήση των constraints στη βάση είναι καθολικός κανόνας, είπαμε ότι τα application level constraints είναι μια λύση που δεν την απορρίπτουμε αλλά χρειάζεται να υπάρχει κάποιος πολύυυυυ καλός λόγος.

Αντιθέτως, το ότι υπάρχουν λύσεις από διάσημα s/w που δεν χρησιμοποιούν constraints δεν είναι απαντά στα μειονεκτήματα που θέσαμε τόσο εγώ, όσο και ο Παναγιώτης. Το "αυτοί ξέρουν" προσωπικά δεν μου λέει τίποτα, αντιθέτως μου θυμίζει αυτό που λένε για τις μύγες . Άν φτιάξουμε ένα matrix με υπέρ και κατά, σίγουρα δεν μπορεί να μπει στα υπέρ το "Έτσι δουλεύει το SAP, Peoplesoft, MS CRM". Σαφώς αν μια εταιρεία μπορεί να αναθέσει σε ένα development team να αναπτύξει ένα constraint layer σε application level, τότε με γειά της με χαρά της. Ωστόσο είναι μια απόφαση που "πληρώνεται" ποικιλοτρόπως. Ας πούμε, μικρότερες εταιρείες δεν έχουν τέτοια πολυτέλεια από resources - δεν είναι όλοι SAP, Microsoft και Oracle. Από την άλλη, μπορεί ο architect του μεγάλου s/w house (sic) να επιλέξει να έχει ακριβώς μια τέτοια ομάδα αντί να έχει διαφορετικές ομάδες που να είναι η κάθε μία υπεύθυνη για το Database-specific development, σε περίπτωση που η εφαρμογή πρόκειται να παίζει σε πολλαπλά RDBMS. Ορίστε! Παρουσίασα ένα επιχείρημα υπέρ του application-level-constraints κόλπου! Μπορεί να υπάρχουν κι άλλα...

 

---

Vir prudens non contra ventum mingit

Και να μην ξεχνάμε ότι οι βάσεις αυτών των εφαρμογών ΕΙΝΑΙ κλειστές και αποκλειστικής χρήσης. Ναι, μπορείς να διαβάσεις από αυτές, αλλά όχι, δεν μπορείς να γράψεις σε αυτές χωρίς να χρησιμοποιήσεις τα εργαλεία ή τα API τους. Δεν μπορείς να τις χρησιμοποιήσεις για άλλες εφαρμογές πέρα από αυτές που σου δίνει η κατασκευάστρια εταιρεία. Και λέγοντας "αυτές" εννοώ τις βάσεις όχι τα API των εφαρμογών.

Από τη στιγμή που μπορεί κάποιος να τροποποιήσει δεδομένα παρακάμπτωντας το API των εφαρμογών, η βάση πρέπει να έχει και τα κατάλληλα constraints. Και ας μην ξεχνάμε, ότι οι περισσότερες ομάδες δεν έχουν τα περιθώρια να υλοποιήσουν στιβαρό μηχανισμό constraints στην εφαρμογή και όχι στη βάση.

Εν ολίγοις, αν θέλετε να φτιάξετε εφαρμογές επιπέδου MS CRM, έχετε τη δυνατότητα να υλοποιήσετε τους ελέγχους που κάνει το MS CRM, να παρέχετε το δικό σας API, και να εμποδίσετε τους πελάτες σας να χρησιμοποιήσουν τη βάση σας για άλλους λόγους, go ahead.

Αν όμως δεν μπορείτε να παρέχετε όλα τα παραπάνω, think again. Κάποιος λογος θα υπάρχει που υπάρχουν τα foreign keys και τα constraints.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

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

Λυπάμαι αλλά λόγω έλλειψης χρόνου δε μπορώ αυτή τη στιγμή να απαντήσω εκτενώς. Ελπίζω στο μέλλον να μπορέσω να βρω το χρόνο και να αναφέρω λίγα πράγματα παραπάνω.

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

Καλή σας ημέρα

---

Βαγγέλης Ξανθάκης
Independent Consultant
www.aylos.com

Κι όμως, θυμάμαι ότι επειδή τα μεγάλα ιεραρχικά και δικτυακά συστήματα είχαν προβλήματα, δημιουργήθηκε το σχεσιακό μοντέλο. Ο πιο σημαντικός λόγος ήταν ότι το ιεραρχικό σύστημα περιορίζει τις σχέσεις που μπορούν να έχουν τα δεδομένα μόνο στις ιεραρχίες. Όταν θέλεις να έχεις περισσότερους από ένα τρόπους πρόσβασης στα δεδομένα, τα ιεραρχικά συστήματα αρχίζουν να εμφανίζουν προβλήματα. Αυτός ήταν και ένας από τους λόγους που οι object βάσεις δεν κατάφεραν να γίνουν mainstream αλλά κατέκτησαν κυρίαρχες θέσεις σε niche εφαρμογές, όπως τα συστήματα ελέγχου.

Διαπίστωσα κιόλας ότι νωρίτερα είπα μια μπούρδα. Τα Foreign keys ΔΕΝ είναι relationships! Τα relationships καθορίζονται από τους πίνακες, όχι τα foreign keys. Τα foreign keys είναι INTEGRITY CONSTRAINTS! Όταν κανείς ορίζει ένα foreign key λέει ουσιαστικά ότι οι τιμές ενός πεδίου μπορούν να πάρουν τιμές που ορίζονται από ένα άλλο πίνακα.

Μπορεί κανείς να ορίσει relations τα οποία αναπαρίστανται με περίπλοκα select statements, τα οποία δεν είναι δυνατόν να αναπαρασταθούν με την 1-προς-1 αντιστοιχία των foreign key constraints. Όταν συμβαίνει αυτό όμως, θα πρέπει να υπάρχει και ένας μηχανισμός ελέγχου για να εμποδίσει τα δεδομένα που δεν ικανοποιούν τα relations και να αντιμετωπίσει τις αναπόφευκτες εγγραφές που θα τα παραβιάζουν και να αποφασίσει τί θα κάνει με τις εγγραφές-φαντάσματα που ξεφεύγουν από αυτά.

Τέλος, το περίεργο με την επιστήμη μας είναι ότι πολλές φορές τα ίδια θέματα εμφανίζονται ξανά και ξανά. Άυτό έγινε με τη διαδρομή ιεραρχικό μοντέλο -> σχεσιακό μοντέλο -> object oriented βάσεις. Αυτό έγινε και με το message passing -> RPC calls -> remote objects -> SOA με Message passing! Άλλοτε, οι νέες υλοποιήσεις των παλαιών ιδεών λύνουν τα προβλήματα των αρχικών, όπως έγινε με τα web services. Άλλοτε, τα παλαιά προβλήματα παραμένουν άλυτα και βάζουν "τρικλοποδιά" στις νέες ιδέες, όπως έγινε με τις object βάσεις.

Για να παραφράσω τον Santayana, όταν θυμάσαι τα λάθη του παρελθόντος, έχεις ελπίδες να μην τα επαναλάβεις.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

pkanavos wrote:

Τα Foreign keys ΔΕΝ είναι relationships! Τα relationships καθορίζονται από τους πίνακες, όχι τα foreign keys. Τα foreign keys είναι INTEGRITY CONSTRAINTS! Όταν κανείς ορίζει ένα foreign key λέει ουσιαστικά ότι οι τιμές ενός πεδίου μπορούν να πάρουν τιμές που ορίζονται από ένα άλλο πίνακα.

Είναι πολύ ενδιαφέρουσα αυτή η προσέγγιση. Αν και στον sql server - φαντάζομαι και σε άλλα rdbms - μπορείς να ορίσεις foreign keys χωρίς integrity constraints, οπότε τότε τα εκφυλίζεις σε απλά relations.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Βάσεις Δεδομένων 4ου έτους! Είχα προλάβει και τα ιεραρχικά συστήματα και τα δικτυακά συστήματα στην εξεταστέα ύλη! Δεν είναι τυχαίο εξάλλου που στον SQL Server τα foreign keys αναφέρονται σαν Foreign Key Constraints, και όχι relations! Βέβαια, το μπλέκουν το πράγμα όταν στο κυρίως reference τα αναφέρουν ως constraints, και στα visual εργαλεία τα αναφέρουν ως relations!

Παλαιότερα πάντως (10 χρόνια πριν και βάλε) τα foreign keys κοστίζανε σε lookups, γι αυτό μπορούσες να ορίσεις ότι θα υπάρχουν αλλά δεν θα έχουν ισχύ. Δίναν πάντα και ένα utility το οποίο έλεγχε τα constraints το βράδυ και ανέφερε errors. Στον SQL Server αυτό είναι το "DBCC CHECKCONSTRAINTS () WITH ALL_CONSTRAINTS".

Ένας λόγος πάντως που γίνεται μπέρδεμα πλέον μεταξύ constraints και relations είναι ότι τα εργαλεία των βάσεων για physical database diagrams τα εμφανίζουν σαν relations. Στα κλασσικά διαγράμματα ERD και ORM, οι σχέσεις υλοποιούνται με πίνακες αν είναι M-N και με FKs αν είναι 1-N, αλλά ποτέ δεν αναφέρονται τα FKs ως relations. Δεν έχω καμμία βάση υπόψη όμως που να περιέχει εργαλεία για ER διαγράμματα, τουλάχιστον όχι στο βασικό πακέτο. Ο Oracle Designer τα δίνει, αλλά αυτός είναι extra.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Καλημέρα.

Διορθώστε με αν κάνω λάθος, αλλά η συζήτηση γίνεται σε θεωρητικό επίπεδο. Δε πιστεύω ότι υπάρχει εταιρεία software στην Ελλάδα, αλλά και στον κόσμο, που να θεωρεί ότι αξίζει να σπαταλήσει χρόνο και ανθρώπινο δυναμικό για να φτιάξει κάτι που τα RDBMS κάνουν έτσι και αλλιώς. Ασφαλώς δε μιλάω για εταιρείες του μεγέθους της MS ή της SAP.

Από την άλλη ασφαλώς και είναι πρόκληση για ένα developer να κάνει κάτι τέτοιου μεγέθους. Σε όποιον το δοκιμάσει του εύχομαι καλό κουράγιο και υπομονή.

---

System crashed: Coffee_Cup.Content is null
Please assign coffee to Content and press any key to continue and any other key to cancel

Καλέας Κων/νος

moruin wrote:

Καλημέρα. Διορθώστε με αν κάνω λάθος, αλλά η συζήτηση γίνεται σε θεωρητικό επίπεδο. Δε πιστεύω ότι υπάρχει εταιρεία software στην Ελλάδα, αλλά και στον κόσμο, που να θεωρεί ότι αξίζει να σπαταλήσει χρόνο και ανθρώπινο δυναμικό για να φτιάξει κάτι που τα RDBMS κάνουν έτσι και αλλιώς. Ασφαλώς δε μιλάω για εταιρείες του μεγέθους της MS ή της SAP. Από την άλλη ασφαλώς και είναι πρόκληση για ένα developer να κάνει κάτι τέτοιου μεγέθους. Σε όποιον το δοκιμάσει του εύχομαι καλό κουράγιο και υπομονή.

Δεν ξέρω αν κάνεις λάθος, αλλά μάλλον το ίδιο υποστηρίζουμε όλοι.
Βέβαια όλοι εξ ορισμού ασχολούμαστε με το extreme sport του development και πολλές φορές μπαίνουμε στην παγίδα να κάνουμε τρελά πράγματα!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.