Ο σκοπός ενός transactional συστήματος είναι συγκεκριμένος. Συχνά υπάρχει η απαίτηση τα δεδομένα του συστήματος να μπορούν να είναι διαθέσιμα σε διάφορες μορφές έτσι ώστε να υποστούν περεταίρω επεξεργασία. Για παράδειγμα, εξαγωγή στατιστικών, αντιπαραβολή με δεδομένα άλλων συστημάτων, παραγωγή reports κλπ.
Η πιο απλή λύση είναι να δώσεις σε κάποιο χρήστη τη δυνατότητα να πάρει ότι θέλει από την βάση δεδομένων. Υλοποίηση μηδέν, απόλυτη ευελιξία και καθόλου γκρίνια! Άλλωστε και η βάση του χρήστη είναι. Ποτέ δεν μπορείς να του απαγορεύσεις την πρόσβαση.
Εμένα θα μου άρεσε όμως περισσότερο ο χρήστης να έχει πρόσβαση σε κάποια web services ή αρχεία xml για το σκοπό αυτό. Από κάποιο σημείο του προγράμματος, για παράδειγμα, θα μπορούσε να υπάρχει ένα πλήκτρο που να λέει με κάπως κομψό τρόπο "βγάλε μου όλους τους πελάτες με κωδικό από 1111 έως 1999 σε xml" και να παράγεται ένα αρχείο στον server με κάποιο όνομα. Αν μιλάμε για client/server ή web εφαρμογή, το αρχείο αυτό θα γίνει download στο client και αν είναι μεγάλο (π.χ. 100MB!!!), θα υπάρχει μια μικρή καθυστέρηση. Το αρχείο xml θα μπορεί να εισαχθεί στη συνέχεια σε κάποιο excel, access, reporting services και ότι κατεβάσει ο νους του καθενός και να κάνει ότι θέλει.
Πως σας φαίνεται; Λέτε στην περίπτωση τόσο μεγάλων αρχείων να μην μπορεί να δουλέψει καθόλου το όλο σκεπτικό;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

To "καθόλου γκρίνια" είναι σχετικό... Όσο τα data είναι μέσα στη βάση, κανείς δεν ενδιαφέρεται για το "πως" είναι. Όταν βγουν, ο ένας τα θέλει έτσι, ο άλλος αλλιώς και ο τρίτος γιουβέτσι (μου αρέσει να κάνω επιστημονική κουβέντα). Εξάλλου, υποψιάζομαι ότι αποκλείεται να θέλεις να κάνεις export μόνο τους πελάτες... Σίγουρα κάποιος θα σου πει "όταν εννοείς πελάτες, συμπεριλαμβάνονται και οι παραγγελίες τους;", γιατί βεβαίως ο άνθρωπος δεν ξέρει από πίνακες και objects, στο μυαλό του έχει την εικόνα του πελάτη μαζί με τις παραγγελίες.

Οπότε αρχίζουν τα προβλήματα... Θα πρέπει να βρεις μια αρκετά generic και ευέλικτη λύση αν σκοπεύεις να ενσωματώσεις κάποιο utility για export. Ενδεχομένως να υλοποιεί κάποιον designer ώστε να επιλέγουν οι advanced χρήστες τι θα γίνει export ή έναν plugin μηχανισμό ώστε πχ να προσθέτεις export templates και το σύστημα όταν επιλέγεις "export" να σου προτείνει έναν από τα πιθανά templates.

Απο εκεί και πέρα, μπορείς να υλοποιήσεις κάποια technology-specific λύση ώστε να κρατάς αλλού data κατάλληλα για reporting, πχ σε ελαφρώς denormalized μορφή ή ακόμα-ακόμα και μέσα σε data mart όπου πλέον ο καθένας θα μπορεί να ζητάει ό,τι report του καπνίζει χωρείς να επιβαρύνεται το OLTP σύστημα σου.

---

Vir prudens non contra ventum mingit

KelMan wrote:

