Πρόβλημα λογικής με message delete σε pm application.

Σε αυτή την περιοχή μπορείτε να βρείτε ή να αναζητήσετε πληροφορίες σχετικές με την PHP

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

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 07 Ιαν 2014 12:40

Καλημέρα.
Εύχομαι καλή χρονιά σε όλους με υγεία και ευτυχία.

Αντιμετωπίζω το εξής θέμα σε μια personal message application που φτιάχνω.

Υπάρχει ένας πίνακας με τα εξής πεδία:

Κώδικας: Επιλογή όλων

id, topic_id, from_member, to_member, description, message, message_date, is_read, is_favorite, deleted
όπου καταχωρούνται pm που ανταλάσουν εγγεγραμμένα μέλη μεταξύ τους.
Δουλεύει μια χαρά μέχρι το σημείο που ένα pm πρέπει να διαγραφεί μόνιμα από τη βάση
(πηγαίνοντας δηλαδή στο deleted messages application όπου βλέπεις τα μηνύματα που έχει μαρκάρει ο user σαν deleted).
Οταν λοιπόν το ένα μέλος (ας υποθέσουμε ο sender) διαγράψει μόνιμα ένα pm τότε αυτό σβήνεται και από το application του άλλου μέλους (receiver).
"Λογικό" καθώς το μήνυμα υπάρχει σαν μια μοναδική εγγραφή που την διαβάζουν και οι δύο.

Οι λύσεις που έχω σκεφτεί είναι δύο:
α) περνιούνται διπλοεγγραφές (μία για τον sender και μια για τον receiver) όπου ο καθένας κάνει manage τη δικιά του εγγραφή.
Το προφανές μειονέκτημα είναι οτι έτσι γεμίζει ο πίνακας με πολλές εγγραφές. Παρόμοιες κιόλας.
β) να μπούν 2 flags (π.χ. permanent_deleted_from, permanent_deleted_to) και μόνο αν "γυρίσουν" και τα 2 σε yes να διαγράφεται πραγματικά η εγγραφή.
Το μειονέκτημα είναι οτι αυτό μπορεί να μη συμβεί ποτέ οπότε πάλι η βάση θα περιέχει πολλές εγγραφές (αν και σαφώς λιγότερες από την α λύση).

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

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από burnmind » 07 Ιαν 2014 13:57

Πρώτα πρέπει να αποφασίσεις πώς θέλεις να λειτουργεί η εφαρμογή σου. Έχεις ήδη δώσει 2 επιλογές:

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

*Υποθέτω από τη δομή της βάσης σου πως θα είναι πάντα 2.

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

**Θα μπορεί να κάνειι και κάτι άλλο εκτός της διαγραφής;

alou
Script Master
Δημοσιεύσεις: 1374
Εγγραφή: 24 Αύγ 2007 19:52
Επικοινωνία:

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από alou » 07 Ιαν 2014 14:03

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

message_header
id, topic_id, from_member, to_member, message_date, is_read, is_favorite, deleted

και
id, message_header_id, description, message

έχοντας ένα pivot table μόνο με uid και message header id για κάθε χρήστη, όπου το κάθε μήνυμα περνέται 2 φορές (για sender και για receiver). Έτσι μπορείς να χειριστείς το αν θα φανεί ένα μήνυμα ή όχι μετά τη διαγραφή του στον κάθε χρήστη αλλά για να διαγράψεις τα μηνύματα που αφαιρούνται τελείως από το pivot θα χρειαστεί άλλου είδους query που αν θες το κάνεις σαν συντήρηση. Για ευκολία αν θες προσθέτεις ένα status field στο message_header, με αρχική τιμή 2 και το κάνεις decrement όταν γίνεται delete μια καταχώριση στο pivot, οπότε γίνεται 0 αν σβηστούν και οι 2 (με την προϋπόθεση ότι ένα μήνυμα δεν αφορά παραπάνω χρήστες) και τρέχεις ένα query που πετάς τα 0 status messages.

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 07 Ιαν 2014 14:18

@burnmind:
Δεν θέλω να σβήνεται η εγγραφή και από τους δύο χρήστες.
Δεν έχει νόημα σε μια pm εφαρμογή, οι οποίες ούτως η άλλως έχουν το νόημα της stand alone εφαρμογής. Δηλαδή λειτουργούν με τη δική τους λογική ανεξάρτητα από την εφαρμογή στην οποία περικλείονται.

**Θα μπορεί να κάνειι και κάτι άλλο εκτός της διαγραφής;
Αυτό δεν το κατάλαβα, εννοείς τις ενέργειες που κάνει ήδη (με το is_read, is_favorite, deleted) ή κάτι άλλο;

