mails_table πρόβλημα...

Συζητήσεις για την βάση δεδομένων MySQL και το phpMyAdmin

Συντονιστές: WebDev Moderators, Super-Moderators

Απάντηση
Serghio
Δημοσιεύσεις: 455
Εγγραφή: 08 Φεβ 2011 19:20
Τοποθεσία: Περιστέρι

mails_table πρόβλημα...

Δημοσίευση από Serghio » 09 Σεπ 2013 17:54

Φτιάχνω μια εφαρμογή στην οποία υπάρχουν 2 είδη χρηστών...business users και regular users και τα σχετικά με αυτούς δεδομένα(password,email,username...) υπάρχουν σε ένα πίνακα με το όνομα users_table.

Σε ένα δεύτερο πίνακα με το όνομα mails...είναι αποθηκευμένα όπως καταλαβαίνετε τα μηνύματα που στέλνουν οι μεν στους δε.Σε αυτόν πίνακα υπάρχουν 2 cols, from και to, που υποδηλώνουν τον αποστολέα και παραλήπτη ταυτόχρονα, και τα οποία reference το user_ID στον users table.

Το πρόβλημα ανακύπτει όταν ένας χρήστης θελήσει να διαγράψει τον λογαρισμό του.
Θα ήθελα να διαγράψω τα email που έχει στείλει αλλά όχι αυτά που έχει λάβει, γιατί αν γίνει το δεύτερο ο χρήστης που έστειλε το email και προορίζεται για τον διαγραφέντα χρήστη(παραλήπτη)-τα email αυτά θα "εξαφανιστούν" από τον λογαριαμό του, ενώ θα έπρεπε να υπάρχει ένα αρχείο αποσταλθέντων email ακόμα και για παραλήπτες που έχει διαγραφεί ο λογαριασμός τους.

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

Ελπίζω να μην σας μπέρδεψα...
Τι θα μπορούσα να κάνω στην παραπάνω κατάσταση.

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

mails_table πρόβλημα...

Δημοσίευση από burnmind » 09 Σεπ 2013 18:58

Αφού η στήλη "from" περιέχει το user_id του χρήστη που έστειλε το mail και η στήλη "to", αυτό του παραλήπτη, τότε αν θες να διαγράφεις μόνο τα μηνύματα που έχει στείλει κάποιος χρήστης, θα διαγράψεις αυτά που περιέχουν το id του στη στήλη "from".

Από εκεί και πέρα όμως, είσαι σίγουρος ότι αυτή είναι σωστή επιλογή; Εφόσον ένας χρήστης έλαβε κάποιο μήνυμα, γιατί να αυτό να διαγραφεί (αλλά να παραμείνουν οι τυχόν απαντήσεις που του έστειλε - αφού θα κρατήσεις τα απεσταλμένα) επειδή ο χρήστης που το έστειλε διέγραψε τον λογαριασμό του; Μπορεί ο παραλήπτης να το χρειάζεται για οποιονδήποτε λόγο.

Άβαταρ μέλους
dva_dev
Script Master
Δημοσιεύσεις: 3790
Εγγραφή: 16 Σεπ 2005 01:32
Επικοινωνία:

mails_table πρόβλημα...

Δημοσίευση από dva_dev » 09 Σεπ 2013 19:34

Το πρόβλημα μου φαίνεται ότι είναι πιο βασικό και ξεκινάει από την ανάλυση. Ξέχνα τη βάση εντελώς και πες ότι διέγραψες το χρήστη και τα μηνύματα που έχει στείλει και έχει τα μηνύματα που έχει λάβει.
Σου χρησιμεύουν σε κάτι;
Ξέρει ο χρήστης 1 ότι έχει στείλει μήνημα στον χρήστη 2 (που τώρα έχει διαγραφεί). Και λοιπόν; Εστειλε ένα μήνυμα σε κάποιον ??? χρήστη 2 για τον οποίο δεν έχει πλέον κανένα στοιχείο (πέρα από το κείμενο του μηνύματος και το θέμα αν το κρατάς).
Αν ο χρήστης 1 έχει στείλει 100 μηνύματα σε 100 χρήστες που έχουν διαγραφεί και οι 100 τι έχει; 100 απεσταλμένα άχρηστα μηνύματα που δεν ξέρει τι έχει πάει σε ποιόν. 100 σκουπίδια.

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

