Επιστροφή στο Forum : Αποθήκευση εικόνων σε Β.Δ.
Αχχχ... δεν είναι για πολλά-πολλά η Άξες῎ Ειδικά άμα βάλεις πάνω φωτογραφίες ...κλάταρε.
Αχχχ... δεν είναι για πολλά-πολλά η Άξες῎ Ειδικά άμα βάλεις πάνω φωτογραφίες ...κλάταρε.
ΠΟΤΕ δεν βάζεις φωτογραφίες ως binary objects, σε καμία βάση!
Η Access είναι για πολλά, πολλά, αρκεί να ξέρει κάποιος να τη χρησιμοποιεί ;)
DeadAtHeaven
20-09-05, 12:02
ΠΟΤΕ δεν βάζεις φωτογραφίες ως binary objects, σε καμία βάση!
Γιατί τόσο απόλυτος yiapap? Υπάρχουν και εφαρμογές που πρέπει οι φωτογραφίες ή μάλλον οι εικόνες να αποθηκευτούν στη βάση.
Φαντάσου να έχεις 2500 εικόνες σε ένα υποκατάλογο στο server και μια βάση για αυτές τις εικόνες σε ξεχωριστά σημεία. Θα πρέπει να ασφαλίσεις και τον υποκατάλογο και τη βάση ξεχωριστά. Φαντάσου τώρα διαφορετικές θεματικές ενότητες ανάμεσα στις εικόνες (άρα και διαφορετικούς υποκαταλόγους όπου θα πρέπει να αποθηκεύονται οι εικόνες) με ένα σωρό υποκαταλόγους. Απο τη στιγμή που ο χρήστης θα ζητήσει μια εικόνα θα πρέπει να βρείς ένα τρόπο να τη μεταφέρεις στο τερματικό του. Αν τρέχεις μια web εφαρμογή (ή έχεις ένα htmlview στο interface σου) τα πράγματα είναι εύκολα (δημιουργείς ένα IMG με url τη διαδρομή προς την εικόνα. αυτο προυποθέτει οτι θα έχεις και ένα web server βέβαια...άλλες ρυθμίσεις ασφάλειας απο 'κει)...αν τρέχεις όμως μια custom εφαρμογή θα πρέπει με κάποιο τρόπο να μετακινείς τις εικόνες, να διαχειρίζεσαι τα σφάλματα του δικτύου, κλπ. (Στη περίπτωση που οι εικόνες είναι απάνω στη βάση, όλο το κομάτι της μεταφοράς των εικόνων μέσω του δικτύου το διαχειρίζεται το API της βάσης.)
Οι εικόνες μπορούν να αποθηκευτούν στη βάση αρκεί αυτό να γίνει με προσοχή. Για παράδειγμα, μπορείς να φτιάξεις μια τελείως ξεχωριστή βάση και να αποθηκεύσεις τις εικόνες indexed με ένα ID (Δύο πεδία μόνο δηλαδή). Έτσι οι αναζητήσεις στις δύο βάσεις τρέχουν ανεξάρτητα.
Η λύση δεν είναι ιδανική αλλά έχει πολλά πλεονεκτήματα.
DeadAtHeaven,
1. Έτσι κι αλλιώς πρέπει να ασφαλίσεις τα αρχεία της βάσης... όπως και τη βάση. Αν σε ενοχλεί τόσο πολύ να δώσεις δικαιώματα σε έναν φάκελο, τι να πω...
2. Οι θεματικές ενότητες γιατί πρέπει να είναι υποφάκελλοι; Αν αποθηκεύσεις τις φωτογραφίες σε πίνακες κάνεις διαφορετικό πίνακα ανά ενότητα; Προφανώς όχι! Η θεματική ενότητα είναι attribute της φωτογραφίας και προφανώς αποθηκεύεται στον πίνακα που περιέχει το path της φωτό
3. Η μεταφορά μιας φωτογραφίας που αποθηκεύεται ως αρχείο γίνεται με μυριάδες τρόπους. Από web/ftp, file transfer γενικώς μέχρι, αν επιμένεις, custom binary transfer με μια πλειάδα αντικειμένων. Η μεταφορά μιας φωτογραφίας που αποθηκεύεται εντός της βάσης γίνεται μόνο μετά από binary ανάγνωση της βάσης.
4. Προσωπικά βρήκα πάρα πολλά αντικείμενα που απεικονίζουν εικόνες από αρχείο και... κανένα που να απεικονίζει εικόνες ΑΠΕΥΘΕΙΑΣ από βάση (αν έχεις κανένα πες μου)
5. Μέγεθος: 2500 φωτογραφίες αξιοπρεπούς ανάλυσης είναι 2.5GB. Η βάση που θα δημιουργηθεί για αναζητήσεις θα είναι ένα μονολοθικό αρχείο >2.5GB με ότι αυτό συνεπάγεται (κίνδυνος ολικής απώλειας, δυσκολία backup κτλ.κτλ.)
Εντάξει, η απολυτότητα δεν είναι σωστή, ("Ποτέ... σε καμία" :oops: ) αλλά ακόμη δεν έχω βρει εφαρμογή που θα δούλευε καλύτερα αν οι φωτό ήταν στη βάση.
DeadAtHeaven
20-09-05, 14:43
DeadAtHeaven,
1. Έτσι κι αλλιώς πρέπει να ασφαλίσεις τα αρχεία της βάσης... όπως και τη βάση. Αν σε ενοχλεί τόσο πολύ να δώσεις δικαιώματα σε έναν φάκελο, τι να πω...
Πιθανότατα το έθεσα λάθος. Αναφέρομαι σε ρυθμίσεις δικαιωμάτων ανάγνωσης / εγγραφής / διαγραφής απο διάφορους χρήστες μέσα στο σύστημα.
2. Οι θεματικές ενότητες γιατί πρέπει να είναι υποφάκελλοι; Αν αποθηκεύσεις τις φωτογραφίες σε πίνακες κάνεις διαφορετικό πίνακα ανά ενότητα; Προφανώς όχι! Η θεματική ενότητα είναι attribute της φωτογραφίας και προφανώς αποθηκεύεται στον πίνακα που περιέχει το path της φωτό
Ίσως φταίει το οτι είχα στο μυαλό μου συγκεκριμένη εφαρμογή. Τέλος πάντων, αυτό που θέλω να πώ είναι οτι η οργάνωση των εικόνων στο δίσκο θα πρέπει να ακολουθεί κατα κάποιο τρόπο την οργάνωση τους στη βάση. Αυτό για να είναι σε θέση ένας χρήστης να αναζητήσει μια εικόνα απο ένα backup ή σε περίπτωση αστοχίας του προγραμάτος, εύκολα απο το δίσκο. Ύστερα είναι και το θέμα της ονοματολογίας των εικόνων. Αν το αφήσεις στο χρήστη θα καταλήξεις με ονόματα του στύλ (zigosxraymartios.png, ultrajohn200505.png ή ακόμα χειρότερα zuzunaki.png, variemai.png, akalyptos.png, μη γελάς καθόλου :-) ) Άντε μετά απο το backup να καταλάβεις που αναφέρεται το zuzunaki (Όταν έχεις χάσει την εφαρμογή αλλά πρέπει να βρείς την εικόνα). Ενώ αν οι εικόνες είναι τακτοποιημένες σε υποκαταλόγους με συγκεκριμένη ονοματολογία -όπως θα ήταν οργανωμένες και στη βάση- μπορείς να βρείς ακριβώς αυτό που θέλεις και χωρίς την εφαρμογή (με χαμηλότερη ταχύτητα ίσως)
3. Η μεταφορά μιας φωτογραφίας που αποθηκεύεται ως αρχείο γίνεται με μυριάδες τρόπους. Από web/ftp, file transfer γενικώς μέχρι, αν επιμένεις, custom binary transfer με μια πλειάδα αντικειμένων.
Συμφωνώ για τα αντικείμενα, αλλά το θέμα είναι οτι όσο περισσότερα βάζεις τόσο πιο ευάλωτο γίνεται το πρόγραμα σε bugs που δεν μπορείς να ελέγξεις.
Η μεταφορά μιας φωτογραφίας που αποθηκεύεται εντός της βάσης γίνεται μόνο μετά από binary ανάγνωση της βάσης.
Συμφωνώ αλλά όλη αυτή τη διαδικασία θα την αναλάβει το API της βάσης.
4. Προσωπικά βρήκα πάρα πολλά αντικείμενα που απεικονίζουν εικόνες από αρχείο και... κανένα που να απεικονίζει εικόνες ΑΠΕΥΘΕΙΑΣ από βάση (αν έχεις κανένα πες μου)
Θέλει λίγη δουλειά και δεν είναι απαραίτητο να βρίσκεις τα πάντα έτοιμα (χωρίς να θέλω να υπονοήσω τίποτα). Για παράδειγμα, κάνεις το query και οτι σου επιστρέφεται το τοποθετείς σε ένα pointer στη μνήμη. Αυτός ο pointer τώρα, θα αποτελέσει μια απο
τις παραμέτρους της συνάρτησης που θα κάνει απεικόνηση στο GUI.
5. Μέγεθος: 2500 φωτογραφίες αξιοπρεπούς ανάλυσης είναι 2.5GB. Η βάση που θα δημιουργηθεί για αναζητήσεις θα είναι ένα μονολοθικό αρχείο >2.5GB με ότι αυτό συνεπάγεται (κίνδυνος ολικής απώλειας, δυσκολία backup κτλ.κτλ.)
Ίσως έχεις στο μυαλό σου την access. Το θέμα είναι οτι θα δημιουργηθεί μεν ένα μονολιθικό αρχείο αλλά θα μπορεί να προσπελαστεί πάρα πολύ γρήγορα μια και κάθε κλειδί είναι αντιστοιχισμένο σε συγκεκριμένο offset μέσα στο αρχείο. Η ολική απώλεια ελοχεύει και στη περίπτωση της αποθήκευσης των αρχείων στο δίσκο...η δυσκολία του backup συζητείται, καθώς μπορείς να κάνεις incremental backup το οποίο θα δίνει μικρές βάσεις κάθε φορά.
Εντάξει, η απολυτότητα δεν είναι σωστή, ("Ποτέ... σε καμία" :oops: ) αλλά ακόμη δεν έχω βρει εφαρμογή που θα δούλευε καλύτερα αν οι φωτό ήταν στη βάση.
Το ερώτημα είναι, αν έχεις βρεί μέχρι τώρα καμία εφαρμογή που να "πρωτοτυπεί" και να θέλει να βάλει τις εικόνες στη βάση.
Τη διαφορά έχει να κρατάω 2GB πληροφορίες σε ξεχωριστά αρχεία απο το να τις αποθηκεύω σε μια βάση; Τα επιχειρήματα της ταχύτητας αναζήτησης εξαφανίζονται σιγά σιγά...
Τέλος πάντων όπως καταλαβαίνεις δεν υπάρχει συγκεκριμένη απάντηση σε αυτό το ερώτημα αν και η σχετική συζήτηση είναι πολύ ενδιαφέρουσα :-)....θα εξαρτάται πάντα απο το πρόβλημα που καλείσαι να λύσεις.
DeadAtHeaven,
Αναφορικά με τα δικαιώματα:
Το ίδιο μπορείς να κάνεις και μέσω της προσέγγισης των αρχείων. Έτσι κι αλλιώς την επεξεργασία και τη διαγραφή θα την κάνεις μέσω εφαρμογής. Οπότε μπορείς από εκεί να διαβάσεις τα δικαιώματα της εγγραφής και να διαχειριστείς (ή όχι) την εικόνα. Η μόνη διαφορά μας είναι ότι εγώ προτείνω να προσθέσεις ένα text πεδίο με το url/unc του αρχείου ενώ εσύ προτείνεις ένα object/blob πεδίο. Δεν υπάρχει διαφορά στα δικαιώματα. Αν κάποιος δεν μπορεί να διαβάσει την εγγαρφή, δε διαβάζει το url δε διαβάζει την εικόνα. Αν η εφαρμογή σου έχει δυνατότητες επεξεργασίας (σπάνιο) τότε δε σου κάνει κόπο να γράψεις 3 σεριές κώδικα παραπάνω και να αρνηθείς την επεξεργασία. Η διαγραφή μπορεί να γίνει αντίστοιχα με άλλες 3 γραμμές ή με trigger.
Με τα filenames:
Το ίδιο δε θα γίνει αν δώσεις δικαίωμα στο χρήστη να προσθέτει την περιγραφή που θέλεις στην εικόνα; Το όνομα του αρχείου δεν έχει καμιά σημασία, αφού το βρίσκεις όπως, όπου θέλεις στη βάση και το διαχειρίζεσαι από εκεί. Δλδ μπορείς να του δώσεις κάποιο generic όνομα π.χ. 2005-01-10.png ή να αφήσεις το χρήστη να το ονοματίσει ή κάτι μικτό. Το θέμα είναι το url/unc να αποθηκευτεί στη βάση
Περί μονολιθικότητας:
Όλες οι βάσεις δεδομένων τηρούνται σε μονολιθικά αρχεία. Είτε dbf, mdb,mdx ή τα πως τα λένε της Oracle. Ένα unreadable sector και η βάση σου πάει. Αντίθετα με τα αρχεία στη χειρότερη θα χάσεις ένα από τα 2500.
Incremental backups μπορείς να έχεις μόνο σε ορισμένες από αυτές της βάσεις ενώ αν έχεις ξεχωριστά τα αρχειάκια μπορείς να κρατάς incremental backup από μια πλειάδα εξωτερικών εφαρμογών.
Περί pointer:
Ωραία, έχεις τον Pointer, μετά; Θα πρέπει να γράψεις δικό σου αντικείμενο ώστε να απεικονίσει τα δεδομένα της βάσης. Αν όμως το query σου επιστρέφει το url/unc του αρχείου, χρησιμοποιείς οποιοδήποτε image object για να τα απεικονίσει. Γι αυτό λέω ότι υπάρχει μια πλειάδα αντικειμένων. Βέβαια, αν είσαι οπαδός του Μαζόχ και θέλεις να ξαναανακαλύπτεις τον τροχό... ;)
DeadAtHeaven
20-09-05, 17:29
DeadAtHeaven,
Αν και είμαστε offtopic η συζήτηση είναι ενδαιφέρουσα οπότε τη συνεχίζω ;)
Αναφορικά με τα δικαιώματα:
Το ίδιο μπορείς να κάνεις και μέσω της προσέγγισης των αρχείων. Έτσι κι αλλιώς την επεξεργασία και τη διαγραφή θα την κάνεις μέσω εφαρμογής. Οπότε μπορείς από εκεί να διαβάσεις τα δικαιώματα της εγγραφής και να διαχειριστείς (ή όχι) την εικόνα. Η μόνη διαφορά μας είναι ότι εγώ προτείνω να προσθέσεις ένα text πεδίο με το url/unc του αρχείου ενώ εσύ προτείνεις ένα object/blob πεδίο. Δεν υπάρχει διαφορά στα δικαιώματα. Αν κάποιος δεν μπορεί να διαβάσει την εγγαρφή, δε διαβάζει το url δε διαβάζει την εικόνα. Αν η εφαρμογή σου έχει δυνατότητες επεξεργασίας (σπάνιο) τότε δε σου κάνει κόπο να γράψεις 3 σεριές κώδικα παραπάνω και να αρνηθείς την επεξεργασία. Η διαγραφή μπορεί να γίνει αντίστοιχα με άλλες 3 γραμμές ή με trigger.
Ένα blob πεδίο προτείνω συγκεκριμένα σε ένα δικό του table. Παρ' όλο που καταλαβαίνω οτι οι προσεγγίσεις είναι παρόμοιες πιστεύω οτι κανείς έχει περισσότερο έλεγχο στην υλοποίηση με τη βάση. Περισσότερο έλεγχο και πιο εύκολη υλοποίηση μαζί. Αναλογίσου οτι για κάθε επιπλέον service που προσθέτεις (web, ftp, κλπ) για τη μεταφορά δεδομένων θα πρέπει να το "ασφαλίσεις" και να το παρακολουθείς (patch, update, κλπ). Με τη βάση, κάνεις update σε ένα μέρος του συστήματος σου (Τον database server)
Με τα filenames:
Το ίδιο δε θα γίνει αν δώσεις δικαίωμα στο χρήστη να προσθέτει την περιγραφή που θέλεις στην εικόνα; Το όνομα του αρχείου δεν έχει καμιά σημασία, αφού το βρίσκεις όπως, όπου θέλεις στη βάση και το διαχειρίζεσαι από εκεί. Δλδ μπορείς να του δώσεις κάποιο generic όνομα π.χ. 2005-01-10.png ή να αφήσεις το χρήστη να το ονοματίσει ή κάτι μικτό. Το θέμα είναι το url/unc να αποθηκευτεί στη βάση
Δεκτόν. Υπάρχει όμως διαφορά ανάμεσα στη περιγραφή της εικόνας και το όνομα του αρχείου στο δίσκο. Αυτό που λέω είναι οτι αν αφήσεις την επιλογή του ονόματος στο χρήστη δεν θα μπορείς αργότερα να το αναζητήσεις σε κάποια έκτατη ανάγκη.
Περί μονολιθικότητας:
Όλες οι βάσεις δεδομένων τηρούνται σε μονολιθικά αρχεία. Είτε dbf, mdb,mdx ή τα πως τα λένε της Oracle. Ένα unreadable sector και η βάση σου πάει. Αντίθετα με τα αρχεία στη χειρότερη θα χάσεις ένα από τα 2500.
yiapap...συνεχίζεις να είσαι απόλυτος......ίσως έχεις στο μυαλό σου συγκεκριμένα συστήματα. Οι MyISAM βάσεις αποθηκεύονται στο δικό τους υποκατάλογο και ο κάθε πίνακας αποθηκεύεται σαν ένα ξεχωριστό set αρχείων. Ένα έχει κατάληξη .frm και περιέχει τη δομή του πίνακα, ένα δεύτερο έχει κατάληξη .myd και περιέχει τις πληροφορίες και ένα τρίτο έχει κατάληξη .myi και περιέχει τα indexes. Δεν θυμάμαι την αντίστοιχη οργάνωση στην Oracle αλλά και εκεί υπάρχουν περισσότερα απο ένα αρχεία για κάθε βάση
Incremental backups μπορείς να έχεις μόνο σε ορισμένες από αυτές της βάσεις ενώ αν έχεις ξεχωριστά τα αρχειάκια μπορείς να κρατάς incremental backup από μια πλειάδα εξωτερικών εφαρμογών.
Με ένα σχετικό query μέσα απο την εφαρμογή μπορείς να κάνεις incremental backup του dataset που προκύπτει.
Περί pointer:
Ωραία, έχεις τον Pointer, μετά; Θα πρέπει να γράψεις δικό σου αντικείμενο ώστε να απεικονίσει τα δεδομένα της βάσης. Αν όμως το query σου επιστρέφει το url/unc του αρχείου, χρησιμοποιείς οποιοδήποτε image object για να τα απεικονίσει. Γι αυτό λέω ότι υπάρχει μια πλειάδα αντικειμένων. Βέβαια, αν είσαι οπαδός του Μαζόχ και θέλεις να ξαναανακαλύπτεις τον τροχό... ;)
Απο τη στιγμή που έχω τον pointer έχω και την εικόνα στη μνήμη. Δεν εννοώ ένα pointer μέσα στη βάση, εννοώ ένα unsigned char *MyPointer pointer (Μάλλον έρχομαι απο άλλο "χωριό" ε; ) στα δεδομένα της εικόνας που τα έχω πάρει απο το query προς τη βάση. Μετά στέλνω τον pointer κατ' ευθείαν σε μια συνάρτηση που κάνει την απεικόνηση (Η συνάρτηση προέρχεται απο σχετικό library, οπότε ο Μαζόχ...κάθεται σπίτι του :) )
Ένα blob πεδίο προτείνω συγκεκριμένα σε ένα δικό του table. Παρ' όλο που καταλαβαίνω οτι οι προσεγγίσεις είναι παρόμοιες πιστεύω οτι κανείς έχει περισσότερο έλεγχο στην υλοποίηση με τη βάση. Περισσότερο έλεγχο και πιο εύκολη υλοποίηση μαζί. Αναλογίσου οτι για κάθε επιπλέον service που προσθέτεις (web, ftp, κλπ) για τη μεταφορά δεδομένων θα πρέπει να το "ασφαλίσεις" και να το παρακολουθείς (patch, update, κλπ). Με τη βάση, κάνεις update σε ένα μέρος του συστήματος σου (Τον database server)
Δεν κατάλαβα που κολλάει το άλλο service. Αφού σου είπα UNC... Τα αρχεία εικόνων μπορείς να τα έχεις στον db server σε κάποιο ξεχωριστό φάκελο
Δεκτόν. Υπάρχει όμως διαφορά ανάμεσα στη περιγραφή της εικόνας και το όνομα του αρχείου στο δίσκο. Αυτό που λέω είναι οτι αν αφήσεις την επιλογή του ονόματος στο χρήστη δεν θα μπορείς αργότερα να το αναζητήσεις σε κάποια έκτατη ανάγκη.Προφανώς, όσο λιγότερα αφήνεις στη διακριτική ευχέρεια του χρήστη τόσο καλύτερα. Όμως δεν καταλαβαίνω σε ποια έκτακτη ανάγκη δε θα μπορέσεις να αναζητήσεις την εικόνα... όταν μπορείς να τη δεις από οποιαδήποτε εφαρμογή! Αντιπαράβαλε το παραπάνω με το τι θα γίνει αν υπάρξει "έκτακτη ανάγκη" στη Β.Δ.
yiapap...συνεχίζεις να είσαι απόλυτος......ίσως έχεις στο μυαλό σου συγκεκριμένα συστήματα. Οι MyISAM βάσεις αποθηκεύονται στο δικό τους υποκατάλογο και ο κάθε πίνακας αποθηκεύεται σαν ένα ξεχωριστό set αρχείων. Ένα έχει κατάληξη .frm και περιέχει τη δομή του πίνακα, ένα δεύτερο έχει κατάληξη .myd και περιέχει τις πληροφορίες και ένα τρίτο έχει κατάληξη .myi και περιέχει τα indexes. Δεν θυμάμαι την αντίστοιχη οργάνωση στην Oracle αλλά και εκεί υπάρχουν περισσότερα απο ένα αρχεία για κάθε βάσηlol... σκεφτόμουν να προσθέσω "δεν ξέρω μόνο για τη δομή της MySQL"... αλλά με πρόλαβες. Επαναλαμβάνω ότι η συνηθέστερη οργάνωση είναι ένα αρχείο ανά βάση... άντε και άλλο ένα για τα indexes. Σου έδωσα ως παραδείγματα: Όλες τις DBASE, την Access, τον SQL Server και κατά 99% (διορθώστε με) την Oracle.
Με ένα σχετικό query μέσα απο την εφαρμογή μπορείς να κάνεις incremental backup του dataset που προκύπτει.Όχι σε Access, όχι σε DBASE
Απο τη στιγμή που έχω τον pointer έχω και την εικόνα στη μνήμη. Δεν εννοώ ένα pointer μέσα στη βάση, εννοώ ένα unsigned char *MyPointer pointer (Μάλλον έρχομαι απο άλλο "χωριό" ε; ) στα δεδομένα της εικόνας που τα έχω πάρει απο το query προς τη βάση. Μετά στέλνω τον pointer κατ' ευθείαν σε μια συνάρτηση που κάνει την απεικόνηση (Η συνάρτηση προέρχεται απο σχετικό library, οπότε ο Μαζόχ...κάθεται σπίτι του :) )lol μάλλον έρχεσαι από άλλο χωριό πραγματικά
Εγώ σκεφτόμουν τα image controls των Windows που τα πετάς σε μια φόρμα (σε οποιαδήποτε visual γλώσσα προγραμματισμού), αλλάζεις το property .Image .Picture .Whatever ή χρησιμοποιείς κάποια μέθοδό του με όρισμα το fullpath προς την εικόνα. :rolleyes:
DeadAtHeaven
20-09-05, 19:09
Δεν κατάλαβα που κολλάει το άλλο service. Αφού σου είπα UNC... Τα αρχεία εικόνων μπορείς να τα έχεις στον db server σε κάποιο ξεχωριστό φάκελο
Οπότε εννοείς οτι τη σύνδεση και τη μεταφορά θα την αναλάβει το λειτουργικό;
Προφανώς, όσο λιγότερα αφήνεις στη διακριτική ευχέρεια του χρήστη τόσο καλύτερα. Όμως δεν καταλαβαίνω σε ποια έκτακτη ανάγκη δε θα μπορέσεις να αναζητήσεις την εικόνα... όταν μπορείς να τη δεις από οποιαδήποτε εφαρμογή! Αντιπαράβαλε το παραπάνω με το τι θα γίνει αν υπάρξει "έκτακτη ανάγκη" στη Β.Δ.
Δεκτόν, έχεις δίκιο. Το συγκεκριμένο πλεονέκτημα δεν το είχα σκεφτεί.
Σου έδωσα ως παραδείγματα: Όλες τις DBASE, την Access, τον SQL Server και κατά 99% (διορθώστε με) την Oracle.
Όχι στην Oracle...
Όχι σε Access, όχι σε DBASE
Και πάλι αναφέρομαι σε μια εφαρμογή που χρησιμοποιεί μια βάση.
lol μάλλον έρχεσαι από άλλο χωριό πραγματικά
Εγώ σκεφτόμουν τα image controls των Windows που τα πετάς σε μια φόρμα (σε οποιαδήποτε visual γλώσσα προγραμματισμού), αλλάζεις το property .Image .Picture .Whatever ή χρησιμοποιείς κάποια μέθοδό του με όρισμα το fullpath προς την εικόνα. :rolleyes:
Δεκτόν. Αυτός είναι ένας τρόπος για απεικόνηση. Απο την άλλη μεριά, επειδή έχω στο νού μου μια εφαρμογή στην οποία κάνεις και επεξεργασία της εικόνας μέσω συναρτήσεων κάποιας σχετικής βιβλιοθήκης είναι λογικό να χρησιμοποιήσει κανείς τις συναρτήσεις αυτής της βιβλιοθήκης. Γι αυτό άλλωστε μιλάω και για δείκτες κλπ.
Οπότε εννοείς οτι τη σύνδεση και τη μεταφορά θα την αναλάβει το λειτουργικό;Σε συνδυασμό με την εφαρμογή σου, ναι.
Δεκτόν. Αυτός είναι ένας τρόπος για απεικόνηση. Απο την άλλη μεριά, επειδή έχω στο νού μου μια εφαρμογή στην οποία κάνεις και επεξεργασία της εικόνας μέσω συναρτήσεων κάποιας σχετικής βιβλιοθήκης είναι λογικό να χρησιμοποιήσει κανείς τις συναρτήσεις αυτής της βιβλιοθήκης. Γι αυτό άλλωστε μιλάω και για δείκτες κλπ.
Είδες... να ένας λόγος που δεν είχα σκεφτεί... Και μάλιστα το είχα σχεδόν αποκλείσει σε μια από τις απαντήσεις μου :)
Ναι, αν χρειάζεται να κάνεις επεξεργασία της εικόνας τότε πιθανότητα σε βολεύει να την έχεις ως blob που διαβάζεται και παραμένει στη μνήμη για επεξεργασία έως ότου αποφασίσεις το commit στη βάση.
DeadAtHeaven
21-09-05, 15:55
Σε συνδυασμό με την εφαρμογή σου, ναι.
:-\ Ενδιαφέρον, θα του ρίξω μια ματια.
Είδες... να ένας λόγος που δεν είχα σκεφτεί... Και μάλιστα το είχα σχεδόν αποκλείσει σε μια από τις απαντήσεις μου :)
Ναι, αν χρειάζεται να κάνεις επεξεργασία της εικόνας τότε πιθανότητα σε βολεύει να την έχεις ως blob που διαβάζεται και παραμένει στη μνήμη για επεξεργασία έως ότου αποφασίσεις το commit στη βάση.
Μου φαίνεται θα κάνω split το διαλογό μας σε καινούργιο νήμα ;)
Λοιπόν, ΟΚ, ξεκινάμε την υλοποίηση; :-) :-)
DeadAtHeaven,
ερώτηση: όταν γίνεται επεξεργασία (και αποθήκευση) μιας εικόνας το πρωτότυπο χάνεται; ( δε διατηρούνται εκδόσεις της κάθε εικόνας δλδ; )
DeadAtHeaven
21-09-05, 18:46
DeadAtHeaven,
ερώτηση: όταν γίνεται επεξεργασία (και αποθήκευση) μιας εικόνας το πρωτότυπο χάνεται; ( δε διατηρούνται εκδόσεις της κάθε εικόνας δλδ; )
Η σύντομη απάντηση είναι ναι.
Αυτού του είδους τις λειτουργίες θα πρέπει να τις υλοποιήσει κανείς. Όπως για παράδειγμα το [πολλαπλό] undo είναι μια λειτουργία που υλοποιείται στις εφαρμογές.
yiapap version control στις εικόνες, στη περίπτωση που είναι αποθηκευμένες στη βάση γίνεται πολύ εύκολα με ένα trigger και αποθηκεύεις το ID της εικόνας, το ID του version, [πιθανότατα την ημερομηνία] και βέβαια την εικόνα την ίδια. Το trigger θα γίνεται απο το insert query της διόρθωσης. Λέμε τώρα....απλή παρατήρηση :-)
Η σύντομη απάντηση είναι ναι.
Αυτού του είδους τις λειτουργίες θα πρέπει να τις υλοποιήσει κανείς. Όπως για παράδειγμα το [πολλαπλό] undo είναι μια λειτουργία που υλοποιείται στις εφαρμογές.
οk.
yiapap version control στις εικόνες, στη περίπτωση που είναι αποθηκευμένες στη βάση γίνεται πολύ εύκολα με ένα trigger και αποθηκεύεις το ID της εικόνας, το ID του version, [πιθανότατα την ημερομηνία] και βέβαια την εικόνα την ίδια. Το trigger θα γίνεται απο το insert query της διόρθωσης. Λέμε τώρα....απλή παρατήρηση :-)
Ίσως και το user/client id που έκανε την τελευταία αλλαγή ( ; ).
Η σύντομη απάντηση είναι ναι.
Αυτού του είδους τις λειτουργίες θα πρέπει να τις υλοποιήσει κανείς. Όπως για παράδειγμα το [πολλαπλό] undo είναι μια λειτουργία που υλοποιείται στις εφαρμογές.
yiapap version control στις εικόνες, στη περίπτωση που είναι αποθηκευμένες στη βάση γίνεται πολύ εύκολα με ένα trigger και αποθηκεύεις το ID της εικόνας, το ID του version, [πιθανότατα την ημερομηνία] και βέβαια την εικόνα την ίδια. Το trigger θα γίνεται απο το insert query της διόρθωσης. Λέμε τώρα....απλή παρατήρηση :-)
To ίδιο trigger μπορεί να κρατά πολλαπλά αντίγραφα του φυσικού αντίγραφου εικόνας με τη version είτε ενσωματωμένη στο filename, είτε στις ιδιότητες εφόσον αυτό υποστηρίζεται από το είδος του αρχείου (π.χ. EXIF σε jpg) :p
<split by yiapap 21/9 19.50>
DeadAtHeaven
22-09-05, 12:24
To ίδιο trigger μπορεί να κρατά πολλαπλά αντίγραφα του φυσικού αντίγραφου εικόνας με τη version είτε ενσωματωμένη στο filename, είτε στις ιδιότητες εφόσον αυτό υποστηρίζεται από το είδος του αρχείου (π.χ. EXIF σε jpg) :p
Έτσι θα πρέπει να δημιουργήσεις ένα αντίγραφο του αρχείου (Με μια εντολή που θα εξαρτάται απο το λειτουργικό) και να του δώσεις ένα νέο κατάλληλο όνομα. Είναι δεν είναι η version ενσωματομένη στα metadata του αρχείου, αυτό θα πρέπει να έχει ένα νέο κατάλληλο όνομα.
Έτσι θα πρέπει να δημιουργήσεις ένα αντίγραφο του αρχείου (Με μια εντολή που θα εξαρτάται απο το λειτουργικό) και να του δώσεις ένα νέο κατάλληλο όνομα. Είναι δεν είναι η version ενσωματομένη στα metadata του αρχείου, αυτό θα πρέπει να έχει ένα νέο κατάλληλο όνομα.
Με μπερδεύεις... Αυτό δε λέω κι εγώ;
Όσο για το εξαρτάται από το λειτουργικό... Θεωρώ τόση ώρα ότι δε μιλάμε για cross-platform εφαρμογή! Άλλωστε και οι συναρτήσεις επεξεργασίας/απεικόνισης που αναφέρεις δε νομίζω ότι είναι cross platform.
Όλες τις DBASE, την Access, τον SQL Server και κατά 99% (διορθώστε με) την Oracle.
Οχι. H Oracle απέχει μακράν.... Χρησιμοποιεί αρχεία, (αν θέλεις και όχι, πας με raw partitions :D ) και χτίζεις tablespaces, ένα δικό της virtual file system για να το πούμε απλά.
Περί μονολιθικότητας:
Όλες οι βάσεις δεδομένων τηρούνται σε μονολιθικά αρχεία. Είτε dbf, mdb,mdx ή τα πως τα λένε της Oracle. Ένα unreadable sector και η βάση σου πάει. Αντίθετα με τα αρχεία στη χειρότερη θα χάσεις ένα από τα 2500.
Incremental backups μπορείς να έχεις μόνο σε ορισμένες από αυτές της βάσεις ενώ αν έχεις ξεχωριστά τα αρχειάκια μπορείς να κρατάς incremental backup από μια πλειάδα εξωτερικών εφαρμογών.
Παιδιά, η ORACLE απέχει μακράν. Και το μισό αρχείο να είναι κατεστραμένο, εαν δεν διαβάζει στα συγκεκριμένα blocks, δεν θα σου κολλήσει (θα σου πετάει warnings ίσως). Ασε που μπορείς να κάνεις block based recovery απο τα backups (που σαν σωστος DBA πάντα κρατάς :D ). Πέστε μου μια άλλη βάση που το κάνει αυτό. Και μάλιστα online με τους χρήστες επάνω....
DeadAtHeaven
22-09-05, 14:38
Με μπερδεύεις... Αυτό δε λέω κι εγώ;
Όσο για το εξαρτάται από το λειτουργικό... Θεωρώ τόση ώρα ότι δε μιλάμε για cross-platform εφαρμογή! Άλλωστε και οι συναρτήσεις επεξεργασίας/απεικόνισης που αναφέρεις δε νομίζω ότι είναι cross platform.
OK yiapap δεν αντιλέω, απλά διευκρίνησα ένα δύο πράγματα. Όσο για το cross platform...δεν σκέφτομαι κάποια συγκεκριμένη πλατφόρμα στη διάρκεια της συζήτησης μας. Οι συναρτήσεις που αναφέρω μπορούν να προέρχονται απο κάποια βιβλιοθήκη η οποία να είναι cross platform (Όπως αυτές της intel για παράδειγμα)
anon, έχω την εντύπωση οτι η Oracle ίσως θα πρέπει να κατατάσετε σε δική της κατηγορία RDBMS με τόσες δυνατότητες που προσφέρει. :-)
OK yiapap δεν αντιλέω, απλά διευκρίνησα ένα δύο πράγματα. Όσο για το cross platform...δεν σκέφτομαι κάποια συγκεκριμένη πλατφόρμα στη διάρκεια της συζήτησης μας. Οι συναρτήσεις που αναφέρω μπορούν να προέρχονται απο κάποια βιβλιοθήκη η οποία να είναι cross platform (Όπως αυτές της intel για παράδειγμα)
anon, έχω την εντύπωση οτι η Oracle ίσως θα πρέπει να κατατάσετε σε δική της κατηγορία RDBMS με τόσες δυνατότητες που προσφέρει. :-)
Νομίζω ότι άδικα το πολεμάτε. Στον προγραμματισμό, υπάρχουν πολλοί τρόποι για να καταφέρεις κάτι, και ανάλογα με την περίπτωση μπορει να υπάρχει ένας ή και περισσότεροι πολύ καλλοί τρόποι για να το πετύχεις. Εξαρτάται και με ποιές τεχνολογίες είσαι εξοικειωμένος.
Τώρα για την ORACLE, είναι ακριβή, πιστεύω πολύ ακριβή, αλλά το συμβόλαιο της είναι φθηνότερο απο την MS. Για εταιρίες που στηρίζονται εκεί τα δεδομένα τους, δεν το συζητώ. Αξίζει τα λεφτά της και με το παραπάνω (συγκριτικά την MS την πληρώνεις εκ νέου καθε τρία χρόνια, ενώ την Oracle κάθε 4-5 χρόνια, μιλάω για συμβόλαιο).
Και οι δυο επιλογές έχουν τα υπέρ τους και τα κατά τους. Με το να κρατάς τις εικόνες μέσα στη βάση, κάνει αρκετά πιο εύκολη τη διαχείρισή τους, απ'ότι ξεχωριστά (στο fs). Επίσης έχει αυξημένο data integrity. Φαντάσου να πάει κάποιος στον Windows Explorer και να κάνει move καταλάθος (που δεν είναι και σπάνιο φαινόμενο) ένα folder με εικόνες σε άλλο σημείο! Αντιθέτως, αν πάει κάποιος κατά λάθος να σβήσει εγγραφές, άντε να του χτυπήσει στο foreign key integrity check.
Εγώ πάντως είμαι υπέρ του να αποθηκεύονται σε βάση, ιδίως όταν πρόκειται για μικρές και πολλές.
anon, έχω την εντύπωση οτι η Oracle ίσως θα πρέπει να κατατάσετε σε δική της κατηγορία RDBMS με τόσες δυνατότητες που προσφέρει. :-)
H Oracle είναι η νέα Microsoft (άντε μαζί με τη Google) ... ουσιαστικά είναι μονοπώλιο...
Όντως έχει πολλά κόλπα αλλά είναι πολύ βαριά σε σχέση με άλλες... και οι εξτρα δυνατότητες έχουν προβληματάκια συχνά (βλέπε java in the database)
Σαν δυνατό παίκτη βλέπω και τη SYbase που έχει πολύ financial sector στην Αμερική. Φαίνεται αρκετά αξιόπιστη και γρήγορη και αρκετά πιο φτηνή (απ'ότι φαίνεται στο eshop.sybase.com) και έχει και free for production linux version.
H Oracle είναι η νέα Microsoft (άντε μαζί με τη Google) ... ουσιαστικά είναι μονοπώλιο...
Oracle, DB2, MS SQL Server, MySQL, PostrgreSQL και ένα σωρό άλλες. Πού είναι το μονοπώλειο? :what:
Σαν δυνατό παίκτη βλέπω και τη SYbase που έχει πολύ financial sector στην Αμερική. Φαίνεται αρκετά αξιόπιστη και γρήγορη και αρκετά πιο φτηνή (απ'ότι φαίνεται στο eshop.sybase.com) και έχει και free for production linux version. Σοβαρά το λες αυτό?? :eek: Δυνατός παίχτης η Sybase??? Με τον Adaptive Server να έχει όλο προβλήματα? Με τα εργαλεία του κώλου που διαθέτει??? Μη μου πεις πως το Sybase Central ή το SQL Advantage είναι σοβαρά εργαλεία...
Σαν δυνατό παίκτη βλέπω και τη SYbase που έχει πολύ financial sector στην Αμερική. Φαίνεται αρκετά αξιόπιστη και γρήγορη και αρκετά πιο φτηνή (απ'ότι φαίνεται στο eshop.sybase.com) και έχει και free for production linux version.
Μάλλον δεν ασχολείσαι με βάσεις δεδομένων. Η Sybase είναι παλια ιστορία, και στις αρχές του 90, που η Microsoft δεν είχε κάτι αξιόλογο για τα Windows Server πρότεινε στην Sybase να κάνουν συνεργασία. και η Sybase πιάστηκε κορόιδο!!! Πήρε τον κώδικα η Microsoft και έβγαλε τη δικιά της βάση. H Sybase είχε τότε καλές ταχύτητες σε σχέση με τον ανταγωνισμό (βλ Oracle) αλλά μάπα εργαλεία διαχείρησης. Πήρε λοιπόν τον πυρήνα της Sybase, γιαυτό τρέχει Transact SQL όπως και η sybase, έβαλε καλύτερα εργαλεία, βελτιστοποίησε τον πυρήνα της βάσης και πέταξε έξω απο την αγορά τω Windows την Sybase. Αυτά για την ιστορία. Οχι ότι είναι κακή βάση, απλά έμεινε λίγο πίσω σε σχέση με τις υπόλοιπες λόγω κακών επιλογών, και έχει συνεχώς συρικνούμενο αγοραστικό κοινό.
Μάλλον δεν ασχολείσαι με βάσεις δεδομένων.Κάνεις μεγάλο λάθος.
Η Sybase είναι παλια ιστορία, και στις αρχές του 90, που η Microsoft δεν είχε κάτι αξιόλογο για τα Windows Server πρότεινε στην Sybase να κάνουν συνεργασία. και η Sybase πιάστηκε κορόιδο!!! Πήρε τον κώδικα η Microsoft και έβγαλε τη δικιά της βάση. H Sybase είχε τότε καλές ταχύτητες σε σχέση με τον ανταγωνισμό (βλ Oracle) αλλά μάπα εργαλεία διαχείρησης. Πήρε λοιπόν τον πυρήνα της Sybase, γιαυτό τρέχει Transact SQL όπως και η sybase, έβαλε καλύτερα εργαλεία, βελτιστοποίησε τον πυρήνα της βάσης και πέταξε έξω απο την αγορά τω Windows την Sybase. Αυτά για την ιστορία. Οχι ότι είναι κακή βάση, απλά έμεινε λίγο πίσω σε σχέση με τις υπόλοιπες λόγω κακών επιλογών, και έχει συνεχώς συρικνούμενο αγοραστικό κοινό.Την ξέρω την ιστορία της Sybase, δε χρειάζομαι υπενθύμιση... Καταλαβαίνω πολύ καλά την ...ουστιά που της έκανε η M$.
Αυτό όμως δε με πείθει για να βάλω Sybase. Αυτό που με νοιάζει δεν είναι το ποιά ήταν η Sybase στο παρελθόν αλλά τι κάνει τώρα. Και αυτό που ξέρω (πολύ καλά) είναι το ότι κάθομαι εγώ (και ένας συνάδελφος) και διορθώνουμε συνέχεια προβλήματα στα συστήματα που τρέχουν Sybase και φιλοξενούν παλιές εφαρμογές μας (γραμμένες σε PowerBuilder). Όχι και να τρέχω όλη την ώρα επειδή η Sybase κάποτε ήταν μεγάλη...
Κάνεις μεγάλο λάθος.
Την ξέρω την ιστορία της Sybase, δε χρειάζομαι υπενθύμιση... Καταλαβαίνω πολύ καλά την ...ουστιά που της έκανε η M$
Αναφερόμουν στον cyberp αν πρόσεξες απο το quote
Αναφερόμουν στον cyberp αν πρόσεξες απο το quote
Οου, σορρυ man :sorry:
Σε αυτά πάντως που γράφω για τη Sybase, πιστεύω πως συμφωνείς και εσύ ούτως ή άλλως.
Οου, σορρυ man :sorry:
Σε αυτά πάντως που γράφω για τη Sybase, πιστεύω πως συμφωνείς και εσύ ούτως ή άλλως.
Απολύτως. Εγώ ξεκίνησα στις βάσεις με Sybase και τότε η Oracle μου φαινόταν παρανοικά στρυφνή (μιλάμε για 94/95). Αλλά αφού πήρα και την σχετική εκπαίδευση σε Oracle είδα ότι υπάρχει σημαντική διαφορά μεταξύ των δύο. Δυστυχώς είναι πολύ ακριβή, αλλά σε αντίθεση με την Micro$oft κάνει πολύ σοβαρή δουλειά. Και θέλει πολύ δουλειά για να την μάθεις (δεν είναι plug 'n pray).
Oracle, DB2, MS SQL Server, MySQL, PostrgreSQL και ένα σωρό άλλες. Πού είναι το μονοπώλειο? :what:
Αυτό είναι επιχείρημα??? Και OS's υπάρχουν πολλά, αλλά....
Για δέστε τι γίνεται εκεί έξω...Διαγωνισμοι δημοσίου "φωτογραφίζουν" Oracle :thumbdown
Σοβαρά το λες αυτό?? :eek: Δυνατός παίχτης η Sybase??? Με τον Adaptive Server να έχει όλο προβλήματα? Με τα εργαλεία του κώλου που διαθέτει??? Μη μου πεις πως το Sybase Central ή το SQL Advantage είναι σοβαρά εργαλεία...
Προβλήματα?? Μάλλον έχεις μείνει πίσω...
Παλιότερα είχε, οκ.. αλλά και όλες οι βάσεις δεν έχουν?? Γιατί βγάζουν όλες patches??
Εγώ δεν είπα πουθενά ότι είναι η Sybase καλύτερη... ούτε ότι έχει καλά εργαλεία...
Απλά εννοούσα ότι αρχίζει να ανεβαίνει συνέχεια είναι σταθερή από την έκδοση 11.5 και μετά και υποστηρίζει και αρκετά το Linux.. ήταν η πρώτη (απ΄τις εμπορικές) που έβγαλε έκδοση για Linux.
Δεν καταλαβαίνω γιατί μιλάτε τόσο φανατικά...
Μάλλον δεν ασχολείσαι με βάσεις δεδομένων.Το προσπερνάω!!
Η Sybase είναι παλια ιστορία, και στις αρχές του 90, που η Microsoft δεν είχε κάτι αξιόλογο για τα Windows Server πρότεινε στην Sybase να κάνουν συνεργασία. και η Sybase πιάστηκε κορόιδο!!! Πήρε τον κώδικα η Microsoft και έβγαλε τη δικιά της βάση. H Sybase είχε τότε καλές ταχύτητες σε σχέση με τον ανταγωνισμό (βλ Oracle) αλλά μάπα εργαλεία διαχείρησης. Πήρε λοιπόν τον πυρήνα της Sybase, γιαυτό τρέχει Transact SQL όπως και η sybase, έβαλε καλύτερα εργαλεία, βελτιστοποίησε τον πυρήνα της βάσης και πέταξε έξω απο την αγορά τω Windows την Sybase. Αυτά για την ιστορία. Οχι ότι είναι κακή βάση, απλά έμεινε λίγο πίσω σε σχέση με τις υπόλοιπες λόγω κακών επιλογών, και έχει συνεχώς συρικνούμενο αγοραστικό κοινό.
To ότι έκανε τεράστια λάθη στο μαρκετινγκ δεν αλλάζει κάτι...
Για το ότι η Μ$ βελτιστοποίησε τον πηρύνα διαφωνώ... τον άλλαξε, ναι...έβαλε κάποια νέα features, αλλά και η Sybase δεν έχει μείνει πίσω τεχνολογικά...
Δεν πρέπει ποτέ να είμαστε απόλυτοι... Χρησιμοποιούμε ότι μας συμφέρει (χρονικά/κόστος) ανάλογα με την περίπτωση/εφαρμογή..
Μπορεί σε μια περίπτωση να είναι καλύτερη η Mysql, σε άλλη η Oracle και σε άλλη η Sybase...
Αυτό είναι επιχείρημα??? Και OS's υπάρχουν πολλά, αλλά....
Για δέστε τι γίνεται εκεί έξω...Διαγωνισμοι δημοσίου "φωτογραφίζουν" Oracle :thumbdown Ναί, αλλά η πίτα μοιράζεται σε πολλούς (M$, Oracle, DB2 κλπ). Μονοπώλειο σημαίνει όταν μια εταιρεία καλύπτει σχεδόν όλο το μερίδιο της αγοράς (και το εκμεταλλεύεται).
Προβλήματα?? Μάλλον έχεις μείνει πίσω...Θες να σε συνδέσω να μιλήσεις με τους admins? Πάρε πρώτα μια ανάσα όμως...
Απλά εννοούσα ότι αρχίζει να ανεβαίνει συνέχεια είναι σταθερή από την έκδοση 11.5Πρέπει να φτάσει στην 11.5 έκδοση για να σταθεροποιηθεί? Εγώ πάντως μιλάω για 11. Τώρα με 0.5 τι να άλλαξε άραγε? :what:
Ναί, αλλά η πίτα μοιράζεται σε πολλούς (M$, Oracle, DB2 κλπ). Μονοπώλειο σημαίνει όταν μια εταιρεία καλύπτει σχεδόν όλο το μερίδιο της αγοράς (και το εκμεταλλεύεται).Πρόσεξε δεν είπα ότι είναι μονοπώλιο...Είπα ουσιαστικά...Βλέπω τι γίνεται στην αγορά και ειδικά στην Ελληνική... Και φυσικά το εκμεταλλεύεται, γι'αυτό είναι και πανάκριβη. H IBM κάνει τεράστιες εκπτώσεις για να πάρει μερίδιο..Όταν η Oracle θα αρχίσει να έχει ουσιαστικό ανταγωνισμό, τότε θα ρίξει και τις τιμές...
Θες να σε συνδέσω να μιλήσεις με τους admins? Πάρε πρώτα μια ανάσα όμως...
Πρέπει να φτάσει στην 11.5 έκδοση για να σταθεροποιηθεί? Εγώ πάντως μιλάω για 11. Τώρα με 0.5 τι να άλλαξε άραγε? :what:H 11 βγήκε πριν 9 χρόνια!!
Τώρα βρίσκεται στην έκδοση 15. Η σειρά είναι:11, 11.5, 11.9.2, 12.0, 12.5, 15 :rtfm:
Η ORACLE είναι πολύ ακριβή, αλλά αυτό συμβαίνει γιατι δυστυχώς δεν την πιάνει κανείς. Σε μεγάλες εγκαταστάσεις και mission critical ουσιαστικά δεν υπάρχει ανταγωνισμός. Και για την ακρίβεια κάποια στιγμή πριν δύο ή τρία χρόνια, αύξησε (!!!!) τις τιμές. Υπάρχει η DB2 αλλά αυτή πιάνει μεγάλο μερίδιο εγκατεστημένων RDBMS λόγω των mainframes.
Είναι μονοπόλιο; Και ναί και όχι. Η διαφορά σε σχέση για παράδειγμα με την Microsoft είναι ότι δεν έχει το 95% αλλά περίπου στο 30%, και το λογισμικό της είναι πραγματικά κλάσεις ανώτερο. Δεν κατακρίνω τις άλλες βάσεις δεδομένων, και μην αρχίσει flaming σχετικό. Οι καλες βάσεις δεδομένων που γνωρίζουν ανάπτυξη έχουν κάποιο λόγο που βρίσκονται εκεί. Η MySQL είναι απλή και πολύ γρήγορη (και free), η PostgreSQL είναι επίσης free και με περισσότερες δυνατότητες, η MS SQL Server είναι γιαυτούς που είναι Microsoft only ώστε να έχουν ομογενοποιημένο περιβάλλον και με μια καλή βάση δεδομένων (θυμηθείται ότι είναι βασικά Sybase) με σχετικό μικρή ανάγκη για dba, η ORACLE είναι για αυτούς unixάδες (linuxάδες) κυρίως (παίζει και σε πολλά άλλα περιβάλλοντα) και είναι με πολλές δυνατότητες αλλά και απαιτήσεις για καλό dba και mission critical, η db2 στα δικά της συστήματα κυρίως. Και υπάρχουν και πολλές άλλες, με μικρότερο ποσοστό που καλύπτουν ειδικότερες ανάγκες (πχ η SAP DB, τώρα άλλαξε όνομα, κανονική RDBMS που υποστηριζόταν κατευθείαν απο το SAP και free. Τώρα θα πάς να βάλεις SAP και να πληρωσεις ταααα φραγκα, και θα λυπηθείς να στήσεις μια Oracle;).
Τώρα όσον αφορά την φωτογράφιση.... Θυμάμαι χαρακτηριστικά ότι η Sybase δεν είχε row-level locking την δεκαετία του 90. Ενώ οι περισσότεροι στον ανταγωνισμό το είχαν. Είχe page level locking. Και η θεωρία ήταν όταν κάνεις καλό προγραμματισμό, δεν πέφτεις σε ανάγκη row-level locking. Ξέρεις πόσο πολύ στοίχησε στην Sybase αυτό; Και πόσο πολύ έμεινε σε αυτή την λογική; Εχει η sybase τις δυνατότητες που έχει η Oracle και την φωτογραφίζουν όπως λές; Μήπως είναι κρίσημες δυνατότητες; Για μένα που κάνω και τον DBA, το recoverability της βάσης και οι δυνατότητες failover είναι πολύ πιο σημαντικές απο το να τρέχει ένα query κατα 10 δεύτερα πιο γρήγορα (αν και σε αυτό επίσης είναι πολύ καλή σε σχέση με το ανταγωνισμό).
Αυτη την στιγμή η Sybase τρέχει να πιάσει τον ανταγωνισμό. Πρέπει να έχει ένα μερίδιο μικρότερο απο 5% της αγοράς. Οι περισσότεροι γυρνάνε σε MS SQL Server, ο οποίος τρέχει τον transact sql με ελάχιστες έως καθόλου παρεμβάσεις και το ξέρω απο πρώτο χέρι, απο εταιρία που κάνει ακριβώς αυτη την δουλειά. Στα Windows σαφώς η MS SQL έχει ξεπεράσει την Sybase, αν και έχουν την ίδια βάση, με καλύτερα εργαλεία και ενοποιημένο περιβάλλον με τα Windows. Στα Unix/Linux η ORACLE με την ιδιαίτερη προτίμηση στο Linux, είναι η προτιμόμενη commercial RDBMS και αυτό με λόγο και αιτία.
Για το ότι η Μ$ βελτιστοποίησε τον πηρύνα διαφωνώ... τον άλλαξε, ναι...έβαλε κάποια νέα features, αλλά και η Sybase δεν έχει μείνει πίσω τεχνολογικά...
το σημαντικότερο που έβαλε πρώτα απο όλα η Microsoft ήταν το row-level locking.
Αντε Larry, για κατέβασε τις τιμές γιατί έτσι όπως το πάς, θα σε φάνε λάχανο οι free πριν το καταλάβεις (για του λόγου το αληθές γουγλάρετε fyracle :cool: ).
H Oracle είναι η νέα Microsoft (άντε μαζί με τη Google) ... ουσιαστικά είναι μονοπώλιο...
Πρόσεξε δεν είπα ότι είναι μονοπώλιο...Είπα ουσιαστικά...Διαψεύδεις τα ίδια τα λόγια σου...
H 11 βγήκε πριν 9 χρόνια!!
Τώρα βρίσκεται στην έκδοση 15. Η σειρά είναι:11, 11.5, 11.9.2, 12.0, 12.5, 15 :rtfm:Όταν μια εταιρεία διαμηνύει παντού την ποιότητα/ταχύτητα κλπ του προϊόντος της, ενώ στην πράξη δουλεύει τον κόσμο, αυτή την εταιρεία δεν την εμπιστεύεσαι ξανά. Ό,τι και να κάνει...όσα χρόνια και αν περάσουν.
Φίλε μου και στην 30 έκδοση να φτάσει (αν προλάβει) πλέον δεν πείθομαι να χρησιμοποιήσω ξανά Sybase στις εφαρμογές μου. Δε βλέπω απολύτως κανένα λόγο απ'τη στιγμή που έχω πληθώρα άλλων καλύτερων λύσεων... :thumbdown
Διαψεύδεις τα ίδια τα λόγια σου...
Διάβασε ξανά σε παρακαλώ..λέω ουσιαστικά είναι μονοπώλιο!
Όταν μια εταιρεία διαμηνύει παντού την ποιότητα/ταχύτητα κλπ του προϊόντος της, ενώ στην πράξη δουλεύει τον κόσμο, αυτή την εταιρεία δεν την εμπιστεύεσαι ξανά. Ό,τι και να κάνει...όσα χρόνια και αν περάσουν.
Φίλε μου και στην 30 έκδοση να φτάσει (αν προλάβει) πλέον δεν πείθομαι να χρησιμοποιήσω ξανά Sybase στις εφαρμογές μου. Δε βλέπω απολύτως κανένα λόγο απ'τη στιγμή που έχω πληθώρα άλλων καλύτερων λύσεων... :thumbdown
Δεν προσπαθώ να πείσω κανέναν...
Περί ορέξεως...
Διάβασε ξανά σε παρακαλώ..λέω ουσιαστικά είναι μονοπώλιο!Α, δε λες πως είναι μονοπώλειο, λες πως είναι ουσιαστικά μονοπώλιο. Έχει τεράστια διαφορά ε? Τεσπα...
Παιδιά εκτροχιάζεστε.
1) Αλλο είναι το θέμα και όχι η ανταπαράθεση για βάσεις δεδομένων (και ίσως κακώς έχω εμπλακεί και εγώ, αλλά νομίζω ότι κάποια πράγματα πρέπει να λέγονται).
2) Μονοπώλιο είναι τα Microsoft Windows που κατέχουν πάνω απο το 90% στους σταθμούς εργασίας (όχι servers) σαν λειτουργικό σύστημα. Δεν μπορεί να είναι μονοπώλιο το 32%, ακόμη και εαν παίρνεις την πλειοψηφία δημοσίων έργων.
3) Η ιστορία της Sybase είναι σε όλους γνωστή που ασχολούνται με βάσεις δεδομένων. Κανένας δεν θα πεί ότι είναι άχρηστη. Απλά έχει κάνει κακές επιλογές στρατηγικής και έχει πλέον μικρότερο και όλο συρικνούμενο ποσοστό εγκαταστάσεων. Και σε μια εμπορική rdbmsαυτό σημαίνει και σημαντικά λιγότερα λεφτά στο development. Νομοτελιακά δηλαδή βαδίζει προς τα κάτω, εκτός και εαν συμβεί κάτι πρωτοφανές. Ενώ MS / Oracle / DB2 και οι free rdbms έχουν μέλλον, και ήδη έχουν προσπεράσει προ πολλού σε ικανότητες / δυνατότητες / ευκολίες την Sybase. Μπορείς να ασχολείσαι με την Sybase, αλλά απλά δεν έχει μέλλον. Οσο για την δωρεάν έκδοση για Linux (Νομίζω ότι είναι η ASE 11.5) δεν είναι η τελευταία μεγάλη έκδοση και δεν ξέρω εαν μπορείς να την χρησιμοποιήσεις σε εμπορικές εγκαταστάσεις. Δωρεάν εκδόσεις μπορείς να πάρεις ελεύθερα και για την Oracle χωρίς κλειδιά και άλλες μαμακίες οι οποίες τρέχουν κανονικότητα. Η Oracle θεωρεί ότι μια σωστή εμπορική εγκατάσταση θα αγοράσει τις άδειες προκειμένου να είναι νόμιμη και εγώ το θεωρώ σωστή πολιτική (έχουμε τρείς dual-cpu unlimited users license και πληρώνουμε και συμβόλαιο).
Παιδιά εκτροχιάζεστε.
1) Αλλο είναι το θέμα και όχι η ανταπαράθεση για βάσεις δεδομένων (και ίσως κακώς έχω εμπλακεί και εγώ, αλλά νομίζω ότι κάποια πράγματα πρέπει να λέγονται).
2) Μονοπώλιο είναι τα Microsoft Windows που κατέχουν πάνω απο το 90% στους σταθμούς εργασίας (όχι servers) σαν λειτουργικό σύστημα. Δεν μπορεί να είναι μονοπώλιο το 32%, ακόμη και εαν παίρνεις την πλειοψηφία δημοσίων έργων.
3) Η ιστορία της Sybase είναι σε όλους γνωστή που ασχολούνται με βάσεις δεδομένων. Κανένας δεν θα πεί ότι είναι άχρηστη. Απλά έχει κάνει κακές επιλογές στρατηγικής και έχει πλέον μικρότερο και όλο συρικνούμενο ποσοστό εγκαταστάσεων. Και σε μια εμπορική rdbmsαυτό σημαίνει και σημαντικά λιγότερα λεφτά στο development. Νομοτελιακά δηλαδή βαδίζει προς τα κάτω, εκτός και εαν συμβεί κάτι πρωτοφανές. Ενώ MS / Oracle / DB2 και οι free rdbms έχουν μέλλον, και ήδη έχουν προσπεράσει προ πολλού σε ικανότητες / δυνατότητες / ευκολίες την Sybase. Μπορείς να ασχολείσαι με την Sybase, αλλά απλά δεν έχει μέλλον. Οσο για την δωρεάν έκδοση για Linux (Νομίζω ότι είναι η ASE 11.5) δεν είναι η τελευταία μεγάλη έκδοση και δεν ξέρω εαν μπορείς να την χρησιμοποιήσεις σε εμπορικές εγκαταστάσεις. Δωρεάν εκδόσεις μπορείς να πάρεις ελεύθερα και για την Oracle χωρίς κλειδιά και άλλες μαμακίες οι οποίες τρέχουν κανονικότητα. Η Oracle θεωρεί ότι μια σωστή εμπορική εγκατάσταση θα αγοράσει τις άδειες προκειμένου να είναι νόμιμη και εγώ το θεωρώ σωστή πολιτική (έχουμε τρείς dual-cpu unlimited users license και πληρώνουμε και συμβόλαιο).
Συμφωνώ με κάποια από αυτά που γράφεις ειδικά στο θέμα μάρκετινγκ, αλλά:
Οι free δεν έχουν με τίποτα περισσότερες δυνατότητες από Sybase. Πχ replication, high availability, partitioning, online backups κλπ. (στο row-level όντως άργησε πολύ, αλλά υπάρχει εδώ και 7 χρόνια). Επίσης μην ξεχνάς ότι στις mobile databases έχει 40% μερίδιο (sql anywhere κλπ) - σχεδόν μονοπώλιο ;)
Η τελευταία free for production για Linux είναι κανονική full έκδοση 12.5, απλά έχει όριο 5GB data: http://www.sybase.com/linuxpromo
Ξαναλέω, χρησιμοποιούμε ότι μας βολεύει, ανάλογα με την περίπτωση. Ειδικά εμείς δεν πρέπει ποτέ να είμαστε δογματικοί. Προσωπικά (ανάλογα με το project) έχω χρησιμοποιήσει MS, Sybase, Oracle, DB2, Mysql, Postgresql, Access κλπ)
Άσχετο, απ΄όσο γνωρίζω δεν υπάρχει κάποιο ελληνικό forum για βάσεις και σκεφτόμουν να φτιάξω ένα (κάτι σαν το dbforums.com). Τι λέτε;
Άσχετο, απ΄όσο γνωρίζω δεν υπάρχει κάποιο ελληνικό forum για βάσεις και σκεφτόμουν να φτιάξω ένα (κάτι σαν το dbforums.com). Τι λέτε;
Δεν είναι άσχημη ιδέα. Αλλά, μήπως ΜΟΝΟ για DBs/SQL θα είναι υπερβολικά εξειδικευμένο;
Δεν είναι άσχημη ιδέα. Αλλά, μήπως ΜΟΝΟ για DBs/SQL θα είναι υπερβολικά εξειδικευμένο;
Αυτό σκεφτόμουν και εγώ... ίσως είναι πολύ εξειδικευμένο για την Ελλάδα.
Αυτοί που ασχολούνται συστηματικά με βάσεις, κυρίως για administration, αλλά και για design/delelopment ίσως να μην είναι αρκετοί...
Αυτό σκεφτόμουν και εγώ... ίσως είναι πολύ εξειδικευμένο για την Ελλάδα.
Αυτοί που ασχολούνται συστηματικά με βάσεις, κυρίως για administration, αλλά και για design/delelopment ίσως να μην είναι αρκετοί...
Άλλωστε οι περισσότεροι (αν όχι όλοι) ξέρουν αρκετά καλά Αγγλικά για να πηγαίνουν στο dbforums...
Globalisation, είπαμε ;)
Είναι ανάγκη να του δώσεις κατάληξη gr? Διάλεξε ένα *.net ή *.org και γράψ'το στα αγγλικά.
Globalisation, επαναλαμβάνω κι εγώ :thumbsup1
Ξερει καποιος πως μπορω σε ενα πινακα στη MySQL να εχω ενα attribute για αποθηκευση εικονων? Τι τυπου ειναι αυτο το attribute (blob νομιζω) και πως γραφω το INSERT?
DeadAtHeaven
10-10-05, 12:56
...Τι τυπου ειναι αυτο το attribute (blob νομιζω)
Ο τύπος του πεδίου είναι BLOB, και σημαίνει Binary Large OBject. Σε τέτοιου είδους πεδία μπορεί κανείς να αποθηκεύει raw data σε οτι format κι αν είναι αυτά σαν μια σειρά απο χαρακτήρες.
Ρίξε μια ματιά εδώ:
http://dev.mysql.com/doc/mysql/en/blob.html
...και πως γραφω το INSERT?
Το πρόβλημα είναι τώρα οτι το query γράφεται σε text μορφή και ώς text, συγκεκριμένες ακολουθίες χαρακτήρων έχουν συγκεκριμένο νόημα (control sequences). Συνήθως υπάρχουν συναρτήσεις οι οποίες scanάρουν ένα string και αντικαθιστούν τις γνωστές ακολουθίες χαρακτήρων με τα λεγόμενα escape strings. Αντίστοιχες συναρτήσεις υπάρχουν και για την αντίστροφη μετατροπή.
Ρίξε μια ματιά στα παρακάτω:
http://dev.mysql.com/doc/mysql/en/blob.html
(Κοίτα στα σχόλια)
http://dev.mysql.com/doc/mysql/en/string-syntax.html
Παρ' όλο που συνιστάται η μετατροπή της εικόνας σε base64 προσωπικά προτιμώ την απλή μετατροπή με τα escape sequences. Στο base64 encoding, οι 256 διαφορετικοί χαρακτήρες που μπορεί να υπάρχουν μέσα σε ένα BLOB μετατρέπονται σε ένα υποσύνολο 64 χαρακτήρων (μόνο χαρακτήρες χωρίς σύμβολα που μπορεί να ερμηνευτούν ώς control sequences). Άρα να περιμένεις οτι η ακολουθία που θα σου επιστραφεί αν χρησιμοποιήσεις μια τέτοια συνάρτηση θα είναι κατά πολύ μεγαλύτερη (άρα θα καταλάβει πολύ περισσότερο χώρο).
χχμμμ...με μπέρδεψες λίγο DeadAtHeaven. Το doc της MySQL το ειχα υποψην και το κοιταζω. Thanx anyway.
DeadAtHeaven
11-10-05, 10:55
χχμμμ...με μπέρδεψες λίγο
Ως προς τί σε μπέρδεψα;
Το πρόβλημα είναι τώρα οτι το query γράφεται σε text μορφή και ώς text, συγκεκριμένες ακολουθίες χαρακτήρων έχουν συγκεκριμένο νόημα (control sequences).
Δεν καταλαβαινω τι σχεση εχει αυτο. Εγω γραφω π.χ. ενα
SELECT * FROM ταδε_πινακα WHERE ταδε_πινακα.ταδε_attribute=5
και θελω να μου επιστρεφει τις αναλογες εγγραφες μαζι φυσικα με την εικονα που ειναι αποθηκευμενη σε blob data type.
BTW,διαβαζω και το MySQL doc μηπως βγαλω ακρη...
Μα σου την επιστρέφει!
Το πρόβλημα είναι ότι το blob data type πρέπει να το επεξεργαστείς ώστε να δεις/απεικονίσεις την εικόνα!
Γι αυτό έγινε και όλο το νήμα, όπου υποστήριξα ότι είναι πιο απλό λειτουργικό να αποθηκεύεις ένα URL/UNC προς το αρχείο εικόνας.
DeadAtHeaven
12-10-05, 11:32
Δεν καταλαβαινω τι σχεση εχει αυτο. Εγω γραφω π.χ. ενα
SELECT * FROM ταδε_πινακα WHERE ταδε_πινακα.ταδε_attribute=5
και θελω να μου επιστρεφει τις αναλογες εγγραφες μαζι φυσικα με την εικονα που ειναι αποθηκευμενη σε blob data type.
BTW,διαβαζω και το MySQL doc μηπως βγαλω ακρη...
OK Οπότε πρέπει να πάμε ένα βήμα πιο πίσω:
Έχεις ένα Data Base Management System όπως η mysql. Αυτό, μεταξύ των άλλων δυνατοτήτων του, οργανώνει την αποθήκευση των δεδομένων σε ένα μέσο (σκληρός δίσκος για παράδειγμα) με ένα δικό του τρόπο -δε μας ενδιαφέρει πώς, προς το παρόν-.
Ο χρήστης του DBMS -εσύ για παράδειγμα- δεν ασχολείται με το πώς είναι αυτά τα δεδομένα αποθηκευμένα επειδή το σύστημα του δίνει ένα "interface" (προσοχή δεν αναφέρομαι σε GUI). Αυτό το "interface" είναι η SQL. Όταν γράφεις στην SQL insert into mytable values("DeadAtHeaven","127.0.0.1") -για παράδειγμα-, τότε μεταφέρεις δεδομένα και εντολές πρός τη βάση.
Ποιά είναι τώρα η διαφορά ανάμεσα στο "DeadAtHeaven" και μία εικόνα; Η σύντομη απάντηση είναι καμία!
Και τα δύο είναι σύνολα απο bytes και ώς τέτοια τα βλέπει και η MySQL.
Όταν πρέπει να αποθηκεύσεις μια εικόνα στη βάση θα πρέπει να τη "χωρέσεις" μέσα σε ένα string το οποίο περιέχει τη κατάλληλη εντολή προς το DBMS ΚΑΙ ΤΑ ΔΕΔΟΜΕΝΑ!
Μια εικόνα λοιπόν θα πρέπει να τη διαβάσεις απο το δίσκο "Ώς ένα σύνολο απο bytes" και να τη "χωρέσεις" μέσα σε ένα string που θα το στείλεις στη βάση.
Το πρόβλημα είναι οτι για "ιστορικούς λόγους" συγκεκριμένες ακολουθίες χαρακτήρων ΜΕΣΑ ΣΕ STRING έχουν συγκεκριμένη ερμηνεία απο το σύστημα. Για παράδειγμα, αν το string περιέχει \0 τότε σημαίνει οτι αυτό είναι το τέλος του string. Σε μια εικόνα όμως δεν μπορείς να ξέρεις τι ακολουθίες θα προκύψουν. Φαντάσου να ανεβάζεις μια εικόνα 2MB και μετά τα πρώτα 800 bytes να έχεις ένα \0. Το σύστημα θα υποθέσει οτι τα δεδομένα της εικόνας τελειώνουν εκει ενώ στη πραγματικότητα τελειώνουν πολύ αργότερα.
Γι αυτό πρέπει να περάσεις τα δεδομένα της εικόνας σου πρώτα απο μια συνάρτηση που ανιχνεύει τέτοιες ακολουθίες χαρακτήρων και τις αλλάζει έτσι ώστε να μη δημιουργούνται προβλήματα. Για παράδειγμα η ακολουθία \0 μπορεί να γίνει \\0 (όταν το σύστημα θα δεί διπλή κάθετο θα την ερμηνεύσει ώς απλό χαρακτήρα)
Όταν θέλεις να μεταδώσεις μια εικόνα απο και πρός στη βάση σου λοιπόν θα πρέπει να κάνεις τα εξής βήματα:
1. Διαβάζεις την εικόνα
(Όλα τα file uploads γίνονται σε ένα προσωρινό χώρο στον server απο όπου αργότερα μπορείς να τα κάνεις ότι θές...για περισσότερες πληροφορίες ρίξε μια ματιά εδώ (http://www.netspade.com/articles/php/uploading.xml) για να καταλάβεις και τον υπόλοιπο κώδικα πλήρως)
$data = fread(fopen($_FILES['doc']['tmp_name'], "r"), $_FILES['doc']['size']);
(Ο κώδικας είναι απο εδώ: http://dev.mysql.com/doc/mysql/en/blob.html)
2. Μετατρέπεις τους χαρακτήρες
$dataconverted = addslashes($data);
3. Τοποθετείς τους χαρακτήρες στο query
$Myquery="INSERT INTO MYTABLE VALUES(\"".$dataconverted."\")";
4. Εκτελείς το query
mysql_query($Myquery);
Αντίστοιχες ενέργειες αλλά με αντίστροφη σειρά πρέπει να γίνουν όταν μεταφέρεις την εικόνα απο το server στον client.
Αυτά που αναφέρονται σε αυτό το post ισχύουν και στη περίπτωση που το frontend μιας βάσης είναι μια εφαρμογή (και όχι web interface)
@ ADSLgr.com All rights reserved.