SQL Server (και άλλες databases)

Απ: MySQL 5.0

KelMan — Tue, 06 Dec 2005 01:20:36 GMT

Dimitris wrote:

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

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

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

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

Απ: MySQL 5.0

objectref — Mon, 05 Dec 2005 21:42:58 GMT

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

Απ: MySQL 5.0

Παναγιώτης Καναβός — Mon, 05 Dec 2005 21:42:34 GMT

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!

Απ: MySQL 5.0

Dimitris — Mon, 05 Dec 2005 21:06:59 GMT

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

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

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

Απ: MySQL 5.0

Παναγιώτης Καναβός — Mon, 05 Dec 2005 19:20:32 GMT

Ο έλεγχος εγκυρότητας δεν είναι μια μονοκόμματη διαδικασία που πρέπει να γίνει μόνο στο middle-tier ή μόνο στη βάση. Διαφορετικά πράγματα ελέγχονται στη βάση και διαφορετικά πράγματα στο middle-tier. Η ουσία είναι ότι τα δεδομένα στη βάση πρέπει να είναι σωστά, ανεξάρτητα από το ποιά εφαρμογή τα έγραψε στη βάση. Δεν θα πρέπει σε καμμία περίπτωση π.χ. να υπάρχει αρνητική τιμή για ένα προϊόν, ή παραγγελία με ανύπαρκτο κωδικό πελάτη, όποιος και να προσπαθήσει να τις γράψει.
Αυτοί οι έλεγχοι μπορούν να γίνουν εύκολα και γρήγορα στη βάση, χωρίς σημαντικό κόστος. Αν όμως πας να τους κάνεις στο middle tier θα πρέπει να εκτελέσεις πολλά διαφορετικά queries και να τραβήξεις δεδομένα από τη βάση στο middle tier. Άσε που το middle tier δένεται άσχημα με το σχήμα της βάσης.

Από εκεί και πέρα, ο έλεγχος εγκυρότητας μιας πιστωτικής ή του ΑΦΜ μπορεί να μπει στη βάση, μπορεί και όχι. Εξαρτάται από το είδος της εφαρμογής που φτιάχνεις.

Απ: MySQL 5.0

KelMan — Mon, 05 Dec 2005 19:17:59 GMT

Κάθε RDBMS που σέβεται τον εαυτό του έχει τέσσερα βασικά χαρακτηριστικά, γνωστά ως ACID properties: Atomicity, Consistency, Isolation & Durability.

To δεύτερο χαρακτηριστικό είναι ακριβώς αυτό. Το να περιέχει πάντοτε η ΒΔ έγκυρα δεδομένα, η λογική ορθότητα των δεδομένων. Επειδή όμως υπάρχουν πολλοί τρόποι να μπουν ή να αλλάξουν αυτά τα δεδομένα, δεν μπορεί η ευθύνη της εγκυρότητας να περάσει αποκλειστικά στον client. Πρέπει να γίνεται σε δύο επίπεδα, στον client, όποτε αυτός υπάρχει, και στη database. Όταν ξεφεύγει κάτι από το client, τότε το RDBMS θα του επιστρέφει λάθος και ο client θα ενεργεί ανάλογα.

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

Πάντως, σχετικά με αυτό που έλεγε προηγουμένως ο Παναγιώτης, όντως, όταν ένα προϊόν απευθύνεται σε business εφαρμογές από κει και πέρα θα πρέπει να κρίνεται αυστηρά και προσωπική μου άποψη είναι ότι το γεγονός ότι είναι free/open source/etc δεν αποτελεί ελαφρυντικό. Γιατί αν κληθώ να υλοποιήσω ένα σύστημα με αυτό το προϊόν θα πρέπει να αντιμετωπίσω προβλήματα που κανονικά δεν θα έπρεπε να υπάρχουν. Πιστεύω ότι το θέμα του κόστους είναι ένας εντελώς διαφορετικός παράγοντας που απασχολεί τη μελέτη κόστους και το TCO και δεν θα πρέπει να συνυπολογίζεται στο τεχνικό κομμάτι του προϊόντος. Βάζουμε τα specs και αν μας κάνει, κατόπιν εξετάζουμε το κόστος.

