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

Απ: Περι Triggers...

Thiseas — Wed, 15 Aug 2007 09:10:52 GMT

Γιώργο θα έλεγα οτι δεν έπεσες καθόλου έξω.... για να μην πω οτι ίσως έχουμε συναντηθεί και κάπου και δε το ξέρεις.... (σε πειράζω... αλλά ποτέ δεν ξέρεις...)

Απ: Περι Triggers...

George J. Capnias — Wed, 15 Aug 2007 08:34:32 GMT

Thiseas:
Χμ... γίνεται με 2 προγράμματα: ...

Xμ, ένα μήνυμα που δεν το είδα, παρά όταν έκανα post... . Δεν έπεσα και πολύ έξω, ε;

George J.

Απ: Περι Triggers...

George J. Capnias — Wed, 15 Aug 2007 08:32:21 GMT

sakalis:
Και να ρωτήσω εγώ η επικοινωνία της ασύρματης συσκευής με τον database server πως γίνεται?

Γιώργο, με όποιον τρόπο και να γίνεται η επικοινωνία, δεν αλλάζουν κάποια πράγματα:

Είναι ασύρματη, οπότε μιλάμε κάτι μεταξύ WiFi, Infrared και Bluetooth ή έστω και RF. Όλα τα προηγούμενες συνδέσεις μπορούν και συμμετέχουν σε δίκτυο TCP/IP. Ο τρόπος της επικοινωνίας είναι το TCP/IP.
Η ασύρματη σύνδεση, έχει μεταβλητό βαθμό διαθεσιμότητας και ποιότητας, ανάλογα με την θέση του mobile client, τις παρεμβολές που δέχεται, την κατάσταση της μπαταρίας του mobile client, μέχρι και το "κακό κάρμα" , του χειριστή που την κρατάει! Η σύνδεση μπορεί για πολλούς λόγους είναι αναξιόπιστη, και καλό θα ήταν να μπορεί ο mobile client να παίζει και σε off-line mode - να μην απαιτείται να είναι live όλη την ώρα η σύνδεσή του με τον database server για να μπορεί κάποιος να χειρίζεται την εφαρμογή.

Έχεις κάποιο λόγο να ενδιαφέρεσαι πως πραγματικά επικοινωνεί το mobile client με το database server για την καλύτερη απόδοση της εφαρμογής;

George J.

Απ: Περι Triggers...

Thiseas — Wed, 15 Aug 2007 08:17:14 GMT

