WinForms

Απ: Γρήγορη ανάκτηση δεδομένων

KelMan — Fri, 16 Jan 2009 03:25:24 GMT

H αλήθεια είναι ότι γλύτωσες από ένα αρχικό κόστος που αφορά στις άδειες χρήσης, ωστόσο για ένα σύστημα σαν αυτό που περιγράφεις, με ρυθμό ανάπτυξης 4GB/2μηνο, έχω την εντύπωση ότι το TCO (total cost of ownership) τελικά θα είναι αρκετά μεγάλο, τόσο που το κόστος ας πούμε της Workgroup έκδοσης που είναι φθηνή και δεν έχει περιορισμό θα είναι μερικές κλίμακες μικρότερο. 1500$ που κοστίζει χονδρικά ένας SQL Server Standard edition (και μιλάω για retail και όχι ευκαιρίες τύπου ειδικά προγράμματα, κλπ), είναι χονδρικά ένας μισθός για έναν DBA που θα απαιτείται να προσέχει τη βάση, άπαξ αυτή μεγαλώσει αρχικά και θα πρέπει να τηρούνται διαδικασίες backup/restore, indexing, κλπ. Μην παρεξηγήσεις ό,τι γράφω, απλά πολλές φορές το κόστος των αδειών χρήσης, στην πορεία του χρόνου, είναι ένα κλάσμα του κόστους του infrastructure. Θα πρέπει να συνυπολογίσεις τα features του προϊόντος που μπορούν να σου δώσουν performance και scalability. Άσχετα αν θα επιλέξεις SQL Server ή MySQL, καλό είναι να εξετάσεις τι παραπάνω σου δίνουν οι εκδώσεις που έπονται των free.

Απ: Γρήγορη ανάκτηση δεδομένων

Παναγιώτης Καναβός — Fri, 16 Jan 2009 00:50:40 GMT

Το ότι ο Connector της ίδιας της MySQL δεν παίζει ωραία με BLOB δεν σημαίνει ότι είναι για πέταμα η ίδια η βάση! Εδώ είναι που λένε Throwing out the baby with the bathwater!
Η απλούστερη λύση είναι να αγοράσεις το dotConnect της DevArt. Αν δεν θέλεις να το χρησιμοποιήσεις ίσως να υπάρχουν άλλοι μηχανισμοί για να πετύχεις αυτό που θες. Όπως σου είπε και ο Μάνος δεν είμαστε και οι ειδικοί στη MySQL. Απ' ότι βλέπω μπορείς να χρησιμοποιήσεις string manipulation functions με text πεδία. Θα μπορούσες π.χ. να χρησιμοποιήσεις την INSERT για να εισάγεις ένα μικρό string μέσα σε ένα πεδίο text. Τουλάχιστον έτσι γλυτώνεις να τραβήξεις τα δεδομένα στον client και να τα ξαναστείλεις στον server.

Αν όμως ο χειρισμός των blob είναι σημαντικός και δεις ότι δεν υπάρχει επαρκής υποστήριξη τότε ναι, αξίζει να κοιτάξεις άλλη βάση.

Απ: Γρήγορη ανάκτηση δεδομένων

Dataman — Fri, 16 Jan 2009 00:17:44 GMT

KelMan:
Τι εννοείς όταν λες "με τους περιορισμούς του";

Εννοώ τον περιορισμό στον όγκο της βάσης (4GB εάν θυμάμαι καλά).
Αυτός ήταν ένας από τους λόγους που επέλεξα MySQL.

Η εφαρμογή έχει σχεδιαστεί μεταξύ άλλων να αποθηκεύει περίπου 2100 records το λεπτό σε table 8 αριθμητικών πεδίων. Με πρόχειρο υπολογισμό με τον SQL Server θα είχα δεδομένα περίπου για 2 μήνες και το ζητούμενο είναι τουλάχιστον για ένα έτος.

Και για να σε προλάβω, υπάρχει σοβαρός λόγος που η βάση πρέπει να είναι ΜΙΑ και δεν μπορώ να την "σπάσω" έτσι ώστε να κερδίσω σε χώρο.

Απ: Γρήγορη ανάκτηση δεδομένων

KelMan — Thu, 15 Jan 2009 23:23:03 GMT

No such thing as free lunch λένε οι Άγγλοι...

Τι εννοείς όταν λες "με τους περιορισμούς του";

Απ: Γρήγορη ανάκτηση δεδομένων

Dataman — Thu, 15 Jan 2009 22:56:42 GMT

Δηλαδή εάν κατάλαβα καλά ή pay ή Sql Server Express (με τους περιορισμούς του).
Θα εκτιμηθούν ιδιαίτερα τα λεγόμενά σας, ελπίζω να μην έχω άλλες εκπλήξεις από τις δυνατότητες του MySQL ADO Connector.

