Προτάσεις/ιδέες για την λογική του προβλήματος

[flienky]

Παιδια σορρυ κιολας, αλλα τωρα τι λεμε, οτι για αυτο το πρόβλημα, ειναι συν να φτιαξεις και δευτερη βαση δεδομένων ωστε να εχεις back up?

 

Αν θέλεις να φτιαξεις σωστό συστημα για back up, το κάνεις με snapshots και logs (απο τους πιο απλους τροπους).

 

Το να εχεις και δευτερη βαση δεδομένων, με τα μη committed values και να λες οτι ειναι συν οτι υπαρχει επειδη κραταει και back up ειναι τελείως λάθος, καθώς κρατάει back up μόνο τα uncommitted και μόνο τα στοιχεία της φορμας (τι θα απογίνει το table users που κραταει passwords emails κλπ?).. και γενικά δεν ειναι ετσι ο τροπος που κρατάς back up. 

 

Anyway, το να εχεις 2 tables θα ειναι πιο ζωρικό απο διάφορες αλλες οπτικές οπως πχ, θελω να αλλάξω ενα column type απο var char να το κανω text, θα πρέπει να το κάνω 2 φορες... και άλλα.

[mad-proffessor]

Η δευτερη βαση θα εχει τα commited και αυτην θα βλεπει ο προισταμενος, ολα ειναι θεμα ποσο κρισιμα θεωρουν τα δεδομενα τους στην εταιρεια. Αν δε μπορεις να πεισεις το πελατη σου με τα επιχειρηματα που σου εδωσα με τη παραγωγικοτητα κ αλλα εξετασε καποια αλλη υλοποιηση. Σκεψου να εχεις 1000 εγγραφες κ μολις τελειωσεις να πατησεις αποθηκευση και οχι αποθηκευση και αποστολη.

Λαθη ειμαστε, ανθρωπους κανουμε θα συμπληρωσω

[tasanton]

Πρακτικά αυτο που ζητά ο φίλος ειναι μια λειτουργικότητα draft και published εκδόσεων.
Όσο ειναι κατι draft το βλέπει μόνο ο author, οταν το κάνει publish τότε το βλέπει και ο supervisor.
Νομιζω οτι η λύση με 2 σετ πινάκων στη βάση ειναι ικανοποιητική. Κάθε ζευγάρι πινάκων θα εχει ακριβώς την ίδια γραμμογραφηση (ώστε να ειναι εύκολη η διαχείριση και οι αλλαγές).
Πατώντας αποστολή, ο κώδικας σου θα αντιγράφει τα draft data στα published (δηλαδή απο τον ενα πίνακα στον άλλο). Καλό ειναι να έχεις και κάποιο transaction, μην γίνουν μισές ενημερώσεις.
Η λύση αυτή επιτρέπει στον supervisor να βλέπει ανα πάσα στιγμή τα latest published data.

[Uberalles_gr]

Ευχαριστώ παιδιά για τις απαντήσεις σας και για τον χρόνο σας.

 

Εντέλει, δεν γλιτώνω είτε τον 2ο πίνακα είτε τις διπλοεγγραφές σε έναν πίνακα.

[pmav99]

Επειδή πάντως ρωτάς για τις τεχνολογίες αν παίζουν ρόλο, σκέψου πως θα μπορούσε να γίνει αυτό που έχεις στο μυαλό σου με πχ mongo.

[Uberalles_gr]

Πως θα μπορούσε να είχε γίνει γιατί δεν γνωρίζω mongo.

[masteripper]

Σε κάθε πρόβλημα υπάρχουν πολλές λύσεις αλλά μάλλον κάτι χάνουμε απο την όλη σύλληψη και παράλληλα αναγκαιότητα...

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

Live           :θα πρέπει σε κάθε control να υπάρχει ρουτίνα που αποθηκεύει οποιαδήποτε αλλαγή...

Περιοδική  : μια δυνατότητα θα ήταν να παίρνεις Hash τα δεδομένα της γραμμής και εφόσον έχουν αλλάξει απο την τελευταία φορά να εμφανίζονται οι εγγραφές με μεταβολή...

[Uberalles_gr]