Απ: MySQL 5.0

Dimitris — Mon, 05 Dec 2005 18:53:51 GMT

πως θα αισθανόσουν πχ, αν έκανες μια καταχώρηση παραγγελίας και "δεν έμπαινε" ή "έμπαινε λάθος" η διεύθυνση του χρήστη ή ο αριθμός της πιστωτικής του κάρτας;

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

Απ: MySQL 5.0

Παναγιώτης Καναβός — Mon, 05 Dec 2005 18:40:38 GMT

Μου έχει τύχει παρόμοια κατάσταση και δεν την χάρηκα καθόλου. Είχα παραγγείλει πληκτρολόγιο για το PDA μου από ένα αγγλικο e-shop, είχα πάρει την επιβεβαίωση με email και περίμενα. Και περίμενα. Όταν πέρασαν μερικοί μήνες και βαρέθηκα να τους περιμένω, τους στέλνω ένα email και διαπιστώνω ότι ... η παραγγελία είχε χαθεί! Δεν υπήρχε καν στη βάση! ΈΤσι και αυτοί χάσανε τα χρήματα της παραγγελίας μου και εμένα σαν πελάτη, γιατί φυσικά δεν ξαναπάτησα!
Κάτι τέτοιο είναι πανεύκολο να συμβεί αν η βάση η ίδια πάσχει σε data-integrity. Είναι διαολεμένα δύσκολο να αντιμετωπίσεις την έλλειψη data integrity στο business layer.

Όσο για την κριτική του MySQL ... γιατί όχι? Όταν η ίδια η εταιρεία καμαρώνει, όταν υπάρχουν άλλες open-source βάσεις χωρίς αυτά τα προβλήματα, γιατί να μην κρίνω το προϊόν όπως όλα τα άλλα? Business προϊόν δεν είναι, ή λέει ότι είναι?

Απ: MySQL 5.0

George J. Capnias — Sun, 04 Dec 2005 23:40:50 GMT

Δεν νομίζω ότι κάποιος υποτιμά την MySQL. Η απάντηση του Παναγιώτη νομίζω ότι είναι η πραγματικότητα. Υπάρχουν πράγματα που η MySQL είναι καλύτερη από άλλες βάσεις. Αλλά όταν έρχεσαι και κάνεις σύγκριση στην MySQL με άλλες βάσεις δεδομένων, το πρώτο πράγμα που σε κάνει να αναρωτιέσαι είναι γιατί δεν έχει views και store procedures που τόσο θα προσδώσει αξία στο προϊόν.

Η έκδοση 5, αναμενόταν να αλλάξει το status αυτό. Αλλά με αυτά που λέει το άρθρο του Alex Papadimoulis, και στο link που παρέθεσες εσύ - οι εκδόσεις 3.x/4.x δεχόντουσαν να βάλουν δεδομένα στην βάση έστω και αν ήταν λάθος, αλλά τώρα στην έκδοση 5.x δεν θα μπαίνουν τα λάθος, αλλά όλα τα άλλα δεδομένα που είναι σωστά στο ίδιο record - πως θα αισθανόσουν πχ, αν έκανες μια καταχώρηση παραγγελίας και "δεν έμπαινε" ή "έμπαινε λάθος" η διεύθυνση του χρήστη ή ο αριθμός της πιστωτικής του κάρτας; Δεν θα ήταν άχρηστη η πληροφορία που θα καταγραφεί στην Β.Δ.; Δεν θα ήταν προτιμότερο να σκάσει κατά την εκτέλεση του query και να ξέρεις ότι δεν μπήκε και να το αντιμετωπίσεις αυτό από το πρόγραμμά σου;

George J.

Απ: MySQL 5.0

Dimitris — Sat, 03 Dec 2005 20:14:25 GMT

Νομίζω οτι κρίνετε πολύ αυστηρά την MySQL και μάλλον υποτιμάτε τις δυνατότητές της. Δεν έχω κατεβάσει ακόμα την 5 αλλά θα ήθελα να δοκιμάσω και ο ίδιος τα ευρήματα του παραπάνω άρθρου ("MySQL 5.0: Still A "Toy" RDBMS").