@alou:
Στην αρχή είμαι ακόμα οπότε προλαβαίνω να κάνω τα πάντα :D
Στην ουσία δηλαδή προτείνεις τον πρώτο τρόπο με διπλοεγγραφές αλλά να "σπάσει" σε δύο πίνακες.

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 07 Ιαν 2014 14:33

Σόρρυ για την αργοπορία, αλλά επειδή είδα οτι υπάρχει σαν απορία, να διευκρινίσω οτι οι εγγραφές είναι 1 προς 1.
Δηλαδή ένα μήνυμα φεύγει από έναν sender σε έναν receiver.
Δεν υπάρχει περίπτωση ένα μήνυμα να φύγει από έναν sender σε δύο receivers ή το αντίστροφο.
Μιλάμε δηλαδή καθαρά για pm εφαρμογή.
Οχι mail application, chat application ή οτιδήποτε άλλο.

alou
Script Master
Δημοσιεύσεις: 1374
Εγγραφή: 24 Αύγ 2007 19:52
Επικοινωνία:

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από alou » 07 Ιαν 2014 14:37

Βασικά σε 3 πίνακες, οι 2 ενδεικτικά με τα πεδία που είναι παραπάνω (δηλαδή 1. αυτά που χρειάζεσαι για να δείξεις μια λίστα μηνυμάτων 2. όλα τα υπόλοιπα στοιχεία του μηνύματος) και ο 3ος σαν pivot για να ορίσεις μια many 2 many σχέση user / message.

message_id---user_id
1----3
1----4

όπου το μήνυμα #1 έχει σχέση με τα μέλη 3 & 4. Αν το σβήσει ο #4 θα γίνει
message_id---user_id
1----3

Σε πρώτη φάση δηλαδή, δε σβήνεις το μήνυμα αλλά τις σχέσεις.

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 07 Ιαν 2014 14:50

Αυτό ακριβώς επεξεργαζόμουν τώρα :D

Αν και δεν βλέπω τον λόγο για 3 πίνακες.
Περισσότερο τείνω στους 2 όπου στον πρώτο θα υπάρχουν τα στοιχεία του μηνύματος και στον δεύτερο τα στοιχεία "επεξεργασίας" (is_read, deleted κ.λ.π.) για το κάθε member.
Πιθανός, με μια πρώτη ματιά, να μεταφερθεί εκεί και το message_date.

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από burnmind » 07 Ιαν 2014 16:53

Apostolis_38 έγραψε:**Θα μπορεί να κάνειι και κάτι άλλο εκτός της διαγραφής;
Αυτό δεν το κατάλαβα, εννοείς τις ενέργειες που κάνει ήδη (με το is_read, is_favorite, deleted) ή κάτι άλλο;
Εννοούσα αν θα μπορούν να γίνονται edit, ή κάτι άλλο.

Anyway, με τα δεδομένα που δίνεις (πάντα ένας sender και ένας recipient, τα μηνύματα δεν γίνονται edit, κλπ) η δική μου πρόταση είναι η εξής:

Ένας messages table, που θα κρατάει όλες τις πληροφορίες του μηνύματος που αφορούν και τους 2 χρήστες και δεν αλλάζουν, δηλαδή:

id (pk)
topic_id (υποθέτω fk)
date
description
message
sender_id (fk)
recipient_id (fk)

Και ένας users_messages table, που θα κρατάει τις πληροφορίες του μηνύματος που διαφέρουν:

user_id (pk,fk)
message_id (pk,fk)
read (αυτό ίσως πάει και πάνω, αφού μας ενδιαφέρει μόνο αν το διάβασε έστω και 1 φορά ο παραλήπτης)
favourite
deleted
is_user_the_sender

Το is_user_the_sender φαίνεται περιττό καθώς μπορείς να βρεις ποιος είναι ο sender από τις πληροφορίες του μηνύματος, αλλά ίσως βολεύει όταν θες να πάρεις λίστες με sent/received messages για τον κάθε χρήστη.

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

ΥΓ: Όλα τα παραπάνω είναι προτάσεις με πολύ λίγη σκέψη, οπότε μπορεί να λέω (ή και να έχω καταλάβει) κάτι λάθος. :)

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 07 Ιαν 2014 17:19

Οχι, μια χαρά το πας :D

Αυτούς τους πίνακες έχω φτιάξει με κάποιες διαφορές:
α) δεν έβαλα το is_user_the_sender (δεν βλέπω να μου χρειάζεται).
β) κράτησα το read στον δεύτερο πίνακα για πιο απλόποιημένα updates και μήπως χρειαστεί κάποια στιγμή να ρουφιανεύω στους members ποιός διάβασε ποιόν.
γ) τα user_id και message_id δεν γίνεται να είναι primary γιατί τότε θα χτυπάει το insert και δεν θα μπορούν να στείλουν νέα μηνύματα ο ένας στον άλλο και επίσης θα χτυπάει στην δεύτερη εγγραφή. Δηλαδή θα περνάει το message_id, from_member αλλά όχι το message_id, to_member

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από burnmind » 07 Ιαν 2014 17:40