Θα το πω όσο πιο απλά θέλω. Έχω την φόρμα, με ένα πεδίο π.χ. όνομα.

 

• 01/01/2017 ο χρήστης έχει πατήσει αποθήκευση με τιμή Test, o supervisor το βλέπει κενό
• 02/01/2017 ο χρήστης έχει πατήσει αποθήκευση με τιμή Test123, o supervisor το βλέπει κενό
• 03/01/2017 ο χρήστης έχει πατήσει αποθήκευση και αποστολή με τιμή Test-1-1, o supervisor βλέπει την τιμή Test-1-1
• 04/01/2017 ο χρήστης έχει πατήσει αποθήκευση με τιμή ΜΠΑΜΠΗΣ, o supervisor βλέπει την τιμή Test-1-1 (από 03/01/2017)
• 05/01/2017 ο χρήστης έχει πατήσει αποθήκευση με τιμή ΜΠΑΜΠΗΣ ΟΛΕ, o supervisor βλέπει την τιμή Test-1-1 (από 03/01/2017)
• 06/01/2017 ο χρήστης έχει πατήσει αποθήκευση και αποστολή με τιμή ΜΠΑΜΠΗΣ ΞΑΝΑ, o supervisor βλέπει την τιμή ΜΠΑΜΠΗΣ ΞΑΝΑ

Δεν μπορώ να το πω πιο απλά.

[masteripper]

Οπότε ουσιαστικά θέλεις να δημιουργήσεις μια κατάσταση "memory"....τώρα που είδα το παράδειγμα σου νόμιζα ότι ήθελες το αντίθετο...

Οπότε θες(έχεις) 1 πίνακα Table με Fields (ΑΑ (PK) ,fld1,fld2...fln)

και παράλληλα έχεις 1 πίνακα Uncommited o οποίος έχει την δομή ([AA,fld(x)] ->PK,value)

Ο χρήστης θα βλέπει 1 view στο οποίο κάθε field Που υπάρχει στο uncommited θα προβάλει την τιμή που είναι στο uncommited ...τα υπόλοιπα συνεχίζουν κανονικά....

Οπότε ο supervisor βλέπει τον πίνακα με τις τιμές όπως είναι και ο χρήστης βλέπει το view με τις τροποποιημένες τιμές.....

[Uberalles_gr]

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

[masteripper]

Τότε αναγκαστικά θα πρέπει να κάνεις 2πλους πίνακες με ότι συνεπάγεται αυτό..

[Predatorkill]

Uberalles θα συμφωνησω με pmav99, με mongo θα μπορουσες να το κανεις πολυ πιο ευκολα. Ψαξε mongodb, θα βρεις πολλα tutorials στο youtube αλλα και στο ιντερνετ. Συνεργαζεται μια χαρα με php, μπορεις να τρεχεις κανονικα mysql για το υπολοιπο site πχ αλλα για τη φορμα θα μπορουσες να εχεις μονο mongodb.

[defacer]

Δεν είναι και rocket science ρε παιδιά. Η γενική ιδέα είναι αυτή με το published flag, τώρα αν αυτό το flag θα είναι σε extra column ή αν η τιμή του θα είναι implied από το ποιόν πίνακα διαβάζουμε, το πόσες προηγούμενες εκδόσεις θα υπάρχουν αποθηκευμένες στο σύστημα, αν θες να κρατάς snapshots ή deltas, αν θα έχεις mongo ή sql κλπ, όλα αυτά είναι λεπτομέρειες που μπορούν να αποφασιστούν εντελώς ανεξάρτητα.

 

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

[pmav99]

Την αναφορά στη mongo την έκανα ως απάντηση στο σχόλιο του OP ότι δεν βλέπει ποιο ρόλο παίζουν οι τεχνολογίες που χρησιμοποιεί. Προφανώς και δεν αλλάζεις stack για κάτι τέτοιο.

 

That being said, το συγκεκριμένο πρόβλημα όντως λύνεται πολύ εύκολα/κομψά απλά αποθηκεύοντας τις «uncommitted» απαντήσεις σε ένα json, με την προϋπόθεση φυσικά ότι δεν θες να κάνεις queries στα uncommitted δεδομένα.