Χμ... γίνεται με 2 προγράμματα:
Έναν client-sofware έναν server-sofware και τα 2 γραμμένα από εμάς σε Delphi (θα τα αλλάξουμε όμως γιατι γυρνάμε σιγά σιγά όλη την εφαρμογή προς C#, .Net και αυτό το κομμάτι θα γίνει με το mobile edition... τεσπα).
Προς το παρών ο client-sofware που είναι στο RF (το οποίο έχει DOS ή Windows) επικοινωνεί με τον server-software που ειναι εγκατεστημένος συνήθως στο database server και αυτός με τη σειρά του καλεί Store Procedures.... xοντρικά xοντρικά - επέτρεψε μου να μην αναφέρθώ σε λεπτομέριες για ευνοήτους λόγους.

Σε έναν server μπορουν να κάνουνε connect N RF-Terminals.
H Αρχιτεκτονική είναι απλή και γρήγορη και δεν είναι και τίποτα σπουδαίο, πέρα του γεγονότος οτι το ελέγχουμε κατά το 99% διότι είναι φτιαγμένο από εμάς.
Ο client είναι text mode (άλλοστε τυγχάνει χειρισμού από εργάτες παραγωγής που δεν έχουν μεγάλες απαιτήσεις και ουτε θελουν πολλά πολλά...) και η επικοινωνία γίνεται σε συγκεκριμένη πόρτα που την ορίζεις μέσα από την εφαρμογή μας... αυτά /

Απ: Περι Triggers...

sakalis — Wed, 15 Aug 2007 07:24:50 GMT

Και να ρωτήσω εγώ η επικοινωνία της ασύρματης συσκευής με τον database server πως γίνεται?

Απ: Περι Triggers...

Thiseas — Wed, 15 Aug 2007 07:10:22 GMT

Δεν θα ήθελα να σε διορθώσω στην πολύ καλή ανάλυση σου γιατί οι διορθώσεις μου θα ήταν στο να τοποθετήσω τα πράγματα λίγο πιο κοντά σε αυτό που αντιμετωπίζουμε σαν πραγματικότητα αλλά πολύ λίγο θα άλλαζε το περιέχομενο των συμπερασμάτων σου και στην ουσία θα έμοιαζε σαν μια διόρθωση απλά για να πω κάτι.... πράγμα που δεν χρειάζετε!!

Απλά θα ήθελα να συμπληρώσω λίγα παρακάτω:

1. Ένα δίκτυο αναφέρεται ως προβληματικό είτε γιατί είναι... προβληματικό, είτε γιατι ο φόρτος μια δεδομένη στιγμή (peak) πολλές φορές το κάνει προβληματικό.

2. Οι κινήσεις (transactions) γίνονται είτε ενσύρματα είτε ασύρματα (μέσω remote frequency terminals με κατάλληλο software). Η πολύ σωστή σου προσέγγιση που την αναφέρεις σαν (near real time) πραγματικά ανταποκρίνεται 100% στην πραγματικότητα: Υπάρχουν στιγμές που ορισμένα πράγματα πρέπει να γίνουν σε πραγματικό χρόνο asap.

3. Η απαιτήσεις του πελάτη είναι τέτοιες ώστε να ζητά σε χρόνο ελάχιστο (π.χ. σε ένα Σαββατοκύριακο) αλλαγές αλλά και νέες δυνατότητες οι οποίες αν έπρεπε να συντηρηθούν από μια εφαρμογή θα ήταν αδύνατον από πλευράς χρόνου... (βλέπε versioning control, compiling στον κώδικα, executables, κλπ κλπ) και σκεφτείτε οτι τα παραπάνω αναφέρονται σε έναν μόνο πελάτη.... Στην πραγματικότητα οι πελάτες είναι πολλοί (σε όλη την Ελλάδα) και φυσικά η εφαρμογή που τους υποστηρίζει είναι (και πρέπει να είναι).... μία!

Πιστεύω πως η λύση των Stored Procedures και η κλήση τους από ένα "έξυπνο" interface από την εφαρμογή μας.... ειναι μονόδρομος.
Αυτή είναι η "Μαυρίλα" αλλά και η ομορφία των custom made εφαρμογών... και των προγραμματιστών τους....

Απ: Περι Triggers...

George J. Capnias — Wed, 15 Aug 2007 06:24:45 GMT

Thiseas:
Αλλά σκέψου και πιο λογικά,... και σε ρωτώ να μου απαντήσεις (αν θες βέβαια).
Σκέψου το παραπάνω constraint να κλειθεί από έναν client.

θα πρέπει:
1. Να ανοίξεις transaction (start trans)
2. Να κάνεις το update 1
3. Να κάνεις το update 2
4. Να κλείσεις το transaction (commit)

Σκέψου οτι σε ένα δίκτυο με κινήσεις εκατοντάδων "πακέτων" το λεπτό τα παραπάνω 4 βήματα θα εκτελεστούν σειριακά και με διαφορετικές κλήσεις στον server.
Πιστεύεις οτι το παραπάνω είναι πιο γρήγορο από να constrain στον πίνακα ή ένα trigger που θα εκτελεστεί όλο στον server επειδή έτσι λέει η βιβλιογραφία?

Τα βήματα δεν είναι ανάγκη να γίνουν από τον client. Κάνω ένα λογικό συνειρμό και όπου κάνω λάθος με διορθώνεις - δεν ξέρω τι ακριβώς έχεις στο μυαλό σου ή προσπαθείς να περιγράψεις:

Περιγράφεις για ένα σύστημα server/client με πολλούς clients επάνω σε ένα «φορτωμένο» ή «αργό» δίκτυο
Να υποθέσω ακόμα ότι το σύστημα είναι «near real time», οπότε το perfomance του είναι το πρώτο μέλημα
Δεν μπορεί κανείς να εγγυηθεί για τίποτα, εκτός από εσένα, το προγραμματιστή, που μπορείς να υποσχεθείς ότι η εφαρμογή σου θα κάνει ότι καλύτερο δυνατό για να ανταπεξέλθει στον σκοπό της
Λογικό συμπέρασμα είναι, να είναι θεμιτό να μεταφερθούν όσο λιγότερα δεδομένα επάνω από το δίκτυο και όσο πιο γρήγορα, λόγω του «προβληματικού» δικτύου
Κανείς θα ήθελε μια τέτοια εφαρμογή να έχει πολλά tiers γιατί θα ήταν πιο αργή, και θα είχαμε προβλήματα επικοινωνίας μεταξύ των tiers μιας και το δίκτυο είναι προβληματικό.
Λογικά η εφαρμογή έχει ένα τμήμα business intelligence, που παίρνει αποφάσεις της εφαρμογής. Αυτό που χρειάζεται είναι το business intelligence να είναι όσο πιο «κοντά» στη βάση δεδομένων σου, ώστε να ελαχιστοποιηθούν οι χρόνοι που θα απαιτηθούν να «διαβάζονται» τα δεδομένα για τις αποφάσεις του, αλλά και να «γράφονται» τα αποτελέσματα από τις αποφάσεις πίσω στην βάση δεδομένων.
Μια ακόμα σκέψη είναι αφού μιλάμε για μια «near real time» εφαρμογή, τα δεδομένα δεν πρέπει να «κλειδώνονται» από ένα client, αλλά θα πρέπει να υπάρχει η μέγιστη διαθεσιμότητά τους σε όλους τους clients. Οπότε οι χρόνοι μεταφοράς είναι critical να είναι οι ελάχιστοι δυνατοί
Δεν θα ήθελα τα transactions να ξεκινάνε από τους clients και να μεταφέρονται επάνω από το δίκτυο – θα ήθελα να είχα ένα τρόπο που ο client θα έκανε initiate το transaction, θα εκτελούταν εξ’ ολοκλήρου στο server και ο client θα έπαιρνε πίσω ένα αποτέλεσμα Boolean μορφής – ολοκληρώθηκε επιτυχημένα/δεν ολοκληρώθηκε.
Έτσι όπως το βλέπω εγώ δεν θα ήθελα το business intelligence να είναι μέσα στην client εφαρμογή. Είναι μεγάλο ρίσκο, και αν αποτύχω, αποτυγχάνει και η εφαρμογή μου. Θα πρέπει να επικοινωνεί η εφαρμογή μου με κάποιο μηχανισμό με το server ώστε να μεταφέρει τα ελάχιστα δεδομένα που απαιτούνται ώστε να κάνουν initiate το transaction στον server. Σαν υποψήφιους μηχανισμούς σκέφτομαι Web Services, DCOM/Enterprise components και store procedures μέσα στην βάση.
Τα Web services και το DCOM/Enterprise components νομίζω ότι εύκολα θα τα απορρίπτονται από κάποιον λόγω του όγκου των δεδομένων που χρειάζονται να μεταφέρουν επάνω από το δίκτυο.
Τα store procedures από την άλλη μεριά φαίνεται να είναι ο ιδανικός υποψήφιος για να μπορέσει κάποιος να υλοποιήσει το business intelligence της εφαρμογής – αδιαμφισβήτητα θα είναι τα πιο αξιόπιστα από όλους τους άλλους μηχανισμούς ώστε να φέρουν σε πέρας επιτυχημένα την αποστολή τους μιας και δεν επηρεάζεται η απόδοση τους από το «προβληματικό» δίκτυο. Και να χάσει ο client την επικοινωνία με τον server, δεν θα επηρεαστεί το transaction.
Ένας τρόπος να ξεπεραστεί αυτό το πρόβλημα της απώλειας σύνδεσης με το server κατά την διάρκεια του tranaction και να έχουμε καλύτερα αποτελέσματα στις επιδώσεις της εφαρμογής, θα ήταν να είναι ασύγχρονα τα initiations των transactions με την λήψη των αποτελεσμάτων, ώστε να μην υπάρχει η ανάγκη να μείνουν οι συνδέσεις μέσω δικτύου ανοιχτές για πολύ ώρα.

Thiseas:
[edited: sorry... Γιώργο ... αλλά είδα την απάντηση σου αφού πάτησα save στο post μου... και δεν θα ήθελα να το σβήσω... ]

George J.

Απ: Περι Triggers...

Thiseas — Wed, 15 Aug 2007 04:59:40 GMT

Δεν συνηθίζω να κριτικές προς άτομα που δεν γνωρίζω και ιδιαίτερα να κάνω σε άλλους πράγματα που με ενοχλούν όταν μου τα κάνουνε.
Αναφερόμενος σε "εφαρμογές της πλάκας" φυσικά και δεν εννοώ αυτές που φτιάχνεις εσύ προσωπικά μιας που δεν τις έχω δει και βέβαια ούτε που σε γνωρίζω!

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

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

Όπως είπα οι λόγοι είναι πάρα πολλοί:
- Performance
- Security
- Maintenance

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

Για να έρθω σε αυτό που έλεγα πριν, ο κόσμος είναι γεμάτος crepping projects... ποιος μου εγγυάται εμένα οτι μια υπέροχη αναφορά στην υλοποίηση ενός project που έγινε με την μεθοδολογία που υποστηρίζεις είναι και η βέλτιστη δυνατή?
Ποιός μου λέει εμένα οτι αυτός που την ανέπτυξε είχε ακριβώς την δική σου νοοτροπία και ακολούθησε την δεδομένη μεθοδολογία με κλειστά μάτια...
Όταν ο πελάτης μου εμένα μου πει "ο χρόνος είναι για μένα unaccpetable" και κινδυνεύσω να χάσω ένα έστω και μικρό budjet των 20000 euro, γιατί να το χάσω αν βλέπω οτι με την ίδια υλοποίηση με SP το perfomance βελτιώνετε... εκθετικα?
Να πάω δηλαδή σε όλους τους κ.κ. συγγραφείς των βιβλίων που επαγγέλονται την μη χρήση των stored procedures και τους ζητήσω να λεφτα που δεν κέρδισα από τα χαμένα projects,... ?? (ok... υπερβολή... αλλά νομίζω το "έπιασες" αυτό που θέλω να πω).

Επανέρχομαι, λοιπόν, στο αρχικό μου ερώτημα.
Ποιός θα μου πεί τι είναι ποιο γρήγορο (μιας που μιλάμε για perfomance) ?

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

Αλλά σκέψου και πιο λογικά,... και σε ρωτώ να μου απαντήσεις (αν θες βέβαια).
Σκέψου το παραπάνω constraint να κλειθεί από έναν client.

θα πρέπει:
1. Να ανοίξεις transaction (start trans)
2. Να κάνεις το update 1
3. Να κάνεις το update 2
4. Να κλείσεις το transaction (commit)

Σκέψου οτι σε ένα δίκτυο με κινήσεις εκατοντάδων "πακέτων" το λεπτό τα παραπάνω 4 βήματα θα εκτελεστούν σειριακά και με διαφορετικές κλήσεις στον server.
Πιστεύεις οτι το παραπάνω είναι πιο γρήγορο από να constrain στον πίνακα ή ένα trigger που θα εκτελεστεί όλο στον server επειδή έτσι λέει η βιβλιογραφία?

[edited: sorry... Γιώργο ... αλλά είδα την απάντηση σου αφού πάτησα save στο post μου... και δεν θα ήθελα να το σβήσω... ]

Απ: Περι Triggers...

George J. Capnias — Wed, 15 Aug 2007 04:57:36 GMT

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

@sakalis & Thiseas
Νομίζω ότι το θέμα του thread εξαντλήθηκε, και πλέον η "διαφωνία" σας είναι "εκτός θέματος"! . Θα πρότεινα και στους δύο αν θέλετε να συνεχίσετε την συζήτηση σε αυτό το θέμα να το κάνετε στο νέο thread: http://www.dotnetzone.gr/cs/forums/thread/34322.aspx

George J.

Απ: Περι Triggers...

sakalis — Wed, 15 Aug 2007 03:43:09 GMT

Καταρχήν δεν ανέβασα κανένα τόνο. Αυτά που είπα ήταν πολύ ήρεμα. Δεν προσέβαλα κανένα και λυπάμαι αν εσύ τα πήρες προσωπικα.

Καταρχήν για το 2. Δεν έχω τίποτα με τους σερβιτόρους. Ισα ίσα που όταν είναι καλοί σε αυτό που κάνουν τους εκτιμώ ιδιαίτερα. Αυτό που δεν εκτιμώ είναι τους επαγγελματίες στο χώρο που όσο junior και να είναι, δεν ξέρουν τα στοιχειώδη για τις σχεσιακές βάσεις δεδομένων (βλέπε foreign keys). Αν και εσύ άνηκες σε αυτή την κατηγορία, λυπάμαι που το πήρες προσωπικά, δε σκόπευα κάτι τέτοιο.

Για το 3 έχεις δίκιο δεν το δικαιολόγησα αρκετά. Ωστόσο μία γρήγορη εύρευνα τόσο εδώ όσο και σε sites με πρακτικές καθώς και στη σύγχρονη βιβλιογραφία ίσως σε πείσει. Δεν μπορεί όλη η βιομηχανία και το μεγαλύτερο μέρος της αγοράς πληροφορικής να υποστηρίζει ότι το business logic καλό είναι να μη περιέχεται σε SP. Δεν είμαι κατά των SP, αλλά κατά των σύνθετων SP όπου υλοποιείς όλο ο business Logic. Αυτό δε σημαίνει βέβαια ότι δεν υπάρχουν και εξαιρέσεις

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

Απ: Περι Triggers...

Thiseas — Wed, 15 Aug 2007 01:44:34 GMT

Φίλε μου τραβάς κανα ζόρι με τους σερβιτόρους?
Τεσπα....
Δεν θα σχολιάσω παραπάνω το ύφος της απάντησης... για το 2. Όταν θα γίνεις manager εσύ, να τους στέλνεις να γίνονται σερβιτόροι!!!

Για το 3 τώρα, το να πιστεύεις αυτά που πιστεύεις περί Ap Servers και performance σε σχέση με St Procs... τι να πω... δικαίωμα σου, άλλοστε εφαρμογές τις πλάκας υπάρχουνε πολλές! Ειδικά με το να επιχειρηματολογείς λέγοντας "Σήμερα η τάση είναι...", σαν να είναι ας πούμε της μόδας, αν μη τι άλλο δεν με πείθεις. Φυσικά ίσως δεν σε ενδιαφέρει να με πείσεις... απλά στο λέω μιας και έκανες τον κόπο και ασχολήθηκες με το post μου.
Το αν κάνω μεγάλο λάθος ή όχι, να μου επιτρέψεις να μην σε αφήσω να το αναφέρεις αναπάντητο:
Η δική μου η εμπειρία δεν βασίζεται σε... "τάσεις", αλλά σε πραγματικές εφαρμογές σε εταιρίες (Logistics / WMS - όχι 1 ή 2 αλλά πολύ περισσότερες από 10) που διαχειρίζονται αρκετές χιλάδες transaction ανά ημέρα.
Αν εσύ πιστεύεις οτι δεν πρέπει να χρησιμοποιείς St.Proc επειδή ο Server δεν χρησιμοποιείται για αυτό που κάνει καλύτερα... και φορτώνεις τη λογική σου σε App.Servers και παραπάνω layers!!... τότε μάλλον το μεγάλο λάθος δεν βρίσκεται σε εμένα!

PS: Θα εκτιμούσα επίσης αν κατέβαζες λίγο τους τόνους στις επόμενες απαντήσεις σου- αν υπάρξουν,... διαφορετικά άστο διότι δεν πρόκειται να ξανασχοληθώ γιατί δεν υπάρχει και λόγος.
Απλά χάνεται το νόημα του forum να ανεβάζουμε τους τόνους χωρίς κανέναν απολύτως λόγο.

Απ: Περι Triggers...

sakalis — Tue, 14 Aug 2007 23:58:34 GMT

Θα σχολιάσω τα 2 τελευταία.

2. Αν δε γνωρίζει τι είναι τα Foreign keys καλύτερα να γίνει σερβιτόρος στην ταβέρνα της γειτονιάς του. Αλήθεια σε ποια σχολή πέρασε το μάθημα βάσης δεδομένων????

3. Δηλαδή αν έχεις το business logic σε εναν application server και χρησιμοποιείς την database μόνο για crud πέφτει το perfomance, από το να υλοποιείς τα πάντα με Stored procedures στον database server?Κάνεις μεγάλο λάθος. Σήμερα η τάση είναι να χρησιμοποιώ τον Database server μονο για αυτό που κάνει καλύτερα, να διαχειρίζεται δεδομένα, ενώ τα υπόλοιπα ανεβαίνουν επίπεδο, και υλοποιούνται στο business layer.

Απ: Περι Triggers...

Thiseas — Tue, 14 Aug 2007 23:48:19 GMT

Παναγιώτης Καναβός:

Γιατί κάνεις join με τον Inserted? Άσε που το join με τον inserted, δεν περιλαμβάνει τον inserted. Αφού θέλεις να αλλάξεις τις εγγραφές που έχουν την παλιά τιμή, αρκεί το join με τον deleted.

Σχετικά με το τί είναι πιο εύκολο για ένα νέο προγραμματιστή, τί πιστεύεις? Ότι θα κοιτάξει ποιά foreign keys υπάρχουν στη βάση, ή ότι θα φανταστεί ότι μπορεί να χρησιμοποιούνται triggers? Και γιατί triggers, και να μην είναι όλος ο κώδικας στην εφαρμογή?

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

Ωχ.... πολύ όμορφη κουβέντα αλλά μου έβαλες πολλά θέματα μαζί χε χε.... ...

Λοιπόν...

1ον. Κάνω Join με το Inserted γιατί απλά θέλω την τιμή i.ProductID για να την βάλω στον άλλο πίνακα... πώς αλλιώς να το κάνω... δεν νομίζω οτι γίνεται!!

2ον. Πιστεύω οτι ένας προγραμματιστής δεν θα φανταστεί καν αν έχουν οριστεί foreign keys στη βάση (και πολλές φορές δεν γνωρίζει τι σημαίνει αυτό!! - πίστεψέ με!!)

3ον. Ποτέ στην εφαρμογή τέτοιος κώδικας... για πάρα πολλούς λόγους! Ένας από αυτούς είναι το Performance.

Απ: Περι Triggers...

Παναγιώτης Καναβός — Tue, 14 Aug 2007 22:16:49 GMT

Γιατί κάνεις join με τον Inserted? Άσε που το join με τον inserted, δεν περιλαμβάνει τον inserted. Αφού θέλεις να αλλάξεις τις εγγραφές που έχουν την παλιά τιμή, αρκεί το join με τον deleted.

Σχετικά με το τί είναι πιο εύκολο για ένα νέο προγραμματιστή, τί πιστεύεις? Ότι θα κοιτάξει ποιά foreign keys υπάρχουν στη βάση, ή ότι θα φανταστεί ότι μπορεί να χρησιμοποιούνται triggers? Και γιατί triggers, και να μην είναι όλος ο κώδικας στην εφαρμογή?

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

Απ: Περι Triggers...

Thiseas — Tue, 14 Aug 2007 21:46:59 GMT

O λόγος οτι θέλω να αποφύγω κάτι τέτοιο είναι λίγο πιο.... πεζός...

Έχω ένα έργο του οποίου η Βαση δεν έχει καθλολου constrains τέτοιου τύπου.
Ότι constrain υπάρχει ειναι μέσα σε triggers,... και η διαδικασία να αλλάξω αυτη τη λογική απλά "σκοντάφτει" σε κάποια γραφειοκρατικά θέματα που θα με καθυστερήσουν.

Επέτρεψε μου να διαφωνήσω στο οτι η αλλαγή της τιμής μέσω trigger είναι περισσότερο "Cryptic" απ' οτι η αλλαγή μέσω Cascade, εδικά για κάποιον άπειρο programmer....

Για το deleted:
Κάνοντας ακόμα ένα join με το deleted... πρέπει νομίζω να τα "σπάσεις" τα updates.... κάτι σαν το παρακάτω:

ALTER TRIGGER Products_TestTrigger ON [dbo].[Products]
FOR UPDATE
AS

if UPDATE(RetailPrice)

begin

UPDATE Products_Extention

SET WholePrice = i.RetailPrice - (i.RetailPrice * 0.15)

FROM Products_Extention pe

INNER JOIN inserted i ON i.ProductID = pe.ProductID
end

if UPDATE(ProductID)

begin

UPDATE Products_Extention

SET ProductID = i.ProductID,

FROM Products_Extention pe

INNER JOIN deleted d ON d.ProductID = pe.ProductID

INNER JOIN inserted i ON d.ProductID = pe.ProductID
end

το οποίο "παίζει" μόνο όταν κάνω Update 1 row τη φορά!!
Αν προσέξεις το inserted γίνεται joined με κλειδί το d.ProductID από το deleted για αυτό και παίζει για 1 row, επειδή η συνθήκη join του inserted επιστρέφει TRUE και εκείνη τη στιγμή στον inserted πίνακα η μόνη εγγραφή που υπάρχει είναι αυτή που θέλω - χε χε!!

Νομίζω οτι γίνεται μόνο με την προσέγγιση του cascade... τελικά!