To "καθόλου γκρίνια" είναι σχετικό... Όσο τα data είναι μέσα στη βάση, κανείς δεν ενδιαφέρεται για το "πως" είναι. Όταν βγουν, ο ένας τα θέλει έτσι, ο άλλος αλλιώς και ο τρίτος γιουβέτσι (μου αρέσει να κάνω επιστημονική κουβέντα). Εξάλλου, υποψιάζομαι ότι αποκλείεται να θέλεις να κάνεις export μόνο τους πελάτες... Σίγουρα κάποιος θα σου πει "όταν εννοείς πελάτες, συμπεριλαμβάνονται και οι παραγγελίες τους;", γιατί βεβαίως ο άνθρωπος δεν ξέρει από πίνακες και objects, στο μυαλό του έχει την εικόνα του πελάτη μαζί με τις παραγγελίες.

Γι αυτό λέω... δεν κάνεις τίποτα και τους αφήνεις να βγάλουν τα μάτια τους με τη βάση! με όλα τα επακόλουθα...

Κάποιος administrator αναλαμβάνει τη δουλειά να κάνει custom queries και να τα βάζει αλλού, είτε αυτό είναι data mart είτε είναι γιουβέτσι!

Αλλά ένα σοβαρό σύστημα το κάνει αυτό;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Γιατί το λες αυτό; Ένα σύστημα που κάνει export σε data mart και συντηρεί ωραία κυβάκια δεν είναι σοβαρό; Σοβαρότατο θα έλεγα...

---

Vir prudens non contra ventum mingit

KelMan wrote:

Γιατί το λες αυτό; Ένα σύστημα που κάνει export σε data mart και συντηρεί ωραία κυβάκια δεν είναι σοβαρό; Σοβαρότατο θα έλεγα...

Είναι όντως σοβαρό. Τόσο σοβαρό, που έχει πρακτικά υλοποιημένο ένα σύστημα BI μέσα του, και είναι 2 προϊόντα σε ένα. Δεν ξέρω πόσα προϊόντα το κάνουν αυτό, τόσο λόγω δυσκολίας, όσο γιατί δεν μπορείς να διασπάς τα core competencies σου σε πολλά domains.
Μήπως όταν θέλεις κάτι τέτοιο πρέπει να κοιτάξεις για ένα οικονομικό BI tool; Δε λέω να ρίξεις ένα Hyperion από πάνω, υπάρχουν και πιο απλά πράγματα. Έχω και να σας συστήσω ένα αν θέλετε, είναι της εταιρείας που δουλεύω

---

Νατάσα Μανουσοπούλου

Ναι, αυτό εννοούσα όταν έλεγα για technology-specific λύσεις. Σίγουρα είναι πολύ δύσκολο να δώσεις μια τέτοια λύση ως shrink wrapped application.

Γενικά πάντως θα πρέπει πρώτα να προσδιορίσουμε το ζητούμενο στην διαδικασία του export. Θέλουμε data για χρήση από άλλα συστήματα; Θέλουμε data για τον χρήστη, να τα παίρνει στο Excel ή/και την Access; Θέλουμε data για Reporting; Θέλουμε κάτι που να γίνεται ad-hoc ή όχι; Ουσιαστικά αυτά σε οδηγούν στο τι θα κάνεις. Υπάρχει αρκετός δρόμος από το grid control που έχει "save as..." button μέχρι την BI λύση.

---

Vir prudens non contra ventum mingit

Παρεξήγησης. Το "σοβαρό σύστημα" πήγαινε στο "αφήνω τους χρήστες να πάρουν ότι θέλουν από την OLTP βάση και δεν κάνω τίποτα.

Οπότε, αν κατάλαβα καλά, μια πρόταση είναι να δημιουργήσω μια δεύτερη βάση και να περάσω τα δεδομένα μου εκεί και να αφήσω τον κόσμο να παίξει εκεί, αντί να του δώσω XML.

Δεν προσδιόρισα τον σκοπό του export, γιατί δεν είναι ξεκάθαρος. Υπάρχουν άλλοι πελάτες που θέλουν να συσχετίσουν τα δεδομένα με άλλα άλλων πηγών και άλλοι που θέλουν να κάνουν reporting εργασίες. Γενικά θέλω να δώσω πρόσβαση στα δεδομένα της OLTP βάσης για θεραπεία "πάσας νόσου και πάσας μ....". Και επειδή δεν με ενθουσιάζει να μπαίνει χέρι στην βάση μου, θέλω να δώσω τα δεδομένα κάπου αλλού.