Οσο για τη διαγραφή, τσεκάρισε επίσης ότι στη στήλη to δεν έχεις κάποιο cascade delete στα constraints.

Serghio
Δημοσιεύσεις: 455
Εγγραφή: 08 Φεβ 2011 19:20
Τοποθεσία: Περιστέρι

mails_table πρόβλημα...

Δημοσίευση από Serghio » 09 Σεπ 2013 19:49

dva_dev έγραψε:Το πρόβλημα μου φαίνεται ότι είναι πιο βασικό και ξεκινάει από την ανάλυση. Ξέχνα τη βάση εντελώς και πες ότι διέγραψες το χρήστη και τα μηνύματα που έχει στείλει και έχει τα μηνύματα που έχει λάβει.
Σου χρησιμεύουν σε κάτι;
Ξέρει ο χρήστης 1 ότι έχει στείλει μήνημα στον χρήστη 2 (που τώρα έχει διαγραφεί). Και λοιπόν; Εστειλε ένα μήνυμα σε κάποιον ??? χρήστη 2 για τον οποίο δεν έχει πλέον κανένα στοιχείο (πέρα από το κείμενο του μηνύματος και το θέμα αν το κρατάς).
Αν ο χρήστης 1 έχει στείλει 100 μηνύματα σε 100 χρήστες που έχουν διαγραφεί και οι 100 τι έχει; 100 απεσταλμένα άχρηστα μηνύματα που δεν ξέρει τι έχει πάει σε ποιόν. 100 σκουπίδια.

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

Οσο για τη διαγραφή, τσεκάρισε επίσης ότι στη στήλη to δεν έχεις κάποιο cascade delete στα constraints.
Σωστή η τοποθέτηση σου...εμένα σαν admin του site δεν μου χρησιμεύουν σε κάτι.Μήπως όμως είναι χρήσιμα για τον οποιονδήποτε τρόπο σε κάποιο χρήστη όπως λέει και ο burnmind-και κατι ακόμα, το πρόβλημα δεν είναι κρατηθούν τα from mails του διαγραφέντος χρήστη αλλά(αυτά δεν πειράζει να διαγραφούν) αλλά τα to mails,όπως το περιγράφει καλύτερα ο dva_dve.

Δες και το παράδειγμα που χρησιμοποιώ παρακάτω απο το facebook για να καταλάβεις καλύτερα.

Και ερωτώ;
Τι γίνεται σε ανάλογες περιπτώσεις. Αν πχ στο facebook κάνω delete τον λογαριασμό μου, τα μηνύματα που θα μου έχουν στείλει οι φίλοι μου, θα έχουν διαγραφεί από το αρχείο τους;Εγώ που θα κάνω del τον λογαριασμό μου δεν με ενδιαφέρει να κρατήσω τα mails, οι φίλι μου όμως που μου τα στείλανε όμως;
Απλώς προσπαθώ να καταλάβω ποιές είναι οι πρακτικές εδώ κιόλας.

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

mails_table πρόβλημα...

Δημοσίευση από burnmind » 09 Σεπ 2013 20:04

Μια και ανέφερες το facebook, όταν κάποιος σβήνει τον λογαριασμό του, όλα τα μηνύματα παραμένουν στο inbox αυτού με τον οποίο έχει κάνει κάποια συνομιλία, απλά φαίνεται ότι η συνομιλία γίνεται με λογαριασμό ο οποιός πλέον δεν υπάρχει (τον αναφέρει απλά ως "facebook user" αν έχει διαγράψει εντελώς τον λογαριασμό του, ή απλά αναφέρει το όνομά του χωρίς link, αν -υποθέτω- τον έχει απενεργοποιήσει).

