הסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת
-
@Shmuel754 העלת באמת טענה עם הד"ת וכו', השאלה כמה אני חייב לדאוג ללקוח לכל הסיפור הזה, זה לא משהו שסוכם מראש, ותכלס יש לוגים די מפורטים על כל פעולה של המאזין, חשבתי במוצר המוגמר לבטל את רובם כמעט, אבל אחרי הטענות שלך אולי אשאיר כמה שיכולים להיות חשובים.
הענין שלוגים זה דבר שאפשר בקלות לשנות ולשכתב. -
@צדיק-תמים אם אני כבר עושה טבלה נפרדת שמכילה את מספר המודעה ואת המזהה של מי ששמע את המודעה, למה לא להישאר ברעיון המקורי ולעשות טבלה שתכיל במקום מספר הודעה ומזהה של מי ששמע אותה, מספר מודעה ומזהה של מי שלא שמע אותה?
-
@צדיק-תמים אם אני כבר עושה טבלה נפרדת שמכילה את מספר המודעה ואת המזהה של מי ששמע את המודעה, למה לא להישאר ברעיון המקורי ולעשות טבלה שתכיל במקום מספר הודעה ומזהה של מי ששמע אותה, מספר מודעה ומזהה של מי שלא שמע אותה?
-
דיברנו על טבלה סטטית מיותרת וחיפוש דינאמי, כל עוד לא היתה טבלה מיותרת הסכמתי, אבל כאן יש את אותה הטבלה בדיוק (טוב, כמעט בדיוק) רק שבשיטה שלי היא חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות.
אולי חסרה לי הבנה ברעיון מאחורי ההצעה שלך.
@eido המידע מי שמע הוא מידע שאתה צריך אותו. הוא לא תוצר של פילטור, ולכן הגיוני לשמור אותו. המידע "המודעה הזאת מתאימה למשתמש הזה כי הוא לא ראה אותה עדיין ויש לו קמפיין מתאים" הוא תוצר של שאילתה ויכול להשתנות בכל רגע ולכן לא שומרים אותו בצורה סטטית
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות
אם תהיה לך בעיית איטיות אחרי אינדקסים מתאימים נדבר, לא נראה לי סביר שתגיע לזה
-
@eido המידע מי שמע הוא מידע שאתה צריך אותו. הוא לא תוצר של פילטור, ולכן הגיוני לשמור אותו. המידע "המודעה הזאת מתאימה למשתמש הזה כי הוא לא ראה אותה עדיין ויש לו קמפיין מתאים" הוא תוצר של שאילתה ויכול להשתנות בכל רגע ולכן לא שומרים אותו בצורה סטטית
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות
אם תהיה לך בעיית איטיות אחרי אינדקסים מתאימים נדבר, לא נראה לי סביר שתגיע לזה
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@eido המידע מי שמע הוא מידע שאתה צריך אותו. הוא לא תוצר של פילטור, ולכן הגיוני לשמור אותו. המידע "המודעה הזאת מתאימה למשתמש הזה כי הוא לא ראה אותה עדיין ויש לו קמפיין מתאים" הוא תוצר של שאילתה ויכול להשתנות בכל רגע ולכן לא שומרים אותו בצורה סטטית
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות
אם תהיה לך בעיית איטיות אחרי אינדקסים מתאימים נדבר, לא נראה לי סביר שתגיע לזה
אז אתה אומר שזה ענין עקרוני, אם אפשר להשיג את זה עם שאילתא - מיותר לשמור. אם זה מידע לשאילתא - צריך לשמור. גם אם בסוף זה אותו הנתון ואותה הטבלה. אני מבין נכון?
-
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@eido המידע מי שמע הוא מידע שאתה צריך אותו. הוא לא תוצר של פילטור, ולכן הגיוני לשמור אותו. המידע "המודעה הזאת מתאימה למשתמש הזה כי הוא לא ראה אותה עדיין ויש לו קמפיין מתאים" הוא תוצר של שאילתה ויכול להשתנות בכל רגע ולכן לא שומרים אותו בצורה סטטית
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות
אם תהיה לך בעיית איטיות אחרי אינדקסים מתאימים נדבר, לא נראה לי סביר שתגיע לזה
אז אתה אומר שזה ענין עקרוני, אם אפשר להשיג את זה עם שאילתא - מיותר לשמור. אם זה מידע לשאילתא - צריך לשמור. גם אם בסוף זה אותו הנתון ואותה הטבלה. אני מבין נכון?
-
טוב, אז זה הקוד החדש:
מציאת מודעות:$sqlNew = "SELECT a.* FROM appartments a WHERE $where AND a.created_at >= ? AND NOT EXISTS ( SELECT 1 FROM apartment_reads ar WHERE ar.apartment_id = a.id AND ar.phone = ? ) ORDER BY a.created_at DESC"; $sqlOld = "SELECT a.* FROM appartments a WHERE $where AND ( a.created_at < ? OR EXISTS ( SELECT 1 FROM apartment_reads ar WHERE ar.apartment_id = a.id AND ar.phone = ? ) ) ORDER BY a.created_at DESC";סימון כנקראה:
$sql = "INSERT INTO apartment_reads (apartment_id, phone) VALUES (?, ?)";בעצם הפעולות שאני עושה הן רק במציאת המודעות ובסימון כנקרא, נכון?
ברגע שאני מוחק את המודעה, נמחק גם מה שקשור אליה בטבלה (FOREIGN KEY (apartment_id) REFERENCES appartments(id) ON DELETE CASCADE),
וכשאני מוסיף או מוחק סינון אני לא צריך לבצע שום פעולה.