Οικονομικό BI tool ε; π.χ.; για το Hyperion μιλάς;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Η ΒΙ λύση δεν προσφέρεται για "πάσα νόσο και πάσα μ*****". Πχ δεν προσφέρεται για να συσχετίσει κανείς τα data σου με data από άλλες πηγές καθώς είναι δύσκολο το merging των δεδομένων. Από την άλλη, και διαφορετική βάση να έχεις κάπως θα πρέπει να τα τραβήξεις για να τα δώσεις. Αν πρόκειται να κάνει αυτή τη δουλειά ο χρήστης, θα πρέπει να του δώσεις κάτι σαν query wizard. Ίσως να χρειάζεται να ακολουθήσεις ένα κλιμακωτό approach: Δυνατότητα για "save as..." του "ό,τι βλέπει ο χρήστης στο Grid" για να πιάσεις τη μάζα των export αναγκών που έχουν συνήθως οι απλοί χρήστες. Σε δεύτερο επίπεδο έναν μηχανισμό σαν αυτόν που σου περιέγραψα με τα templates για να δίνεις εύκολα export σενάρια όταν στα ζητάνε. Αν φτιάξεις κι έναν designer γι αυτήν τη δουλειά, μπορείς να τον ενσωματώσεις για τους advanced χρήστες. Σε τρίτο επίπεδο ένα απλό BI tool ώστε να μπορείς να εξυπηρετήσεις ποικιλία από reports και τέλος αν σε ενδιαφέρει το scalability και το performance και για να μπορέσεις να εξυπηρετήσεις μεγάλο όγκο από data, περνάς σε λύσεις τύπου Analysis Services. Βέβαια, αν βάλεις κάτω τον χρόνο υλοποίησης που απαιτεί κάθε ένα από τα παραπάνω σε σχέση με το κόστος, κλπ, κλπ ίσως δεις ότι μπορείς να φτάσεις μέχρι κάποιο σημείο και τα υπόλοιπα θα είναι "nice-to-have"... 

---

Vir prudens non contra ventum mingit

Έχω 3 real life σενάρια να συνεισφέρω ... κανένα δεν είναι τόσο advanced όσο το data-marting, αλλά .. προσεγγίζει κάπως, τουλάχιστον το ένα.

Στο σύστημα που διαχειρίζεται τις υποβολές προτάσεων για το 3ο ΚΠΣ, υπάρχουν εγκατεστημένα σε ένα "τρίτο" μηχάνημα reporting services. Data source για αυτά είναι η βάση της κυρίως εφαρμογής, μέσω ενός hand crafted extention για τα Reporting Services του SQL 2005. Επειδή ο τελικός χρήστης είναι υπάλληλος σε μια τράπεζα, και είναι πιο εξοικειωμένος με το Excel απ'ότι με ... xml ... έχουμε κάνει expose το μοντέλο της βάσης σε .. models, τα οποία μπορούν να χρησιμοποιήσουν με τον Report builder των R.S. - ο Report Builder είναι click-once deployed, κι έτσι ο κάθε τραπεζικός μπορεί να φτιάξει ότι report θέλει, κι ότι τραβάει η ψυχούλα του πάνω στα δεδομένα που αφορούν την τράπεζά του.

Πρέπει εδώ να πώ οτι η υλοποίηση αυτού του πράγματος είναι ... painful to say the least. Ακόμη περιμένουμε patches απο τη μαμά MS Αμερικής για κάποια issues όταν τρέχεις πίσω απο proxies .. αλλά αυτό είναι irrelevant. Δουλεύει.

Στην ίδια εφαρμογή, ο κυρίως πελάτης - το κράτος ας πούμε - έχει κάποιους ανθρώπους οι οποίοι είναι πληροφορικάριοι. Για δικές τους ανάγκες, χρειάζεται να φτιάχνουν reports, αλλά έχοντας full access στη βάση. Για αυτούς, το μέρος όλου αυτού του "framework" το οποίο είναι κάτω απο όλα αυτά - xml config αρχεία τα οποία περιέχουν τα queries και κάποια άλλα attributes δουλεύει μια χαρά. Γράφουν την sql τους, τα menus, authorization πάνω σε ρόλους κτλ κτλ στο lowest level possible στα πλαίσια της εφαρμογής και είναι happy as they can be.