Όπως έγραψα και πριν, κατά τη γνώμη μου είτε θα διαγράφεις τα πάντα αν το είδος της εφαρμογής που κατασκευάζεις το απαιτεί για Χ λόγους, ή θα αφήνεις τα πάντα, ώστε να βγαίνει νόημα σε πιθανές συνομιλίες (αν πχ ένα απεσταλμένο είναι reply σε κάτι, είναι πιθανό να μη βγαίνει νόημα αν υπάρχουν μόνο τα μισά μηνύματα), αλλά και να μην επηρεάζεις τη χρήση που κάνει ο κάθε χρήστης (μπορεί να υπάρχει κάτι σημαντικό σε ένα μήνυμα που να θέλει να το κρατήσει, άσχετα που ο χρήστης ο οποίος του το έστειλε έχει διαγράψει το λογαριασμό του).

Να διαγράψεις μόνο τα μισά δε μου φαίνεται λογικό. Τα πάντα όμως εξαρτώνται από το τι φτιάχνεις.

Serghio
Δημοσιεύσεις: 455
Εγγραφή: 08 Φεβ 2011 19:20
Τοποθεσία: Περιστέρι

mails_table πρόβλημα...

Δημοσίευση από Serghio » 09 Σεπ 2013 21:11

burnmind έγραψε:Μια και ανέφερες το facebook, όταν κάποιος σβήνει τον λογαριασμό του, όλα τα μηνύματα παραμένουν στο inbox αυτού με τον οποίο έχει κάνει κάποια συνομιλία, απλά φαίνεται ότι η συνομιλία γίνεται με λογαριασμό ο οποιός πλέον δεν υπάρχει (τον αναφέρει απλά ως "facebook user" αν έχει διαγράψει εντελώς τον λογαριασμό του, ή απλά αναφέρει το όνομά του χωρίς link, αν -υποθέτω- τον έχει απενεργοποιήσει).

Όπως έγραψα και πριν, κατά τη γνώμη μου είτε θα διαγράφεις τα πάντα αν το είδος της εφαρμογής που κατασκευάζεις το απαιτεί για Χ λόγους, ή θα αφήνεις τα πάντα, ώστε να βγαίνει νόημα σε πιθανές συνομιλίες (αν πχ ένα απεσταλμένο είναι reply σε κάτι, είναι πιθανό να μη βγαίνει νόημα αν υπάρχουν μόνο τα μισά μηνύματα), αλλά και να μην επηρεάζεις τη χρήση που κάνει ο κάθε χρήστης (μπορεί να υπάρχει κάτι σημαντικό σε ένα μήνυμα που να θέλει να το κρατήσει, άσχετα που ο χρήστης ο οποίος του το έστειλε έχει διαγράψει το λογαριασμό του).

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

Βεβαια, εφόσον θα τα κρατάω, νομίζω κιόλας ότι πρέπει να αλλάξω και την δομή του mails table. Τώρα η ταυτότητα του αποστολέα/παραλήπτη υποδηλώνεται από τα foreign keys στα 2 αυτά cols που κάνουν reference τον users_table.
Θα τα καταργήσω αυτά και στην θέση τους θα βάλω τα πραγματικά ονόματα νομίζω, ωστέ να υπάρχουν αυτά και μετά την διαγραφή κάποιου χρήστη...τι λέτε για αυτό;

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

mails_table πρόβλημα...

Δημοσίευση από burnmind » 09 Σεπ 2013 22:48

Και η ανταλλαγή μηνυμάτων συνομιλία είναι. :P