Όσον αφορά το γ):

Είναι double primary key, δηλαδή ο συνδιασμός των δύο columns πρέπει να είναι μοναδικός. Για παράδειγμα, ας θεωρήσουμε πως έχουμε ένα message με id 1, και 2 χρήστες με ids 2 και 3.

Θα περαστούν κανονικά οι εξής 2 εγγραφές:
message_id: 1 & user_id: 2
message_id: 1 & user_id: 3

Το επόμενο μήνυμα (άσχετο αν είναι reply*) θα έχει ούτως ή άλλως άλλο id.

*Αυτό ξέχασα να το ρωτήσω. Θέλεις να έχουν σχέσεις και τα μηνύματα μεταξύ τους; Δηλαδή να φαίνεται ποιο είναι reply ποιου (ώστε πχ να δημιουργείται κάποιο thread), ή το κάθε μήνυμα είναι ξεχωριστό (όπως συμβαίνει στα περισσότερα forums); Αν θέλεις κάτι τέτοιο, τότε θα πρέπει να αλλάξει η σχεδίαση της βάσης.

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 07 Ιαν 2014 18:05

- Α ok! Κατάλαβα.
Αν και δεν ξέρω αν χρειάζεται μιας και έχω τη συνήθεια να δουλέυω όλους τους πίνακες με id field.
Θα το κοιτάξω πάντως μήπως είναι καλύτερη αυτή η λύση.

- Υπάρχει σχέση στα μηνύματα και έχει σαν "οδηγό" το topic_id.
Κάθε απάντηση περνιέται σαν καινούργιο mesage αλλά ανήκει στο ίδιο topic.

Αλλα αν έχεις όρεξη γράψε την υλοποίηση που έχεις στο μυαλό σου.
Ποτέ δεν είμαι απόλυτος οτι έχω φτιάξει την καλύτερη εφαρμογή που υπήρξε ποτέ :D

Άβαταρ μέλους
giannis17
Honorary Member
Δημοσιεύσεις: 1215
Εγγραφή: 06 Ιαν 2005 19:50
Τοποθεσία: Παγκράτι - Αθήνα
Επικοινωνία:

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από giannis17 » 08 Ιαν 2014 08:33

Υπάρχει πολύ πιο απλός τρόπος.

Αντικαθιστάς το πεδίο deleted με 2 πεδία: deleted_by_sender, deleted_by_receiver

Αλλάζεις το query στην συνάρτηση εμφάνισης των μηνυμάτων σε

Κώδικας: Επιλογή όλων

...WHERE (sender != user_id AND deleted_by_sender != "2") OR (receiver != user_id deleted_by_receiver != "2")
Αλλάζεις την συνάρτηση του delete να τσεκάρει αν είναι ήδη deleted και από τον άλλο χρήστη να κάνει μόνιμη διαγραφή.

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

ΥΓ. Υποθέτουμε πως η τιμή 1 στα πεδία deleted είναι ο κάδος και η τιμή 2 είναι η μόνιμη διαγραφή.
"There is only one problem with common sense; it’s not very common."
– Milt Bryce

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 08 Ιαν 2014 10:06

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

Άβαταρ μέλους
cordis
Administrator, [F|H]ounder, [C|S]EO
Δημοσιεύσεις: 27630
Εγγραφή: 09 Οκτ 1999 03:00
Τοποθεσία: Greece
Επικοινωνία:

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από cordis » 09 Ιαν 2014 02:23

Αν θες να ειναι σαν email η έγγραφη 2 φορές ειναι μονόδρομος. Το να ειναι σε μια έγγραφη και για τους δυο λίγο με φοβίζει. Μετά ίσως θες να τα βάζεις σε φακέλους, να βάζεις tags, export, etc...
Δεν απαντάω σε προσωπικά μηνύματα με ερωτήσεις που καλύπτονται από τις ενότητες του forum. Για ο,τι άλλο είμαι εδώ για εσάς.
- follow me @twitter

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

Πρόβλημα λογικής με message delete σε pm application.

Δημοσίευση από Apostolis_38 » 09 Ιαν 2014 09:32

Οχι, δεν θέλω να είναι σε μορφή email.
Περισσότερο μοιάζει στα προσωπικά μηνύματα που έχει η phpbb αλλά σε πιο απλοποιμένη μορφή.
Ακόμα κι έτσι όμως η μία εγγραφή για 2 χρήστες αποδεικνύεται πιο δύσχρηστη.

Απάντηση

Επιστροφή στο “PHP Προγραμματισμός”

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

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