Πέρα τώρα απο τα "βαριά" reports, κάθε process/workflow/πες-το-όπως-θες-ένας-wizard-είναι-με-30-steps χρειάζεται να μπορεί στο τέλος να εκτυπωθεί. Σε Word, σε PDF ... wherever. Πάνω λοιπόν απο το base framework υπάρχουν "filter chains" τα οποία:

1. Διαβάζουν τα απαραίτητα δεδομένα απο τη βάση, as raw as they come
2. Κάνουν καποια transformations, calculations etc.
3. Εξάγουν το τελικό αποτέλεσμα σε κάποια "exportable/importable/printable" μορφή.

Κι έτσι κάπως, έχεις xml exports, συμβατά με το ΟΠΣ ας πούμε ...

Κι αυτό το "πακετάκι", μια χαρά έχει δουλέψει. Αν μάλιστα το υλοποιήσεις και σε ένα IHttpAsyncHandler είναι και αρκετά πολύ scalable.

Όπως βλέπεις λοιπόν, με ένα layered approach, μπορείς να έχεις σχεδόν όποια λύση θέλεις, ανάλογα τις απαιτήσεις των πελατών σου. Αλλά όπως είπε κι ο Μάνος, πρέπει πρώτα να ξέρεις αυτές τις απαιτήσεις. Κι εμείς δεν ξεκινήσαμε έχοντας όλο αυτό το πράγμα στο μυαλό μας - απλώς είμασταν τυχεροί και είχαμε κρατήσει μια "αρχιτεκτονική" η οποία ήταν "ανοιχτή σε προτάσεις" :D ... αλλά σε κάθε βήμα, είχαμε πολύ συγκεκριμένους στόχους.

.. αν όλα αυτά έχουν κάτι να συνεισφέρουν στο αρχικό ερώτημα .. :) .. ( αν όχι .. sorry ρε παιδιά, τι να κάνεις ... 12 η ώρα το βράδυ ... απο πρώτη μέρα στη δουλειά μετά απο άδεια και τέτοια ... :P )

---

Angel
O:]

KelMan wrote:

Η ΒΙ λύση δεν προσφέρεται για "πάσα νόσο και πάσα μ*****". Πχ δεν προσφέρεται για να συσχετίσει κανείς τα data σου με data από άλλες πηγές καθώς είναι δύσκολο το merging των δεδομένων. Από την άλλη, και διαφορετική βάση να έχεις κάπως θα πρέπει να τα τραβήξεις για να τα δώσεις. Αν πρόκειται να κάνει αυτή τη δουλειά ο χρήστης, θα πρέπει να του δώσεις κάτι σαν query wizard. Ίσως να χρειάζεται να ακολουθήσεις ένα κλιμακωτό approach: Δυνατότητα για "save as..." του "ό,τι βλέπει ο χρήστης στο Grid" για να πιάσεις τη μάζα των export αναγκών που έχουν συνήθως οι απλοί χρήστες. Σε δεύτερο επίπεδο έναν μηχανισμό σαν αυτόν που σου περιέγραψα με τα templates για να δίνεις εύκολα export σενάρια όταν στα ζητάνε. Αν φτιάξεις κι έναν designer γι αυτήν τη δουλειά, μπορείς να τον ενσωματώσεις για τους advanced χρήστες. Σε τρίτο επίπεδο ένα απλό BI tool ώστε να μπορείς να εξυπηρετήσεις ποικιλία από reports και τέλος αν σε ενδιαφέρει το scalability και το performance και για να μπορέσεις να εξυπηρετήσεις μεγάλο όγκο από data, περνάς σε λύσεις τύπου Analysis Services. Βέβαια, αν βάλεις κάτω τον χρόνο υλοποίησης που απαιτεί κάθε ένα από τα παραπάνω σε σχέση με το κόστος, κλπ, κλπ ίσως δεις ότι μπορείς να φτάσεις μέχρι κάποιο σημείο και τα υπόλοιπα θα είναι "nice-to-have"...

