Έχω το παρακάτω trigger που όταν αλλάζει το ID ή η λιανική τιμή του πίνακα (Products), ενημερώνετε και το ID και η χονδρική τιμή ενός άλλου (Products_Extention).

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

if UPDATE(ProductID) or UPDATE(RetailPrice)

begin

    UPDATE  Products_Extention

    SET     ProductID = i.ProductID,

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

    FROM    Products_Extention pe

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

Το παραπάνω trigger δεν θα δουλέψει σωστά διότι το i.ProductID δεν είναι ίσο με το pe.ProductID αν αλλάξει κάποιος το ProductID.
Πώς θα το κάνω να δουλέψει σωστά με το σκεπτικό οτι μπορεί να γίνεται και μαζικό Update των γραμμών του πίνακα Products (πχ. Update Products set ProductID = ProductID+1) γνωρίζωντας οτι δεν θα πέσουμε σε duplicate key γιατί (ας πούμε) οτι τα IDs αυξάνονται κατά 10.

PS: Το ξέρω οτι το παράδειγμα ίσως δεν είναι πρότυπο σωστής ανάλυσης (να αλλάζουν τα IDs σαν τα... "πουκάμισα") ... αλλά ας πούμε οτι είμαστε υποχρεωμένοι να το κάνουμε,...

---

Nothing to declare...

Αντί για trigger θα μπορούσες να ορίσεις ένα foreign key μεταξύ των ProductID πεδίων των δύο πινάκων με cascade update. Έτσι κάθε αλλαγή στο ProductID του ενός πίνακα θα περάσει αυτόματα στο ProductID του άλλου.

---

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

Παναγιώτη σ' ευχαριστώ για την γρήγορη απόκριση,... απλά αναρωτιώμουνα αν μπορεί να λυθεί το πρόβλημα με τέτοιο trigger...

Δηλαδή να αποφύγω κάτι τέτοιο:

ALTER TABLE Products ADD CONSTRAINT FK_Products
  FOREIGN KEY(ProductID_Ext)
  REFERENCES Products_Extention(ProductID)
  ON DELETE CASCADE
  ON UPDATE CASCADE

 

To οποίο (απ' οτι κατάλαβα) θεωρείς οτι είναι το πιο σωστό.

---

Nothing to declare...

    Γιατί να το "αποφύγεις" και να το αντικαταστήσεις με μία δυσκολότερη λύση? Πέρα από το ότι πρέπει να γράψεις τον κώδικα, φαντάσου κάποιον προγραμματιστή στο μέλλον που θα προσπαθήσει να καταλάβει τί γίνεται στη βάση και θα προσπαθεί να καταλάβει με ποιό μαγικό τρόπο αλλάζουν οι τιμές των ProductIDs.

    Δύο λόγους μπορώ να σκεφτώ για τους οποίους μπορεί να θέλεις να μην χρησιμοποιήσεις FK. Ο ένας είναι ότι φοβάσαι ότι θα έχει επίδραση στην ταχύτητα, αν και αυτό δεν ισχύει στην περίπτωση που η στήλη Products_Extendion.ProductID έχει index (κάτι το οποίο υποθέτω ότι έχει σίγουρα). Μπορείς πάντως να βάλεις το WITH NOCHECK στην ADD CONSTRAINT για να μην γίνεται έλεγχος, παρά μόνο CASCADE.
Σκέψου επίσης, ότι αν οι πίνακες έχουν σχέση 1-1 όπως φαίνεται, σχεδόν όσες φορές θα εκτελούνταν το check constraint, τόσες θα εκτελούνταν και το trigger σου.
    Ο δεύτερος λόγος είναι ότι χρησιμοποιείς ένα περίεργο σχήμα βάσης. Σε αυτή την περίπτωση θα πρέπει να σκεφτείς τί χρησιμοποιείς και πως.

Μπορείς πάντως να διαβάσεις την παλιά τιμή του ProductID από τον πίνακα deleted ο οποίος περιέχει τις τιμές πριν το update. Αντίστοιχα, ο inserted περιέχει τις τιμές μετά το update.

---

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

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... τελικά!

---

Nothing to declare...

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

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

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

---

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

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

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

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

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

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

Λοιπόν...

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

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

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

---

Nothing to declare...

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

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

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

---

Γιώργος Σακαλής

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

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

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

---

Nothing to declare...

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

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

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

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

---

Γιώργος Σακαλής

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

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

 

George J.

---

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

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

Εννοώ οτι εφαρμογές τις πλάκας (γενικά) υπάρχουν πολλές ακόμα κι αν επαγγέλονται οτι ακολουθούν τα οποιαδήποτε 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 μου... και δεν θα ήθελα να το σβήσω...  ]

---

Nothing to declare...

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.

---

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

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

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

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

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

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

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

---

Nothing to declare...

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

\

---

Γιώργος Σακαλής