Βγάζοντας τα foreign keys, εκτός του ότι αν αλλάξουν τα ονόματα θα έχεις πρόβλημα, πώς θα ξέρεις ποιους χρήστες αφορά το μήνυμα; Θα πρότεινα να αφήσεις foreign keys στη θέση τους.

Τί θέλεις/πρέπει να σβήνεται όταν ένας χρήστης διαγράφει τον εαυτό του; Αν δε σε ενοχλεί να κρατάς το όνομά του, τότε σβήσε τα υπόλοιπα, βάλε μια στήλη στον πίνακα των χρηστών που να υποδηλώνει πως δεν είναι πλέον ενεργός χρήστης (ώστε να κάνεις τους απαραίτητους ελέγχους), και τέλος.

Εναλλακτικά, αν πρέπει, σβήσε όλα τα προσωπικά στοιχεία του, αλλά και πάλι κράτα στη βάση πως υπήρχε ο χρήστης με το Χ id που τώρα είναι απενεργοποιημένος, και βγάλε κάποιο σχετικό μήνυμα ως όνομα χρήστη στα μηνύματα (όπως το facebook βγάζει "Facebook User").

Serghio
Δημοσιεύσεις: 455
Εγγραφή: 08 Φεβ 2011 19:20
Τοποθεσία: Περιστέρι

mails_table πρόβλημα...

Δημοσίευση από Serghio » 09 Σεπ 2013 23:18

burnmind έγραψε: Εναλλακτικά, αν πρέπει, σβήσε όλα τα προσωπικά στοιχεία του, αλλά και πάλι κράτα στη βάση πως υπήρχε ο χρήστης με το Χ id που τώρα είναι απενεργοποιημένος, και βγάλε κάποιο σχετικό μήνυμα ως όνομα χρήστη στα μηνύματα (όπως το facebook βγάζει "Facebook User").
Mάλλον αυτό θα κάνω...να δημιουργήσω ξεχωριστό table για αυτή την δουλειά άραγε;
Ας πούμε deleted_users_table.

Kάτι τέτοιο υποννοείς;

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

mails_table πρόβλημα...

Δημοσίευση από burnmind » 09 Σεπ 2013 23:46

Μπορείς, αλλά η δική μου πρώτη σκέψη (που υπάρχει και στο προηγούμενο μήνυμα) ήταν να κρατήσεις στη βάση το record, να σβήσεις όσες πληροφορίες πρέπει να σβήσεις, και απλά να προσθέσεις μια στήλη, πχ active (bool), που το σύστημά σου θα ελέγχει για να ξέρει αν θα βγάλει στοιχεία για τον χρήστη (αν είναι active), ή απλά ένα μήνυμα πως ο χρήστης δεν υπάρχει πλέον.

Τρόποι υπάρχουν πολλοί. Δοκίμασε πράγματα για να δεις τι σε βολεύει. :wink:

Άβαταρ μέλους
dva_dev
Script Master
Δημοσιεύσεις: 3790
Εγγραφή: 16 Σεπ 2005 01:32
Επικοινωνία:

mails_table πρόβλημα...

Δημοσίευση από dva_dev » 10 Σεπ 2013 00:55

Συμφωνώ με τον burnmind.
Εγώ θα έβαζα και έναν index πάνω στο active στους users και θα έφτιαχνα και ένα view για να φέρνω μόνο τους active χρήστες αντικαθιστώντας πρακτικά το table users.
Αν είναι inactive δεν θα τον φέρνει το view οπότε είναι σαν να μην υπάρχει, παρόλα αυτά αν χρειάζεσαι να φέρεις στοιχεία για να έχεις τις πληροφορίες που απαιτείται για να είναι κατανοητό το email τα παίρνεις κατευθείαν από το table users και είσαι κομπλέ.

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

Serghio
Δημοσιεύσεις: 455
Εγγραφή: 08 Φεβ 2011 19:20
Τοποθεσία: Περιστέρι

mails_table πρόβλημα...

Δημοσίευση από Serghio » 10 Σεπ 2013 07:46

