Serialized Objects vs SQL DB

[Alithinos]

Ας υποθέσουμε ότι θέλουμε να αποθηκεύσουμε διάφορα δεδομένα.

 

Ποιοι είναι οι λόγοι να προτιμήσει κάποιος να τα αποθηκεύσει σε μια κοινή βάση δεδομένων SQL, αντί του να τα αποθηκεύσει σε αρχεία με serialized κλάσεις (πχ object.dat) ?

 

Ας πούμε για παράδειγμα θέλω τους "πίνακες" User, και Post.

Γιατί να μη φτιάξω 2 κλάσεις User και Post όπου θα αποθηκεύω το κάθε User και Post ως ξεχωριστά αρχεία με serialization (πχ John.user και Title.post) ?

Μπορώ να κάνω queries και έτσι στα δεδομένα.

 

Κάποιοι λόγοι για να γίνει με αυτό το τρόπο είναι οι εξής:

1. Ένα πακέτο web hosting περιλαμβάνει SQL Server αλλά θέτει όριο (πχ 1gb), ενώ έχει απεριόριστο αποθηκευτικό χώρο για άλλα πράγματα.

2. Κάποιος ίσως να προτιμάει το workflow του τρόπου με τον οποίο χειρίζεται αντικείμενα.

 

 

[Επισκέπτης]

Δεν θα παραθεσω υπερ και κατα, με μια μικρη αναζητηση θα βρεις πολυ πληροφορια. Θα σου προτεινα να χρησιμοποιησεις repository pattern για να εχεις την δυνατοτητα να αλλαξεις ανα πασα στιγμη το implementation του storage και να συγκρινεις και μονος σου.

Για serialized storage δες

https://developers.google.com/protocol-buffers/docs/overview

[anon667]

Μόνο και μόνο τα guarantees που έχεις χρησιμοποιώντας SQL, δεν νομίζω πως έχει νόημα να συζητάς αν είναι καλύτερα να κάνεις τις δικιές σου custom-ιές.

 

Δύο λόγους βλέπω να θέλεις να κάνεις κάτι δικό σου:

1) Πειραματισμός για να μάθεις (το οποίο δεν είναι και ότι καλύτερο αν έχεις στόχο να πας production σε εύλογο χρονικό διάστημα).

2) Μαζοχισμός

 

Φιλικά πάντα.

[Επισκέπτης]

Κανένα web hosting δεν έχει ρεαλιστικά "απεριόριστο" χώρο. Αν σκεφτείς πονηρά και πεις οκ θα παρακάμψω την SQL οπότε θα το κάνω με serialize θα αυξήσεις πολύ το CPU overhead οπότε θα φας άκυρο από τον hoster. Οι βάσεις δεδομένων είναι optimized για αναζήτηση, ένα text αρχείο δεν είναι.

[tsofras]

relations έχεις σε Serialized Objects ? Μπορείς να κάνεις joins? Αν έχεις πίνακες με πολλά data είναι καλύτερα να ανοίγεις ένα τεράστιο αρχείο ή να κάνεις query σε μία βάση?

Τώρα για θέματα multi threading που γράφουν ταυτόχρονα σε έναν πίνακα και όλο το transaction management επειδή δεν έχω ασχοληθεί με το να γίνεται επάνω σε αρχεία δεν ξέρω αν είναι καλύτερο ή χειρότερο αλλά αν ήταν να απαντήσω εμπειρικά θα έλεγα δεν είναι

[παπι]

Βασικα δεν εχει καμια σχεση το ενα με το αλλο.

 

Το πρωτο ειναι για να μετατρεψεις ενα object instance σε μια δομη απο την οποια μπορεις να ανακτησεις αυτο το instance.

 

Το δευτερο ειναι για να αποθυκαιυεις data collecrions.

 

Στο πρωτο γινεται serialize ενα object σε ενα χ φορματ και μετα deserialize το χ φορματ σε ενα object. Ετσι αν εχεις ενα object 100mb, και θες να αλλαξεις ενα int απο 1 σε 3 (δηλαδη να αλλαξεις ενα bit) τοτε θα πρεπει να δι;βασεις ολο το serialized object, να το αλλαξεις στο instance, και τελος να το κανεις παλι serialize.

 

Στο δευτερο παλι, επειδη ειναι δεντρα, κανεις search αυτο που θες να αλλαξεις και το αλλαζεις.

[tsofras]

Βασικα δεν εχει καμια σχεση το ενα με το αλλο.

 

Το πρωτο ειναι για να μετατρεψεις ενα object instance σε μια δομη απο την οποια μπορεις να ανακτησεις αυτο το instance.

 

