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

Re: Δυναμικό pass SQL με χρήση EXEC

axaros — Tue, 31 May 2005 15:36:34 GMT

cap wrote:

Απλά λέω οτι το "ετοιμάσου για τις συνέπειες" ορισμένες φορές κοστίζει φθηνότερα από το "αντιτάξου στον παντοδύναμο", οποιος και αν είναι αυτός. Αλλες φορές είναι ο chief του R&D, άλλες φορές ο project manager, αλλες φορές το αφεντικό. Οπως και να έχει, μετράς το κόστος, και αποφασίζεις αν "it's not your job" ή οχι.
Αυτό είναι το μόνο που ήθελα να επισημάνω.

ΠΕΣ ΤΑ ΧΡΥΣΟΣΤΟΜΕ !!!!!!!

Re: Δυναμικό pass SQL με χρήση EXEC

cap — Mon, 30 May 2005 08:10:03 GMT

Παναγιώτη, όπως έγραψα και παραπάνω, δεν διαφωνώ σε τίποτα με αυτά που λές. Και προς Θεού, δεν επιχειρώ να καθιερώσω το FAD ως την de facto Ελληνική μεθοδολογία!

Απλά λέω οτι το "ετοιμάσου για τις συνέπειες" ορισμένες φορές κοστίζει φθηνότερα από το "αντιτάξου στον παντοδύναμο", οποιος και αν είναι αυτός. Αλλες φορές είναι ο chief του R&D, άλλες φορές ο project manager, αλλες φορές το αφεντικό. Οπως και να έχει, μετράς το κόστος, και αποφασίζεις αν "it's not your job" ή οχι.

Αυτό είναι το μόνο που ήθελα να επισημάνω.

Re: Δυναμικό pass SQL με χρήση EXEC

Παναγιώτης Καναβός — Mon, 30 May 2005 07:59:45 GMT

Τότε, ετοιμάσου για τις συνέπειες. Το dynamic sql είναι αντίστοιχο του συστηματικού copy-paste σε κάποια άλλη γλώσσα. Στην αρχή φαίνεται πιο γρήγορο. Όταν όμως "σκάσει" η μπόμπα, είναι πολύ δύσκολο να διορθωθεί.
Αυτός είναι και ο λόγος που σου λένε "μην το κάνεις έτσι". Ναι, μπορεί να αντέξει για μια μέρα ο κώδικας. Μετά όμως, θα το σκυλομετανοιώσεις. Τότε να δεις πλάκα με το manager που δεν ενδιαφέρεται, αλλά θα θέλει να διορθωθεί η κατάσταση αμέσως.

Και στην περίπτωση που μου έτυχε, πάλι επειδή δεν προλάβαιναν να καταλάβουν και να γράψουν σωστό sql έγινε η ζημιά. Το κόστος όμως ήταν αστρονομικό, καθώς οι καθυστερήσεις που προκάλεσε στο τέλος οδήγησαν στην ακύρωση του έργου, αλλά προκάλεσαν και καθυστερήσεις στην δημιουργία της νέας πλατφόρμας.

Τελικά, οι "γρήγορες" λύσεις δουλεύουν μόνο στα demo. Σε πραγματικές συνθήκες όμως δεν αντέχουν πολύ.

Re: Δυναμικό pass SQL με χρήση EXEC

cap — Mon, 30 May 2005 02:57:37 GMT

Δεν θα διαφωνήσω καθόλου μαζί σου. Ειναι κακή λύση.

