Καταρχήν, ας ξεκινήσουμε από το ότι ο DBA είναι ο άρχοντας των δεδομένων του οργανισμού, ο άνθρωπος που εξασφαλίζει τη διαθεσιμότητα των δεδομένων. Όπερ σημαίνει ότι θα πρέπει να έχει τόσο dev γνώσεις όσο και system. Πέρα λοιπόν από τις προφανείς systemικές εργασίες και αρμοδιότητες (backup/restore, security, κλπ) θα πρέπει να μπορεί να συμμετάσχει σε μια ομάδα όπου οι developers προτείνουν κάποιες αλλαγές και να αντιλαμβάνεται τι συνεπάγεται αυτό για τις βάσεις του και ενδεχομένως να ασκεί βέτο. Θα πρέπει να μπορεί να εξετάζει ένα execution plan και σε συνεργασία με τους developers να ζητήσει αλλαγές στον κώδικα ή/και να αλλάζει το indexing. Επίσης, θα πρέπει όταν κάνει performance analysis να μπορεί να καταλάβει αν φταίει η εφαρμογή και που ακριβώς. Όλα αυτά δεν γίνονται από έναν admin. Δεν είναι τυχαίο που οι guru του είδους δεν έχουν απλά γνώσεις για το προϊόν (SQL Server, Oracle, κλπ) αλλά και για τις client τεχνολογίες που πέφτουν πάνω στο προϊόν που καλούνται να συντηρούν καθημερινά.
Τώρα, για να έχει νόημα η ύπαρξη ενός DBA θα πρέπει κυρίως να γίνεται in-house development. Διαφορετικά η δουλειά του μπορεί να γίνει από έναν admin που έχει και πέντε γνώσεις περί βάσεων (το πόσο πευχημένα/αποτυχημένα είναι σχετικό). Όταν η επιχείρηση διαλέγει έτοιμες λύσεις, ο DBA δεν μπορεί να κάνει και πολλά σε ότι αφορά στο developικό κομμάτι. Όπως αντιλαμβάνεσαι, το in-house development είναι πολύ περιορισμένο στην Ελλάδα του SBS και γι αυτό δεν συναντάς ιδιαίτερη ζήτηση στης αγγελίες. Από την άλλη μεριά, ούτε ένα s/w house χρειάζεται ιδιαίτερα DBA για τις εφαρμογές που φτιάχνει γιατί πρόκειται για generic λύσεις που θα κάτσουν πάνω στο εκάστοτε περιβάλλον του πελάτη. Τώρα βέβαια αν το s/w παρέχει τέτοιου ανάλογες after-sales υπηρεσίες είναι άλλο θέμα.
Vir prudens non contra ventum mingit