Φαίνεται πως κάπως έτσι είναι. Θα κάνω ένα απλό export σε xml για τον χρήστη, όχι όμως από το grid. Είτε του αρέσει είτε όχι, εγώ xml θα βγάλω. Ούτε excel, ούτε text delimited.
Για τους λοιπούς ίσως κάνω ένα νέο μοντέλο της βάσης, λιγότερο κανονικοποιημένο, που να αντιγράφονται εκεί τα δεδομένα με DTS και να αφήνω τον κόσμο να παίζει εκεί όπως θέλει.... συνέχεια στα σχόλια του angelinio...

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Θα σε βομβαρδίσω!!!

anjelinio wrote:

Έχω 3 real life σενάρια να συνεισφέρω ... κανένα δεν είναι τόσο advanced όσο το data-marting, αλλά .. προσεγγίζει κάπως, τουλάχιστον το ένα. Στο σύστημα που διαχειρίζεται τις υποβολές προτάσεων για το 3ο ΚΠΣ, υπάρχουν εγκατεστημένα σε ένα "τρίτο" μηχάνημα reporting services. Data source για αυτά είναι η βάση της κυρίως εφαρμογής, μέσω ενός hand crafted extention για τα Reporting Services του SQL 2005. Επειδή ο τελικός χρήστης είναι υπάλληλος σε μια τράπεζα, και είναι πιο εξοικειωμένος με το Excel απ'ότι με ... xml ... έχουμε κάνει expose το μοντέλο της βάσης σε .. models, τα οποία μπορούν να χρησιμοποιήσουν με τον Report builder των R.S. - ο Report Builder είναι click-once deployed, κι έτσι ο κάθε τραπεζικός μπορεί να φτιάξει ότι report θέλει, κι ότι τραβάει η ψυχούλα του πάνω στα δεδομένα που αφορούν την τράπεζά του.

Αν μπορούσες να αναλύσεις λίγο παραπάνω σε αυτό το σημείο...
Τι εννοείς "έχουμε κάνει expose το μοντέλο της βάσης σε ...models;". Έχεις αντιγράψει την βάση σου σε άλλη βάση; Δεν είμαι πολύ εξοικοιωμένος με τα reporting services και φαίνεται ότι πρέπει να κάνω κάτι άμεσα. Αυτό με τον click-once deployed builder θα το δοκιμάσω. Άλλωστε και η δική μου εφαρμογή είναι click-once deployed και ταιριάζει! (έτσι όπως το έθεσα είναι σαν να έλεγα ότι το αυτοκίνητό μου ταιριάζει με τα παπούτσια!).

anjelinio wrote:

Στην ίδια εφαρμογή, ο κυρίως πελάτης - το κράτος ας πούμε - έχει κάποιους ανθρώπους οι οποίοι είναι πληροφορικάριοι. Για δικές τους ανάγκες, χρειάζεται να φτιάχνουν reports, αλλά έχοντας full access στη βάση. Για αυτούς, το μέρος όλου αυτού του "framework" το οποίο είναι κάτω απο όλα αυτά - xml config αρχεία τα οποία περιέχουν τα queries και κάποια άλλα attributes δουλεύει μια χαρά. Γράφουν την sql τους, τα menus, authorization πάνω σε ρόλους κτλ κτλ στο lowest level possible στα πλαίσια της εφαρμογής και είναι happy as they can be.

Αν έχουν full access στη βάση τότε που μπαίνει το "framework" σου και τα xml config;
Όταν λες menus, authorization κλπ; Γράφουν κώδικα είναι είναι configurable;

anjelinio wrote:

.. αν όλα αυτά έχουν κάτι να συνεισφέρουν στο αρχικό ερώτημα .. :) .. ( αν όχι .. sorry ρε παιδιά, τι να κάνεις ... 12 η ώρα το βράδυ ... απο πρώτη μέρα στη δουλειά μετά απο άδεια και τέτοια ... :P )