Απλά να κάνω μια παρατήρηση:
Πολλές φορές έχει τύχει να κάνω μια ερώτηση που περιμένει συγκεκριμένη απάντηση. Οι καλοπροαίρετοι, δεν το αμφισβητώ αυτό, συνάδελφοι, τυχαίνει πολλές φορές να με ρωτήσουν "μα γιατί το κάνεις έτσι;", "γιατί δεν δοκιμάζεις να το κάνεις έτσι;" "είναι κακό να το κάνεις έτσι". Ομως, παρ'όλο που μπορεί να συμφωνώ με τις παρατηρήσεις, η ερώτηση είναι ερώτηση. Ορισμένες φορές δεν έχουμε επιλογή να το κάνουμε έτσι ή αλλιώς. Μπορεί αυτό να οφείλεται στο οτι ψωνίσαμε κώδικα αλλουνού και πρέπει να φτιαχτούν τα πάντα στη διάρκεια μιας πλήρους προβολής του "24", μπορεί να οφείλεται στο οτι ψωνίσαμε ΑΡΧΙΤΕΚΤΟΝΙΚΗ αλλουνού και αντε τρεχα τωρα, μπορεί να οφείλεται στο οτι μας πιέζουν πολύ και παρ'ότι γνωρίζουμε οτι δεν είναι η πλέον αποδεκτή λύση να μην έχουμε επιλογές, μπορεί να οφείλεται στο οτι δεν πληρωνόμαστε για να επανασχεδιάσουμε το μαραφέτι....

Οπως και να έχει, ορισμένες φορές ακόμα και μια "λάθος" προσέγγιση αξίζει απάντηση. Ορισμένες προσεγγίσεις είναι χειρότερες από άλλες. Ομως κάθε στιγμή πρέπει να συνυπολογίζουμε και άλλες παραμέτρους ως προς την επιλογή της "χειρότερης" ή της "καλύτερης" λύσης. Αν εγώ πληρωθώ 10 ευρώ για να κάνω κάτι σε 1 ωρα και αυτό το κάτι γίνεται ταχύτερα με dynamic sql, ποιος θα μου πληρώσει το χρόνο για να ΜΗΝ το κάνω έτσι; Αν δεν υπαρχει κανείς, αν ο πελάτης δεν ενδιαφερεται για το ΠΩΣ, αν ο manager σου δεν ενδιαφέρεται για το μετά, τότε ψωνίζει το dynamic sql σου με ΟΛΑ τα προβλήματα που μπορεί να έχει και πάει παρακάτω...

Ελπίζω να έγινα κατανοητός, δεν είχα πρόθεση να θίξω κάποιον.

Re: Δυναμικό pass SQL με χρήση EXEC

Παναγιώτης Καναβός — Mon, 30 May 2005 01:17:06 GMT

Όχι, απλά έχω τραβήξει τόσα εξαιτίας του exec που δεν έκατσα να διαβάσω όλο το thread! Άρχισα τον εξορκισμό μόλις διάβασα το πρώτο reply!
Μου είχε τύχει περίπτωση όπου χρησιμοποιούσαν exec αβέρτα. Τώρα, ένα από τα "καλά" του exec είναι ότι προκαλεί καθυστέρηση η οποία είναι ιδιαίτερα αισθητή όταν έχεις πολλούς χρήστες. Κάποια στιγμή έφτασε η εφαρμογή να σέρνεται απελπιστικά, οπότε έπρεπε να καθαριστεί από όλα τα παραπανίσια select και οπωσδήποτε όλα τα exec. Σαν "γνώστης" της SQL (που σημαίνει ότι ήμουν από τους λίγους που προτιμούσαν να φτιάξουν το σωστό select αντί για cursors ή exec) έπεσε σε μένα να κοιτάξω να δω τί πήγαινε στραβά καθώς και εναλλακτικούς τρόπους. Άντε λοιπόν να μαζέψεις όλα αυτά τα exec, να τα μετατρέψεις πάλι σε καθαρό sql για να δεις τί συμβαίνει με το execution plan τους και μετά να φτιάξεις τα σωστά stored procedures. Πέρασα μια εβδομάδα μαύρα χάλια. Άσε που την επόμενη βδομάδα δεν μπορούσα να κάνω την δική μου δουλειά. Έτσι χάθηκαν δύο βδομάδες από τη σχεδίαση της αρχιτεκτονικής της επόμενης έκδοσης του προϊόντος.