Το δευτερο ειναι για να αποθυκαιυεις data collecrions.

 

Στο πρωτο γινεται serialize ενα object σε ενα χ φορματ και μετα deserialize το χ φορματ σε ενα object. Ετσι αν εχεις ενα object 100mb, και θες να αλλαξεις ενα int απο 1 σε 3 (δηλαδη να αλλαξεις ενα bit) τοτε θα πρεπει να δι;βασεις ολο το serialized object, να το αλλαξεις στο instance, και τελος να το κανεις παλι serialize.

 

Στο δευτερο παλι, επειδη ειναι δεντρα, κανεις search αυτο που θες να αλλαξεις και το αλλαζεις.

 

Προφανώς, δεν είπαμε ότι έχουν σχέση , απλά ότι θα μπορούσες να χρησιμοποιήσεις το serialize - deserialize για να κάνεις persist data αντί για μία βάση δεδομένων

[defacer]

Μη λέτε αστεία πράγματα για ενδεχόμενες καστομιές σε flat files κλπ το 2017. Ακόμα κι αν αυτό είναι ακριβώς που θες να κάνεις, πετα τα όλα σαν serialized blob μέσα σε μια sqlite και μη κάνεις join ποτέ σου.

 

Alithinos, δοκίμασε σε κάποιο πρόγραμμα σου να κάνεις αυτό που είπες. Μερικά πράγματα μαθαίνονται καλύτερα the hard way.

[jimex]

Η βάση δεδομένων (μπορεί κάλλιστα να είναι είναι και non relational) έχει αναπτυχθεί ακριβώς για το σκοπό αυτό. Να αποθηκεύεις πράγματα εύκολα και να τα ανακτάς επίσης εύκολα. Ο μόνος τρόπος αν θέλεις να αποθηκεύσεις δεδομένα και να μη χρησιμοποιήσεις DB, είναι να υλοποιήσεις τις λειτουργίες της DB μόνος σου, στο πρόγραμμα σου. Αλλά guess what? Πάλι DB χρησιμοποιείς, η οποία είναι δική σου custom, και δεν υπάρχει περίπτωση να δουλέψει σωστά!

 

Είναι αστεία τέτοια πράγματα. Αν υπήρχε κουμπί downvote το post του OP θα πήγαινε πάτο.

[MidSeniorDev]

Τα δοκιμάζεις και τους ανακαλύπτεις μόνος σου

[nilosgr]

Οπως ειπε και ο @defacer, βαλε sqlite

Αν μιλάμε για java δες το jooq

[Alithinos]

Κανένα web hosting δεν έχει ρεαλιστικά "απεριόριστο" χώρο. Αν σκεφτείς πονηρά και πεις οκ θα παρακάμψω την SQL οπότε θα το κάνω με serialize θα αυξήσεις πολύ το CPU overhead οπότε θα φας άκυρο από τον hoster. Οι βάσεις δεδομένων είναι optimized για αναζήτηση, ένα text αρχείο δεν είναι.

 

1) Ά ώστε κάνουν και τέτοια οι hosts ? Νόμιζα πως θα ήταν ελεύθερο όσο χρειάζεται...

2) Είχα την ιδέα να τα αποθηκεύσω σε binary όχι κοινό text.

 

 

relations έχεις σε Serialized Objects ? Μπορείς να κάνεις joins? Αν έχεις πίνακες με πολλά data είναι καλύτερα να ανοίγεις ένα τεράστιο αρχείο ή να κάνεις query σε μία βάση?

Τώρα για θέματα multi threading που γράφουν ταυτόχρονα σε έναν πίνακα και όλο το transaction management επειδή δεν έχω ασχοληθεί με το να γίνεται επάνω σε αρχεία δεν ξέρω αν είναι καλύτερο ή χειρότερο αλλά αν ήταν να απαντήσω εμπειρικά θα έλεγα δεν είναι

Η ιδέα για τις σχέσεις ήταν ότι πχ μέσα σε ένα αντικείμενο μιας κλάσης, αποθηκεύεις ένα reference ενός άλλου αντικειμένου. Το αρχείο δεν θα ήταν τεράστιο, γιατί ως ξεχωριστό αρχείο θα σωζόταν όχι το κάθε "table" αλλά το κάθε "row", και το table θα αναπαριστόταν με ένα directory στο file system.

 

Βασικα δεν εχει καμια σχεση το ενα με το αλλο.

 

Το πρωτο ειναι για να μετατρεψεις ενα object instance σε μια δομη απο την οποια μπορεις να ανακτησεις αυτο το instance.

 