Θα αστειέυσαι! Συνεισφέρουν και πολύ μάλιστα...

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Αυτό που περιγράφει ο anjelinio θα μπορούσε να γίνει πολύ ευκολότερα χρησιμοποιώντας ένα Data Warehouse. Έτσι κι αλλιώς, για να δημιουργηθούν τα reports χρειάζεται να τρέξουν περίπλοκα scripts, τα οποία από τη μία διαβάζουν δεδομένα και τα συνδυάζουν, από την άλλη υπολογίζουν τιμές στα συνδυασμένα δεδομένα. Το πρώτο βήμα είναι ίδιο σχεδόν με το ETL βήμα ενός DW. Θα έλεγα μάλλον ότι είναι (πολύ) ευκολότερο με DW. Το δεύτερο βήμα είναι παιχνιδάκι έτσι και φτιάξεις ένα κύβο.

Αυτό που έχω διαπιστώσει πάντως είναι ότι οι περισσότεροι προγραμματιστές και οι manager τους δεν χρησιμοποιούν DW γιατί άκουσαν ότι είναι δύσκολα, όχι γιατί είναι πράγματι δυσκολότερα από τις λύσεις με scripts. Αν ξέρεις τί θέλεις, και δεν ζητάς τη θεραπεία "δια πάσαν νόσον" κλπ., ένα dw για αυτό που περιγράφει ο anjelinio μπορεί να γίνει σε 2 εβδομάδες (διαπιστωμένο, όχι εκτίμηση). Τα αντίστοιχα scripts θα χρειαστούν τον ίδιο, αν όχι περισσότερο χρόνο. Η διαφορά είναι ότι το DW τροποποιείται πολύ ευκολότερα, η προσθήκη νέων υπολογισμών και κριτητρίων, π.χ. για κατανομή επιδοτήσεων, είναι πολύ ευκολότερη, ενώ η ταχύτητα πολύ μεγαλύτερη.

Το πρόβλημα είναι ότι όταν προτείνεις σε κάποιον "να φτιάξουμε reporting database ή data warehouse" φοβάται ότι η περιπλοκότητα θα είναι πολύ μεγάλη, ότι το έργο θα πάρει πολύ χρόνο, κλπ, κλπ, κλπ. Το αποτέλεσμα είναι ότι καταλήγει το κάθε νέο report να είναι μία πολύ δύσκολη δουλειά, εκεί που μπορούσε να είναι πολύ εύκολη.

---

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

Θα επανέλθω το βραδάκι Δημήτρη ( και Πάνο ... ) γιατί αυτή τη στιγμή τρέχουμε και δε φτάνουμε ... :P

---

Angel
O:]

Η απαίτηση στην περίπτωσή μου είναι γενική και έχει να κάνει με το να παρέχει το σύστημά μου στους ανθρώπους της υποστήριξης και τους administrators ή advanced users των πελατών να κάνουν διάφορα πράγματα. Όχι να κάνω εγώ κάτι συγκεκριμένο, π.χ. ένα συγκεκριμένο cube για κάποια χρήση. Το προϊόν, γιατί περί προϊόντος πρόκειται - όχι για κάποια custom λύση για κάποιο πελάτη, πρέπει να δίνει τη δυνατότητα σε κάποιον να τραβήξει δεδομένα. Αυτός ο κάποιος, είτε είναι προσωπικό υποστήριξης, είτε ο πελάτης, μπορεί να αποφασίσει να κάνει cubes, dw και ότι άλλο θέλει ή απλά να πάρει ένα .xls με μια λίστα.

Οπότε αυτό που θέλω είναι έναν elegant τρόπο να κάνω expose τα δεδομένα μου, αντί να δώσω ως έχει την OLTP βάση και να πως σε οποιονδήποτε να κάνει ότι θέλει εκεί!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

papadi wrote:

Θα σε βομβαρδίσω!!! Τι εννοείς "έχουμε κάνει expose το μοντέλο της βάσης σε ...models;". Έχεις αντιγράψει την βάση σου σε άλλη βάση; Δεν είμαι πολύ εξοικοιωμένος με τα reporting services και φαίνεται ότι πρέπει να κάνω κάτι άμεσα.