Απ: Γρήγορη ανάκτηση δεδομένων

Παναγιώτης Καναβός — Thu, 15 Jan 2009 22:06:35 GMT

Δεν έθεσες δύσκολη ερώτηση, απλά έπεσες στην ημέρα που ετοίμαζα την ομιλία για το DotNetZone event! Εξάλλου μη νομίζεις ότι είμαι και ειδικός σε MySQL. Δεν την έχω δουλέψει ΠΟΤΕ. Απλά έψαξα στο site της MySQL για τις απαντήσεις. Από την άλλη, έχω δουλέψει με GIS οπότε ... μυρίστηκα τί μπορεί να συνέβαινε στην αρχική ερώτηση. Οι ερωτήσεις που κάνεις αφορούν όλες τις βάσεις και providers, το θέμα κάθε φορά είναι αν το κάνει και πως το κάνει μία βάση.

Στα longtext, longblob τώρα. Έχεις δίκιο ότι χρειάζεται κάτι άλλο πέρα από το διάβασε τα όλα, γράψε τα όλα. O provider για SQL Server περιέχει την κλάση SqlBinary με την οποία μπορείς να προσθέσεις/τροποποιήσεις bytes αλλά και να ανοίξεις ένα stream πάνω στο blob. Την ίδια τακτική ακολουθούν και όσοι άλλοι providers έχουν αυτή τη δυνατότητα. Ο MySQL Connector .... δεν την έχει. Όπως λένε σε άπταιστα μαρκετίστικα "Has no special requirements to read/write blob data". Με άλλα λόγια, no streaming.

Ευτυχώς, υπάρχουν άλλοι providers οι οποίοι το κάνουν. Δες το dotConnect for MySQL της Devart, το οποίο έχει τις κλάσεις MySqlBlob και MySqlText για να χειριστεί blob και text αντίστοιχα. Και υποστηρίζει και EF, Linq to MySQL.

Απ: Γρήγορη ανάκτηση δεδομένων

KelMan — Thu, 15 Jan 2009 21:23:26 GMT

Δύσκολα όχι, ωστόσο η ερώτησή σου αφορά σε MySQL που δεν είναι μέσα στο ...scope των γνώσεων που έχουν οι περισσότεροι χρήστες εδώ. Περισσότερες πιθανότητες έχεις να βρεις απάντηση σε κάποιο forum σχετικό με MySQL.

Απ: Γρήγορη ανάκτηση δεδομένων

Dataman — Thu, 15 Jan 2009 21:01:23 GMT

Μάλλον τώρα έθεσα δύσκολα ερωτήματα, ευχαριστώ πάντως για τις απαντήσεις.

Απ: Γρήγορη ανάκτηση δεδομένων

Dataman — Wed, 14 Jan 2009 22:31:06 GMT

Παναγιώτης Καναβός:
Ή, αν θες να ελευθερώσεις τη σύνδεση με τη βάση όσο γίνεται γρηγορότερα, να τα αποθηκεύσεις προσωρινά σε ένα string array και μετά να κάνεις το parsing.

Τελικά αυτή ήταν η καλύτερη λύση.
Αποθηκεύω όλες τις πληροφορίες σε άνα string longtext στην βάσης με λογική σειρά και φορτώνω τα στοιχεία κατά την εκκίνηση του προγράμματος.
Επίσης οτιδήποτε αλλαγή κάνω στα στοιχεία φιλτραρω και στελνω για αλλαγή μόνο τα συγκεκριμένα και έτσι έχω ταχύτητα και στην αποθήκευση (δεν έχω ολοκληρώσει ακόμη αυτήν την δυνατότητα - εξηγώ παρακάτω).

Το μόνο που αντιμετωπίζω σαν πρόβλημα (εάν μπορεί να ειπωθεί έτσι) είναι ότι όταν θέλω να ενημερώσω το πεδίο longtext το δίνω πάλι όλο μαζί, υπάρχει τρόπος να προσθέσω στοιχεία?
π.χ εάν έχω πλήθος χαρακτήρων 300.000 και θέλω να προσθέσω ένα χαρακτήρα ακόμη να δώσω μόνο τον χαρακτήρα αυτό να κάνω δηλαδή add στο πεδίο της MySQL Database, αυτή την στιγμή ξαναδίνω όλους τoυς χαρακτήρες (300.001).

Τα στοιχεία που αποθηκεύω είναι ΜΟΝΟ αριθμοί, τα αλφαριθμητικά πεδία φορτώνονται από πίνακα βάση των ids, θέλω να ρωτήσω εάν ο τύπος πεδίου longtext είναι καλύτερος από τον τύπο longblob (στην συγκεκριμένη περίπτωση) σε θέματα ταχύτητας και εάν μπορώ να κάνω συμπίεση των δεδομένων?

Απ: Γρήγορη ανάκτηση δεδομένων