Η SQL είναι μια γλώσσα που λέει να βρεις τη σωστή λύση. Δεν είναι εύκολο, αλλά ευτυχώς, αν ακολουθήσεις κάποιους απλούς κανόνες, μπορείς να φτάσεις σε μια καλή αποδεκτή λύση. Και ένας από αυτούς είναι "OXI Dynamic SQL!". Και αν νομίζεις ότι σου χρειάζεται, δεν έψαξες αρκετά για τη λύση.

Re: Δυναμικό pass SQL με χρήση EXEC

KelMan — Mon, 30 May 2005 01:01:22 GMT

Χμμμ... Είπε κάποιος το αντίθτετο και δεν το κατάλαβα;

Re: Δυναμικό pass SQL με χρήση EXEC

Παναγιώτης Καναβός — Mon, 30 May 2005 00:33:47 GMT

Εξέλθετε εις το πυρ το εξώτερον άθλιοι!

Το exec δεν έχει καμμία διαφορά από το να εκτελέσεις χύμα SQL. Ίδια προβλήματα ασφαλείας, ίδια προβλήματα ταχύτητας. Για να δουλέψει, θα πρέπει όποιος το εκτελεί να έχει δικαίωμα πρόσβασης στους πίνακες που εμπλέκονται. Να μην πούμε για τα καταπληκτικά injection attacks που μπορεί να κάνει κανείς, είτε από web εφαρμογές, είτε από windows εφαρμογές.

Αν θέλετε να περιορίσετε τα strings που στέλνετε στο δίκτυο, φτιάξτε κατάλληλα views και καλέστε τα. Είναι όμως χίλιες φορές καλύτερο να φτιάξετε stored procedures για τους συνδιασμούς των παραμέτρων.

Και κάτι που έμαθα από τότε που γράφτηκε το Dynamic SQL Where clauses using conditional operators. Τα case, where αναγκάζουν τον sql optimizer να δημιουργήσει διαφορετικά execution plans και κάθε φορά που εκτελείται το stored procedure ψάχνεται να βρει ποιό είναι το κατάλληλο.

Δεν ξέρω πως να το πω πιο έντονα.
Το exec είναι για την SQL ότι το copy paste για τη VB, την C# ή όποια άλλη γλώσσα.

ΚΑΚΟ ΚΑΚΟ ΚΑΚΟ! ΞΟΥ ΞΟΥ ΞΟΥ!

Re: Δυναμικό pass SQL με χρήση EXEC

axaros — Sun, 29 May 2005 22:37:08 GMT

Ένα μεγάλο nvarchar parameter περνάω που περιέχει το WHERE Clause που θέλω ανά περίπτωση.

Re: Δυναμικό pass SQL με χρήση EXEC

KelMan — Sun, 29 May 2005 22:32:04 GMT

axaros wrote:

KelMan wrote:

ώς SQL injection attacks...

Στο προηγούμενο Post αναφερόμουνα στο πρώτο σκέλος της απάντησης για το δεύτερο όντως τι κάνει κανείς ???
Υπάρχει σωτηρία???

Υπάρχουν διάφοροι τρόποι από απλοί "χειροκίνητοι", μέχρι σύνθετοι...
Πχ αν κάνεις
"WHERE CustName LIKE '" & Textbox1.Text & "%'"
θα πρέπει να αφαιρέσεις όλα τα single quotes από το text property.
Αν όμως χρησιμοποιείς ένα Command object και δίνεις τιμές σε παραμέτρους μέσω Parameter objects τότε δεν έχεις πρόβλημα. Για περισσότερες πληροφορίες ρίξε μια ματιά εδώ ή δώσε στο Google "SQL injection attack" και θα βρεις πολλύ υλικό...

Re: Δυναμικό pass SQL με χρήση EXEC

axaros — Sun, 29 May 2005 22:31:01 GMT

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

Θέλετε να μιλήσουμε για extensibility όταν ακόμη και το testing θα γίνει on site κατ' απαίτηση των ειδημόνων εμπορικών λαμόγιων ;