Το δευτερο ειναι για να αποθυκαιυεις data collecrions.

 

Στο πρωτο γινεται serialize ενα object σε ενα χ φορματ και μετα deserialize το χ φορματ σε ενα object. Ετσι αν εχεις ενα object 100mb, και θες να αλλαξεις ενα int απο 1 σε 3 (δηλαδη να αλλαξεις ενα bit) τοτε θα πρεπει να δι;βασεις ολο το serialized object, να το αλλαξεις στο instance, και τελος να το κανεις παλι serialize.

 

Στο δευτερο παλι, επειδη ειναι δεντρα, κανεις search αυτο που θες να αλλαξεις και το αλλαζεις.

 

Μα δεν θα έφτανε το κάθε object ποτέ να γίνει τόσο μεγάλο. Φαντάσου κάθε object να αντιστοιχεί σε ένα instance μιας κλάσης, με τη κάθε κλάση να αντιπροσωπεύει ένα 'row', και το κάθε property της κλάσης ένα field του row. Όλα τα αντικείμενα που αντιπροσωπεύουν rows, βρίσκονται ενός directory που αντιπροσωπεύει το table.

 

Αν ονομάσεις και το binary serialized αρχείο του κάθε instance με ένα τύπο της μορφής "rowID.TableName" μπορείς κάποιες λειτουργίες queries (πχ βρες όλα τα rows του πίνακα Τάδε) να τα κάνεις με search στο directory βάση των ονομάτων των αρχείων. Έτσι αν θες να αλλάξεις ένα int σε ένα row, κάνεις search το file που αντιστοιχεί στο row, και ανοίγεις το αρχείο που αντιστοιχεί σε αυτό το row.         

Μη λέτε αστεία πράγματα για ενδεχόμενες καστομιές σε flat files κλπ το 2017. Ακόμα κι αν αυτό είναι ακριβώς που θες να κάνεις, πετα τα όλα σαν serialized blob μέσα σε μια sqlite και μη κάνεις join ποτέ σου.

 

Alithinos, δοκίμασε σε κάποιο πρόγραμμα σου να κάνεις αυτό που είπες. Μερικά πράγματα μαθαίνονται καλύτερα the hard way.

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

 

Η βάση δεδομένων (μπορεί κάλλιστα να είναι είναι και non relational) έχει αναπτυχθεί ακριβώς για το σκοπό αυτό. Να αποθηκεύεις πράγματα εύκολα και να τα ανακτάς επίσης εύκολα. Ο μόνος τρόπος αν θέλεις να αποθηκεύσεις δεδομένα και να μη χρησιμοποιήσεις DB, είναι να υλοποιήσεις τις λειτουργίες της DB μόνος σου, στο πρόγραμμα σου. Αλλά guess what? Πάλι DB χρησιμοποιείς, η οποία είναι δική σου custom, και δεν υπάρχει περίπτωση να δουλέψει σωστά!

 

Είναι αστεία τέτοια πράγματα. Αν υπήρχε κουμπί downvote το post του OP θα πήγαινε πάτο.

 

Downvote ? Το downvote το καταλαβαίνω σε περίπτωση που κάποιος υπερασπίζεται το Χ και το Χ είναι ξεκάθαρα λάθος, ή προτείνει κάτι κακό, βλαπτικό κτλπ. Σε μια απορία όμως που μπορεί να έχει κάποιος και θέλει να κάνουμε μια θεωρητική συζήτηση για τα υπέρ και τα κατά ενός θέματος, δε βρίσκω το λόγο... Στο κάτω - κάτω δεν υπερασπίστηκα το θάνατο της sql. Δε πήρα το μέρος κάποιου σε αυτό το 'VS'.

 

[tsofras]

 

Downvote ? Το downvote το καταλαβαίνω σε περίπτωση που κάποιος υπερασπίζεται το Χ και το Χ είναι ξεκάθαρα λάθος, ή προτείνει κάτι κακό, βλαπτικό κτλπ. Σε μια απορία όμως που μπορεί να έχει κάποιος και θέλει να κάνουμε μια θεωρητική συζήτηση για τα υπέρ και τα κατά ενός θέματος, δε βρίσκω το λόγο... Στο κάτω - κάτω δεν υπερασπίστηκα το θάνατο της sql. Δε πήρα το μέρος κάποιου σε αυτό το 'VS'.

 

+1 για αυτό το σχόλιο, το να κάνεις μία ερώτηση που στην τελική έβαλε και εμάς σε σκέψεις δεν είναι κακό