Παναγιώτης Καναβός — Wed, 14 Jan 2009 04:55:32 GMT

Ρίξε μία ματιά στα spatial extensions της My SQL και ιδιαίτερα στο παράδειγμα χρήσης spatial indexes. Η MySQL υποστηρίζει τις κλάσεις του OpenGIS, δηλαδή Point, Curve, Polygon κλπ καθώς και functions όπως η MBRContains, MBRIntersects κλπ. Επιπλέον, αν χρησιμοποιείς MyISAM μπορείς να δημιουργήσεις spatial indexes βασισμένα σε R-Trees για να επιταχύνεις τις αναζητήσεις. Έτσι μπορείς να εκτελέσεις εντολές όπως η παρακάτω για να πάρεις όλα τα σχήματα που περιέχονται σε ένα πολύγωνο:

mysql> SET @poly =
-> 'Polygon((30000 15000,31000 15000,31000 16000,30000 16000,30000 15000))';
mysql> SELECT fid,AsText(g) FROM geom WHERE
-> MBRContains(GeomFromText(@poly),g);

Στην δική σου περίπτωση θα έπρεπε να χρησιμοποιήσεις μάλλον την MBRIntersects για να φορτώσεις τα αντικείμενα που τέμνονται από το παράθυρο της εφαρμογής σου και όχι μόνο όσα περιέχονται πλήρως. Με τον τρόπο αυτό θα φορτώσεις μόνο τα σχήματα που χρειάζεσαι. Αν χρειαστεί να κάνεις zoom in δεν θα χρειαστεί να ξαναφορτώσεις τα αντικείμενα. Αν κάνεις zoom out υποθέτω ότι θα μπορούσες να χρησιμοποιήσεις ένα συνδυασμό Contains στο νέο παράθυρο και Not Contains στο παλιό για να φορτώσεις πάλι μόνο τα επιπλέον αντικείμενα. Δεν είμαι σίγουρος όμως αν αυτό όντως γίνεται ή αν θα ήταν γρηγορότερο από το να φορτώσεις απλά όλα τα αντικείμενα ξανά.

Ίσως μάλιστα ο ποιό γρήγορος τρόπος να είναι να φορτώσεις τα πάντα στη μνήμη και μετά να κάνεις queries κάθε φορά που γίνεται zoom ή click για να βρεις τα ID και μόνο των σχημάτων που σε ενδιαφέρουν! Αν για παράδειγμα έχεις λίγα πολύγωνα με πολλά σημεία, είναι πολύ πιο γρήγορο να διαβάσεις τα λίγα ID από τη βάση παρά τα πολλά σημεία ένα-ένα

Από εκεί και πέρα, αφού επιλέξεις τα σχήματα που χρειάζεσαι ο γρηγορότερος τρόπος είναι να χρησιμοποιήσεις ένα DataReader για να τα φορτώσεις γραμμή-γραμμή χωρίς περαιτέρω επεξεργασία. Δεν είμαι σίγουρος πως θα φέρει τα σχήματα ο .NET adapter που χρησιμοποιείς, αλλά σίγουρα μπορείς να τα επιστρέψεις ως string μέσω της AsText και μετά να τα κάνεις parse. Ή, αν θες να ελευθερώσεις τη σύνδεση με τη βάση όσο γίνεται γρηγορότερα, να τα αποθηκεύσεις προσωρινά σε ένα string array και μετά να κάνεις το parsing.

Απ: Γρήγορη ανάκτηση δεδομένων

Dataman — Wed, 14 Jan 2009 02:53:17 GMT

Πρόκειται για GIS εφαρμογή και οι πληροφορίες που αποθηκεύω αναφέρονται σε συντεταγμένες, Line, Polygon, Shape.
Τα δεδομένα από την μνήμη φιλτράρονται ανάλογα με το επίπεδο του zoom που θέλω να εμφανίσω. Η εμφάνιση του σχεδίου στο πρόγραμμα δεν καθυστερεί καθόλου διότι τα στοιχεία είναι στη μνήμη και με κατάλληλο αλγόριθμο εμφανίζονται πολύ γρήγορα.

Το πρόβλημα είναι μέχρι να πάνε στην μνήμη.

Ο τρόπος που αποθηκεύω τα δεδομένα στην βάση MySQL είναι με μορφή int ή long και δεν υπάρχει πρόβλημα στην ταχύτητα αναζήτησης.

Μπορείς να γίνεις πιο σαφής στα spatial indexes και spatial δεδομένα?

Απ: Γρήγορη ανάκτηση δεδομένων

Παναγιώτης Καναβός — Wed, 14 Jan 2009 02:23:43 GMT

Dataman:
οι εγγραφές αυτές είναι συντεταγμένες ενός διανυσματικού σχεδίου

