Δεν θα πρέπει να είναι σε θέση το RDBMS, εφόσον έχεις βάλει ένα constraint "price>=0", να σου απορρίψει το update? Ή μήπως θα έπρεπε να φτιάξεις μια ερφαρμογή που να κάνει αυτή τη δουλειά, ίσα-ίσα για ένα update;


Ναι είναι ευθήνη της εφαρμογής να μην κάνει update την τιμή σε αρνητικό αριθμό ή να μην β ημερομηάλεινία 20005 αντί για 2005. Αν είναι να περιμένεις το SQLException για να καταλάβεις οτι έχεις λάθος στοιχεία, τότε έχεις και λάθος πρόγραμμα.

Δεν είναι κακό να μπορεί η βάση να καταλαβαίνει τις λάθος καταχωρήσεις αλλά είναι σαν να λέμε οτι η C είναι toy language γιατί δεν σε εμποδίζει από το να περάσεις τα όρια ενός array!

Dimitris wrote:

Ναι είναι ευθήνη της εφαρμογής να μην κάνει update την τιμή σε αρνητικό αριθμό ή να μην β ημερομηάλεινία 20005 αντί για 2005.

Ποιάς απ' όλες τις εφαρμογές? Δεν είναι μόνο μία η εφαρμογή που κοιτάει μια βάση. Ακόμα και αν φτιάχνεις μια καινούρια εφαρμογή με μια εντελώς νέα βάση, κάποια στιγμή θα θέλεις να προσθέσεις άλλη μια εφαρμογή, ή κάποιος άλλος θα θέλει να φτιάξει μια νέα εφαρμογή πάνω από τη βάση σου. Τί θα κάνει τότε? Θα πρέπει να βρει τον δικό σου κώδικα για να καταλάβει τί συμβαίνει? Και αν χρειαστούν κάποιες αλλαγές στη βάση? Θα πρέπει να αλλάξουν όλες οι εφαρμογές που τη χρησιμοποιούν?

Αν γίνει αυτό που προτείνεις θα πρέπει να φτιάξεις και κάποια batch που θα τρέχουν περιοδικά για να ελέγχουν ότι τα δεδομένα της βάσης είναι σωστά. Κάποτε αυτό ήταν αποδεκτό, επειδή τα μηχανήματα ήταν αργά και κόστιζε πολύ να τρέχει κανείς τους ελέγχους για τα constraints για κάθε insert/update/delete. Σήμερα, τα μηχανήματα είναι πολύ πιο γρήγορα και κανείς δεν έχει όρεξη να σπαταλήσει χρόνο για κάτι που η database μπορεί να το κάνει πολύ απλά μόνη της.

Όσα λες θα ίσχυαν αν η βάση ήταν απλά ένα ακόμα component της εφαρμογής. Αυτό όμως δεν ισχύει παρά μόνο σε εξαιρετικά απλές εφαρμογές. Ακόμα και μηχανογράφηση video club να κάνεις, σε ένα και μόνο υπολογιστή, δεν είσαι σίγουρος ότι δεν θα προστεθεί κάποια στιγμή και άλλη εφαρμογή στην ίδια βάση. Μπορεί το video club να βάλει και ένα ATM για την επιστροφή των ταινιών. Αυτό ήταν σπάνιο πριν από μερικά χρόνια, αλλά κοντεύει να γίνει στάνταρ πλέον.

Όλα αυτά δεν τα λέμε επειδή είμαστε κολλημένοι με τον SQL Server ή μισούμε το MySQL. Είναι βασικές αρχές οι οποίες ισχύουν εδώ και δεκαετίες, χωρίς τις οποίες δεν μπορείς να φτιάξεις σωστές εφαρμογές. Ανήκουν στην ίδια κατηγορία με το "σπάτε τον κώδικα σε functions", "αντί να κάνετε copy-paste τον κώδικα που χρειάζεστε φτιάξτε ένα function", "δώστε ευκολονόητα ονόματα στις παραμέτρους και τις μεταβλητές". Στην αρχή όλοι τα αγνοήσαμε γιατί τα βρίσκαμε υπερβολικά. Αλλάξαμε βέβαια γνώμη αφού κάηκε η γούνα μας μετά από ένα-δύο project!

---

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

Αν εχεις "μεγαλωσει" παντως με databases τυπου Sql Server (προσωπικα απο τον 6.5 και μετα) και δουλευεις και σε mission critical περιβαλλον, δεν υπαρχει περιπτωση ν'ασχοληθεις με DB που ειτε επιτρεπει να μπαινουν λαθος data η (ακομα χειροτερα) να μπαινουν μονο τα σωστα...

---

Software Engineer, specializes in Microsoft .net/C#, COM, Sql Server and now Python.

Dimitris wrote:

Ναι είναι ευθήνη της εφαρμογής να μην κάνει update την τιμή σε αρνητικό αριθμό ή να μην β ημερομηάλεινία 20005 αντί για 2005. Αν είναι να περιμένεις το SQLException για να καταλάβεις οτι έχεις λάθος στοιχεία, τότε έχεις και λάθος πρόγραμμα.

Αυτό προσπαθώ να σου εξηγήσω, ότι δεν πρόκειται για μία εφαρμογή... Μπορεί να έχεις πολλαπλές εφαρμογές και μάλιστα μπορεί να μην έχεις καν τον κώδικα γι αυτές! Γι αυτό σου έφερα το παράδειγμα με το update. Οι business εφαρμογές δεν είναι πάντοτε html/asp/php/whatever σελίδες και μια βάση από κάτω.

Dimitris wrote:

Δεν είναι κακό να μπορεί η βάση να καταλαβαίνει τις λάθος καταχωρήσεις αλλά είναι σαν να λέμε οτι η C είναι toy language γιατί δεν σε εμποδίζει από το να περάσεις τα όρια ενός array!

Δεν έχει σχέση το ένα με το άλλο... Συγκρίνουμε μήλα με αχλάδια... Θα μπορούσα να δεχθώ μια οποιαδήποτε σύγκριση / παράθεση από features μεταξύ δύο RDBMS αλλά να δικαιολογούμε την έλλειψη ενός feature σε ένα RDBMS επειδή κάτι παρόμοιο υπάρχει σε κάποια γλώσσα προγραμματισμού δεν ευσταθεί ως επιχείρημα.

---

Vir prudens non contra ventum mingit