το μόνο πρόβλημα είναι ότι αν επιλέξω να κρατήσω τον χρήστη και διαγράψω κάποια στοιχεία μόνο και επειδή τα στοιχεία του χρήστη βρίσκονται σε 3 πίνακες δεν θα μπορώ να εφαρμόσω on delete cascade.

Μέχρι τώρα, με ένα query, διέγραφα τον χρήστη από την βάση.

Τώρα τα queries θα πρέπει να γίνουν 3. Ένα για να διαγράψει μέρος των στοιχείων από τον users table και και άλλα 2 για να διαγράψει τα στοιχεία του από τα άλλα 2 tables.

Θα κοιτάξω να δω τι μπορώ να κάνω.

Άβαταρ μέλους
korgr
Honorary Member
Δημοσιεύσεις: 5067
Εγγραφή: 07 Οκτ 2008 18:30
Τοποθεσία: Corinth
Επικοινωνία:

mails_table πρόβλημα...

Δημοσίευση από korgr » 10 Σεπ 2013 08:44

Ούτε εγώ θα διέγραφα κάτι!
Είναι αρκετό ένα field `active` ως flag, το οποίο θα μου επέτρεπε να κρατάω ως ανενεργούς όσους χρήστες θα θεωρώ deleted.

Αυτό προϋποθέτει πως όλα σου τα queries προς το table users θα πρέπει να λαμβάνουν υπ' όψη το state αυτού του flag

Serghio
Δημοσιεύσεις: 455
Εγγραφή: 08 Φεβ 2011 19:20
Τοποθεσία: Περιστέρι

mails_table πρόβλημα...

Δημοσίευση από Serghio » 10 Σεπ 2013 13:07

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

Apostolis_38
Δημοσιεύσεις: 1969
Εγγραφή: 14 Φεβ 2008 16:20
Τοποθεσία: ΠΕΙΡΑΙΑΣ

mails_table πρόβλημα...

Δημοσίευση από Apostolis_38 » 10 Σεπ 2013 16:39

- γυρνάς το flag του user σε active και ξεμπερδεύεις χωρίς πολλά πολλά.
Εδώ κουμπώνει και αυτό που έγραψαν οι προηγούμενοι για μη διαγραφή κ.λ.π. κ..π.

- τον οδηγείς ξανά στη σελίδα που κάνει register(φαντάζομαι οτι υπάρχει ήδη) και παίρνει νέο id.

Γιατί να ξαναγράψεις κώδικα;

Serghio
Δημοσιεύσεις: 455
Εγγραφή: 08 Φεβ 2011 19:20
Τοποθεσία: Περιστέρι

mails_table πρόβλημα...

Δημοσίευση από Serghio » 10 Σεπ 2013 16:43

Apostolis_38 έγραψε:- γυρνάς το flag του user σε active και ξεμπερδεύεις χωρίς πολλά πολλά.
Εδώ κουμπώνει και αυτό που έγραψαν οι προηγούμενοι για μη διαγραφή κ.λ.π. κ..π.

- τον οδηγείς ξανά στη σελίδα που κάνει register(φαντάζομαι οτι υπάρχει ήδη) και παίρνει νέο id.

Γιατί να ξαναγράψεις κώδικα;
Aυτό που έκανα τελικά ήταν να διαγράφω και το email που αναφέρω για να παρακάμψω το πρόβλημα της επανεγγραφής αλλά νομίζω ότι αυτό που προτείνεις ίσως είναι καλύτερο.
Aπο την άλλη όταν πάει να ξαναγραφτεί ίσως κάποι στοιχεία να είναι διαφιρετικά...οπότε να χρειάζεται καινούργιο record εξ'ολοκλήρου από το να κάθομαι να κάνω updates. Θα το δω και στην πορεία αυτό.

Απάντηση

Επιστροφή στο “MySQL”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 0 επισκέπτες