Τί είδους σχέδιο? Τα σημεία είναι ανεξάρτητα μεταξύ τους είναι χρησιμοποιείς σχήματα, π.χ. πολύγωνα και γραμμές? Η MySQL έχει υποστήριξη για spatial types οπότε θα μπορούσες να το εκμεταλλευτείς. Είναι πολύ σημαντικό σε μία εφαρμογή απεικόνισης, είτε πρόκειται για GIS είτε για άλλο είδος εφαρμογής, να εμφανίζεις μόνο τα στοιχεία που χρειάζονται. Αν χρησιμοποιείς πολύγωνα μπορείς να χρησιμοποιήσεις spatial queries για να δείξεις μόνο τα σχήματα τα οποία φαίνονται στο "παράθυρο" της εφαρμογής κάθε φορά και όχι ολόκληρο το σχέδιο. Αν έχεις μόνο σημεία, π.χ. συντεταγμένες από GPS, αρκεί να φτιάξεις ένα index για τις δύο συντεταγμένες και να χρησιμοποιήσεις range queries.

Το άλλο σημείο που πρέπει να προσέξεις είναι ότι δεν αρκεί να φορτώσεις τα σημεία στη μνήμη. Όπως καθυστερεί το φόρτωμα του σχεδίου από τη βάση χωρίς spatial indexes, έτσι θα καθυστερήσει και η σχεδίαση του αν πρέπει κάθε φορά να ανατρέχεις ολόκληρο τον πίνακα για να επιλέξεις τα σημεία που θα σχεδιάσεις. Θα πρέπει να χρησιμοποιήσεις κάποια διαφορετική δομή όπως quadtrees για να βρεις γρήγορα τα σχήματα που πρέπει να σχεδιάσεις. Μία αναζήτηση στο codeplex επιστρέφει αρκετές βιβλιοθήκες για spatial δεδομένα, όπως π.χ. το Sharpmap αν και τα περισσότερα projects αφορούν SQL Server 2008.

Χωρίς να ξέρουμε τί θέλεις να κάνεις δεν μπορούμε να σου πούμε ότι χρειάζεσαι ή όχι το Sharpmap, το GeoAPI.NET ή .... την OpenGL. Υπάρχουν πολλών ειδών εφαρμογές οι οποίες δουλεύουν με διανύσματα όπως αρχιτεκτονικά σχέδια, παιχνίδια και GIS. Η κάθε κατηγορία έχει διαφορετικές απαιτήσεις και αρκετές έτοιμες βιβλιοθήκες. Θα πρέπει να μας πεις τί θέλεις να κάνεις για να μπορέσουμε να σε βοηθήσουμε.

Απ: Γρήγορη ανάκτηση δεδομένων

infoCENTER — Wed, 14 Jan 2009 01:56:43 GMT

Αν τα δεδομένα τα διαβάζεις όλα όταν ξεκινάει η εφαρμογή, στην συνέχεια τα επεξεργάζεσαι στην μνήμη και πριν κλείσει η εφαρμογή τα σώζεις όλα και σε ενδιαφέρει η ταχύτητα τότε προσωπικά θα χρησιμοποιούσα Flat File και όχι κάποια βάση. Τώρα αν υπάρχουν και άλλα από πίσω τα οποία δεν έχεις αναφέρει ακόμα, όπως π.χ αναζήτηση, ταξινόμηση, διαγραφή τότε μείνε στην βάση και συμβιβάσου με την ταχύτητα που έχεις. Αν περιμένει πολύ ο χρήστης μέχρι να φορτωθούν τα δεδομένα και το UI δεν ανταποκρίνεται, δημιούργησε και ένα Thread που να φορτώνει τα δεδομένα.

Αλλά αν το σενάριο είναι απλό και η ταχύτητα για εμένα είναι το παν θα προτιμούσα flat file για αποθηκευτικό μου χώρο.

Απ: Γρήγορη ανάκτηση δεδομένων

Dataman — Wed, 14 Jan 2009 00:34:57 GMT

Βασικά είναι 100.000 και όχι 1.000.000 (λάθος πληκτρολόγησης το διόρθωσα), οι εγγραφές αυτές είναι συντεταγμένες ενός διανυσματικού σχεδίου και πρέπει να φορτώνονται όλες κατά την εκκίνηση της εφαρμογής και να είναι σε πίνακα διότι επεξεργάζονται αργότερα.

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

Απ: Γρήγορη ανάκτηση δεδομένων

Παναγιώτης Καναβός — Wed, 14 Jan 2009 00:25:01 GMT

Φόρτωμα από που και γιατί θέλεις να κρατάς 1,000,000 εγγραφές στη μνήμη και μάλιστα σε πίνακα? Υπάρχει περίπτωση ο ένας και μοναδικός χρήστης της desktop εφαρμογής να χρειαστεί και το ένα εκατομμύριο εγγραφές ?