Re: Δυναμικό pass SQL με χρήση EXEC

cap — Sun, 29 May 2005 21:44:02 GMT

gcapnias wrote:

Στην Ελλάδα είναι τρόπος ζωής. Οπότε μην αγχώνεσαι και πολύ. Το θέμα είναι να υπάρχει έλεγχος που είναι η εφαρμογή και που το patchwork.

Εδώ πλέον μιλάμε για enteriprise layer στο patchwork και ενσωμάτωση των άλλων layers μέσα σε αυτό...

George J.

Εχμ. Εδώ στο Ελλάντα, οπου ο πελάτης δεν γνωρίζει τι θέλει, και ο προγραμματιστής / αναλυτής / project manager δεν βοηθάει ούτε αυτόν που παραγγέλνει το λογισμικό αλλα ούτε και αυτόν που το φτιάχνει, σπάνιες είναι οι περιπτώσεις που με σωστό design θα πας "μπροστά"...

Ενας από τους λόγους είναι οτι τελικά ο πελάτης (ειδικά όταν πρόκειται για μεγάλους οργανισμούς) δίνει περισσότερο βάση στο ΠΟΤΕ θα παραδοθεί το πράγμα παρά στο ΠΩΣ θα κάνει αυτά που κάνει. Αρκετές φορές αγνοεί τελείως τα performance metrics, άλλες φορές δεν δίνει δεκάρα για το user interface (μεγααααλο κεφαλαιο αυτό - οι περισσότεροι πάνε με τις προδιαγραφές αδιαφορώντας αν το user interface μπορεί να δουλευτεί από χρήστες με IQ μικρότερο από αυτό της Sharon Stone - μην κοροιδεύετε, είναι μέλος της MENSA!) και άλλες φορές σφυράει αδιάφορα ως προς το extensibility...ετσι, η σύγχρονη δημιουργία λογισμικού στην Ελλάδα μεταφράζεται ως "παρε τα λεφτά και τρέχα", ενώ για refactoring ούτε λόγος...το refactouring ζει και βασιλεύει.

Re: Δυναμικό pass SQL με χρήση EXEC

axaros — Sun, 29 May 2005 21:26:19 GMT

KelMan wrote:
ώς SQL injection attacks...

Στο προηγούμενο Post αναφερόμουνα στο πρώτο σκέλος της απάντησης για το δεύτερο όντως τι κάνει κανείς ???
Υπάρχει σωτηρία???

Re: Δυναμικό pass SQL με χρήση EXEC

axaros — Sun, 29 May 2005 21:22:42 GMT

Το ξέρω το ξέρω Μάνο ...
Στη συγκεκριμένη περίπτωση το πράγμα είναι εύκολα διαχειρίσιμο αφού το WHERE χτίζεται με βάση τα checked nodes ενός tree control ...

Re: Δυναμικό pass SQL με χρήση EXEC

KelMan — Sun, 29 May 2005 19:50:21 GMT

FAD-ξεFAD πάντως, αν ακολουθείς τέτοιες λύσεις χρειάζεται τεράστια προσοχή στην κατασκευή του SQL statement, ιδιαίτερα αν τμήματά του είναι user input από text boxes κλπ, γιατί κινδυνεύεις από το συντακτικά λάθη στο statement ώς SQL injection attacks...

Re: Δυναμικό pass SQL με χρήση EXEC

George J. Capnias — Sun, 29 May 2005 19:40:42 GMT

axaros wrote:
FAD IS BAD Δάσκαλε????

Στην Ελλάδα είναι τρόπος ζωής. Οπότε μην αγχώνεσαι και πολύ. Το θέμα είναι να υπάρχει έλεγχος που είναι η εφαρμογή και που το patchwork.

Εδώ πλέον μιλάμε για enteriprise layer στο patchwork και ενσωμάτωση των άλλων layers μέσα σε αυτό...

George J.