Guaranteeing Data Integrity with MySQL 5.0
http://dev.mysql.com/tech-resources/articles/mysql-data-integrity.html

Απ: MySQL 5.0

objectref — Wed, 30 Nov 2005 20:13:23 GMT

Γενικα παντως υπαρχουν "μπερδεμενες εννοιες" στις μερες μας...
Καποιος π.χ. παλαιος DBA, ακουει πλεον για κωδικα εκτος T-SQL που τρεχει στην βαση (clr integration), ακουει για transactional mode σε κωδικα εκτος T-SQL που τρεχει στον client (http://msdn.microsoft.com/msdnmag/issues/05/12/transactions/default.aspx ενα παρα πολυ ωραιο αρθρο για οποιον ενδιαφερεται), οποτε αρχιζει και σε κοιταζει περιεργα...

Απ: MySQL 5.0

Παναγιώτης Καναβός — Wed, 30 Nov 2005 19:59:46 GMT

Ή ίσως επειδή η MySQL είναι εταιρεία και μπορεί να κάνει διαφήμιση, ενώ η Postgres όχι. Έχω ακούσει γνωστούς να λένε ότι θα προτιμούσαν να χρησιμοποιήσουν Postgres αντί για MySQL αλλά ο πελάτης ζήταγε MySQL.

Διαβάζοντας πάντως και τα σχόλια στο DailyWTF διαπιστώνει κανείς ότι αυτοί που υποστηρίζουν τον MySQL δεν ξέρουν και πολλά πράγματα από βάσεις, ενώ άλλοι μπλέκουν business rules με data integrity rules.
Εδώ που τα λέμε, δεν φταίνε και τόσο οι άνθρωποι, γιατί στον χώρο των βάσεων τα data integrity rules αναφέρονται σαν business rules εδώ και 20+ χρόνια. Η ιδέα των business rules με τη σημερινή έννοια (πολύ πιο περίπλοκα, σε πιο abstract επίπεδο, εύκολα τροποποιήσιμα) είναι πολύ πιο πρόσφατη. Λογικό λοιπόν είναι να να μπερδέψει κανείς τις έννοιες αν ασχολείται περιστασιακά μόνο με βάσεις.

Απ: MySQL 5.0

objectref — Wed, 30 Nov 2005 19:44:43 GMT

Γιατι δυστυχως, γινεται "τοση φασαρια" με οτιδηποτε ειναι anti-Microsoft...Βλεπεις, υπαρχει μια μανια με μερικους στο παγκοσμιο Industry να δινουν εμφαση σε προιοντα εκτος MS (ειδεικα σε open source λυσεις) αν και τις περισσοτερες φορες αυτα ειναι σαφως κατωτερα...

Πιστευω οτι στη Microsoft εχουν αλλαξει πολλα πραγματα για εμας (προς το καλυτερο). Εκανε πολυ μεγαλη κινηση με το να δωσει full functional products χωρις να τα χρεωνει, αυτη τη στιγμη, καποιος με C#/Web/Sql (ολα στις Express Editions) μπορει να καλυψει απο personal αναγκες μεχρι και μιας μικρης εταιρειας χωρις να πληρωσει δραχμη και (το κυριοτερο) με πολυ καλο αποτελεσμα...

Απ: MySQL 5.0

Παναγιώτης Καναβός — Wed, 30 Nov 2005 07:51:59 GMT

Τί έκανε λέει? Δεν έχει data integrity? Δεν παίζουν τα constraints? Δεν μπορείς να κάνεις rollback σε trigger? Ε τότε τί τα φτιάξανε?

Μα καλά, γιατί γίνεται τόση φασαρία με το MySQL όταν η Postgres είναι καλύτερη?

Απ: MySQL 5.0

George J. Capnias — Wed, 30 Nov 2005 01:34:03 GMT

Μια δημοσίευση έχει κάνει για τον MySQL 5.0 και ο Alex Papadimoulis. Αν και η θέση του είναι λίγο ακραία "MySQL 5.0: Still A "Toy" RDBMS", μπορεί κάποιος να διαβάσει τα ευρήματα του Papadimoulis για τον MySQL 5.0 και τα σχόλια που έχουν γίνει σε αυτή του την δημοοσίευση.

George J.