Τα Reporting Services μπορούν να δουλέψουν ως εξής ... έχεις τη δυνατότητα να φτιάξεις ένα "μοντέλο" - κάτι σαν view που έχει πάρει speed-άκια είναι αυτό - και να το κάνεις deploy σε ένα web application που στήνουν τα reporting services. Μετά, με τον Report Builder, ένα click-once deployed application που μοιάζει λίγο με designer στην Access ή κάτι παρόμοιο, μπορούν οι users σου να κάνουν login remotely στα R.S. και να φτιάχουν reports πάνω σε αυτό το μοντέλο. Μπορούν μάλιστα να σώσουν αυτά τα reports στα reporting services και να μπορούν να τα δούν κι άλλοι χρήστες απο web interface.

Είναι λίγο ιδιότροπο βέβαια το authentication / authorization πάνω στα R.S. αλλά σε ένα σχετικά απλό σενάριο του ποιός μπορεί να δεί ποια μοντέλα είναι σχετικά απλό.

papadi wrote:

Αν έχουν full access στη βάση τότε που μπαίνει το "framework" σου και τα xml config; Όταν λες menus, authorization κλπ; Γράφουν κώδικα είναι είναι configurable;

Εκτός απο τα user reports, υπάρχει η δυνατότητα να γράψεις τα queries σου σε κάποια xml config files που έχουμε κάπου στον "πάτο" της όλης ιστορίας, τα οποία περιλαμβάνουν και κάποια άλλα metadata, όπως π.χ. ποιοί ρόλοι έχουν access σε αυτά. Έτσι, μπορούν οι "δημόσιοι" να προσθέτουν reports για όποια user groups θέλουν, και αυτά να εμφανίζονται @runtime στα αντίστοιχα μενού των χρηστών. Είναι απλώς ένας εναλλακτικός τρόπος να προσθέτεις reports στο σύστημα ... "απο κάτω".

[ Να πώ εδώ, οτι το datasource του κάθε report που δεν έχει φτιαχτεί απο κάποιον user, παίρνει data απο τα queries που περιέχονται σε αυτά τα config files. Αυτά που έχουν φτιαχτεί απο users, παίρνουν δεδομένα βάσει του μοντέλου το οποίο χρησιομοποίησαν για να φτιάξουν το report τους - επίσης να πώ οτι κι εγώ ίσως δεν καταλάβω τί εννοώ όταν ξαναδιαβάσω αυτή την πρόταση που μόλις έγραψα :D ]

Τώρα φίλε Πάνο ... η χρήση reporting services δεν αποκλείει τη χρήση ενός Data Warehouse. Ένα ακόμη data source για τα reporting services είναι. Επειδή όμως ήσουν ένα χρόνο στην εταιρία ( σε παλιά σου posts μάλιστα την κατονομάζεις σχεδόν .. περήφανα :P ) και ξέρεις πως είναι τα πράγματα, μπορείς να φανταστείς οτι απλώς δεν είχαμε το χρόνο να κάνουμε και μια τέτοια υλοποίηση.

Παρόλα αυτά, και αν και δεν είμαι καθόλου data warehouse oriented προσωπικά, δε νομίζω οτι η κυρία Βασιλική της "Συνεταιριστικής Τράπεζας Παραμεθωρίου" θα "την πάλευε" έχοντας ένα interface μπροστά της το οποίο δεν είναι όσο απλός είναι ο  Report Builder αυτή τη στιγμή :P Αυτό χρειάζοντας οι χρήστες μας, οι οποίοι δεν ξέρουν καν τι είναι ένας κύβος ... του Rubick, αυτό δώσαμε. Θέλω να πιστεύω - και ήδη έχουμε κινηθεί προς αυτή την κατεύθυνση - οτι το μέλλον θα μας βρεί Data Warehouse enabled μέσα στο επόμενο 6-μηνο.

Αυτά απο 'μένα ... επιστρέφω στις κωδικογραφίες μου τώρα.

Disclaimer: Τα Ονόματα και ιδρύματα που αναφέρθησαν σε αυτό το post είναι σχεδόν fictional, και δεν υπήρχε καμμία πρόθεση να υποτιμήσω καμμία Συνεταιριστική Τράπεζα ή οποιαδήποτε συμπαθέστατη κυρία Βασιλική ( μια απ'αυτές είναι και θεία μου στην τελική ... ) :D .. και φυσικά κανένα συνδαιτήμονα DotNetZoner.

---

Angel
O:]