הסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת
-
תודה על הפירוט הנוסף.
תכין טבלה נוספת "מודעות להסתרה", עמודות: מס' לקוח, מס' מודעה.
בעת השליפה תחבר את המודעות לפי לקוח לטבלה הזו עם LEFT JOIN ותוודא שמס' מודעה ריק, או שתבדוק עם NOT EXSIST שאין שמה שורה על מודעה זו.@dovid כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
תודה על הפירוט הנוסף.
תכין טבלה נוספת "מודעות להסתרה", עמודות: מס' לקוח, מס' מודעה.
בעת השליפה תחבר את המודעות לפי לקוח לטבלה הזו עם LEFT JOIN ותוודא שמס' מודעה ריק, או שתבדוק עם NOT EXSIST שאין שמה שורה על מודעה זו.לא כ"כ הבנתי למה לעשות טבלה חדשה ובשליפה לחשבן מה להראות ומה לא, אם אפשר פשוט למחוק את המודעה מהמסד? זה חוסך תחזוקה של מסד נוסף, חוסך צבירת מודעות ישנות בשני המסדים ותחזוקה של עוד קוד.
שוב, אני לא כ"כ מבין בsql ומסדי נתונים, אם בכל זאת אני טועה, בבקשה תאירו את עיני. -
@dovid כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
תודה על הפירוט הנוסף.
תכין טבלה נוספת "מודעות להסתרה", עמודות: מס' לקוח, מס' מודעה.
בעת השליפה תחבר את המודעות לפי לקוח לטבלה הזו עם LEFT JOIN ותוודא שמס' מודעה ריק, או שתבדוק עם NOT EXSIST שאין שמה שורה על מודעה זו.לא כ"כ הבנתי למה לעשות טבלה חדשה ובשליפה לחשבן מה להראות ומה לא, אם אפשר פשוט למחוק את המודעה מהמסד? זה חוסך תחזוקה של מסד נוסף, חוסך צבירת מודעות ישנות בשני המסדים ותחזוקה של עוד קוד.
שוב, אני לא כ"כ מבין בsql ומסדי נתונים, אם בכל זאת אני טועה, בבקשה תאירו את עיני. -
@eido
איפה המסד \ אפליקצייה יושב זה מסד סודי? פרטי?
אולי אתה פשוט יכול פרסם קישור.
ואם יש למישהו זמן יעיף מבט במה שעשית.@pcinfogmach כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@eido
איפה המסד \ אפליקצייה יושב זה מסד סודי? פרטי?
אולי אתה פשוט יכול פרסם קישור.
ואם יש למישהו זמן יעיף מבט במה שעשית.את המסד אני לא יכול לפרסם, לא כי הוא סודי, הוא עדיין בשלבי פיתוח וחוץ מ"שמאטעס" (אני מקוה שככה כותבים את זה) אין בו כלום, הענין הוא שאת רוב המודעות שם הכניס הלקוח מטלפונים שונים שלו(?) ואני לא בטוח שאפשר לפרסם אותם בציבור...
הקוד כשלעצמו גם כן לא סודי אבל הוא ארוך, מאוד הוא בנוי מחלק של PHP שיש בו איזה 20 קבצים (קצרים, רק שכל אחד עושה תפקיד מסוים) ועוד חלק של nodejs עם (בין היתר) 5 קונטרולרים וutlis 1. ואפילו עוד קובץ פייתון.
אם יש משהו שיעזור אני יכול להעלות כאן, אבל בגלל שכל קונטרולר הוא זרימה של ivr אז הקבצים מאוד ארוכים (בין 200 ל450 שורות כל קובץ). -
@pcinfogmach כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@eido
איפה המסד \ אפליקצייה יושב זה מסד סודי? פרטי?
אולי אתה פשוט יכול פרסם קישור.
ואם יש למישהו זמן יעיף מבט במה שעשית.את המסד אני לא יכול לפרסם, לא כי הוא סודי, הוא עדיין בשלבי פיתוח וחוץ מ"שמאטעס" (אני מקוה שככה כותבים את זה) אין בו כלום, הענין הוא שאת רוב המודעות שם הכניס הלקוח מטלפונים שונים שלו(?) ואני לא בטוח שאפשר לפרסם אותם בציבור...
הקוד כשלעצמו גם כן לא סודי אבל הוא ארוך, מאוד הוא בנוי מחלק של PHP שיש בו איזה 20 קבצים (קצרים, רק שכל אחד עושה תפקיד מסוים) ועוד חלק של nodejs עם (בין היתר) 5 קונטרולרים וutlis 1. ואפילו עוד קובץ פייתון.
אם יש משהו שיעזור אני יכול להעלות כאן, אבל בגלל שכל קונטרולר הוא זרימה של ivr אז הקבצים מאוד ארוכים (בין 200 ל450 שורות כל קובץ). -
@eido הבעיה היא שאתה משכפל נתונים (מודעות) שאמורים להיות שאילתה
שאילתה לא אמורה להיות סיבוך, בשביל זה אתה עובד עם SQL ולא עם קבצים בדיסק -
@צדיק-תמים מממ לא הבנתי, צריך עוד טיפה להוריד את זה ברמה כדי שאבין...
-
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אבל בגלל שכל קונטרולר הוא זרימה של ivr אז הקבצים מאוד ארוכים
למה זה סיבה?
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אבל בגלל שכל קונטרולר הוא זרימה של ivr אז הקבצים מאוד ארוכים
למה זה סיבה?
כי כל הקשה מובילה למשהו אחר ועושה פעולה שונה לגמרי. חלקן אפילו עם הסתעפויות. מטבע הדברים זה מאריך את הקוד.
-
@eido אני מתכוון שגם עם הספריה yemot-router2 אפשר לבודד לוגיקה לפונקציות הניתנות לשימוש חוזר
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@eido אני מתכוון שגם עם הספריה yemot-router2 אפשר לבודד לוגיקה לפונקציות הניתנות לשימוש חוזר
נכון, יש הרבה פונקציות שבודדתי אותן לשימוש חוזר, אבל יש פונקציות שיש בהן שינוי דק ועם כמה שינויים אני מאמים שאפשר להפוך אותן לגנריות + export. ובגלל שהשינוים בוצעו לאחר שהקוד כבר היה מוכן אז יש כפילויות...
אבל לא כ"כ הבנתי איך זה קשור לשיטה להסרת מודעות?
-
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
לא כ"כ הבנתי את ההצעה שלך, אני לא כ"כ חזק בsql ומסדי נתונים.
יש טבלה אחת כללית של מודעות
וטבלה אחת של מודעות חדשות פר לקוח וזה בגלל שאני צריך לדעת להבדיל בין המודעות החדשות שהן לאו דווקא חדשות, אלא אלו שהוא לא שמע עדיין גם אם הוא שמע כבר אחרות, זאת אומרת יכול להיות שהוא נכנס ושמע את הדירות של בית שמש, אבל לא את של ירושלים אז אלו של ירושלים עדיין יושמעו בתור חדשות, גם אם הן הוכנסו לפני של בית שמש. וכן אם הוא רק התחיל לשמוע את המודעות של ירושלים אז אלו שהוא עדיין לא שמע יושמעו כחדשות. ככה זה נותן לי לנהל את המודעות בצורה הכי טובה.כמה שהצלחתי לחשוב האופציה הכי טובה היא פשוט לעשות מודעות חדשות פר לקוח. זה על הרעיון של מה שהצעתם לי כאן.
תאריך כניסה אחרונה לא עוזר לי, כי יכול להיות שהוא לא שמע את כל המודעות שהיו עד עכשיו ואם אחשב לפי תאריך שמיעה אחרונה אז הוא יפספס מודעות.
בטבלת הסינונים כבר יש מזהה לקוח - הטלפון.
מהסיבה הנ"ל אני לא יכול לחשב סינון בזמן אמת, כי אני צריך אינדיקציה ברורה מה הוא שמע ומה לא.@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
לא כ"כ הבנתי את ההצעה שלך, אני לא כ"כ חזק בsql ומסדי נתונים.
יש טבלה אחת כללית של מודעות
וטבלה אחת של מודעות חדשות פר לקוח וזה בגלל שאני צריך לדעת להבדיל בין המודעות החדשות שהן לאו דווקא חדשות, אלא אלו שהוא לא שמע עדיין גם אם הוא שמע כבר אחרות, זאת אומרת יכול להיות שהוא נכנס ושמע את הדירות של בית שמש, אבל לא את של ירושלים אז אלו של ירושלים עדיין יושמעו בתור חדשות, גם אם הן הוכנסו לפני של בית שמש. וכן אם הוא רק התחיל לשמוע את המודעות של ירושלים אז אלו שהוא עדיין לא שמע יושמעו כחדשות. ככה זה נותן לי לנהל את המודעות בצורה הכי טובה.כמה שהצלחתי לחשוב האופציה הכי טובה היא פשוט לעשות מודעות חדשות פר לקוח. זה על הרעיון של מה שהצעתם לי כאן.
תאריך כניסה אחרונה לא עוזר לי, כי יכול להיות שהוא לא שמע את כל המודעות שהיו עד עכשיו ואם אחשב לפי תאריך שמיעה אחרונה אז הוא יפספס מודעות.
בטבלת הסינונים כבר יש מזהה לקוח - הטלפון.
מהסיבה הנ"ל אני לא יכול לחשב סינון בזמן אמת, כי אני צריך אינדיקציה ברורה מה הוא שמע ומה לא.מה שהציעו לך באשכול השני זה לא לשכפל את המידע אלא ליצור טבלה של "מה המשתמש קרא כבר" ואז בזמן אמת לעשות בשאילתה בדיקה שהמודעה לא מופיעה בטבלה השניה (כלומר לא נקראה)
זה יכול להיות גם בלי טבלה נפרדת, כעמודה של "מזהי משתמשים שקראו" בטבלת המודעות, אבל אז אתה מאבד את המידע הנוסף כמו כמה פעמים המשתמש נכנס למודעה, מתי, ועוד, שזה מידע שעשוי להיות שימושיהאם להשתמש בזה או בתאריך כניסה אחרונה שהצעתי זה באמת שיקול עסקי
-
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
לא כ"כ הבנתי את ההצעה שלך, אני לא כ"כ חזק בsql ומסדי נתונים.
יש טבלה אחת כללית של מודעות
וטבלה אחת של מודעות חדשות פר לקוח וזה בגלל שאני צריך לדעת להבדיל בין המודעות החדשות שהן לאו דווקא חדשות, אלא אלו שהוא לא שמע עדיין גם אם הוא שמע כבר אחרות, זאת אומרת יכול להיות שהוא נכנס ושמע את הדירות של בית שמש, אבל לא את של ירושלים אז אלו של ירושלים עדיין יושמעו בתור חדשות, גם אם הן הוכנסו לפני של בית שמש. וכן אם הוא רק התחיל לשמוע את המודעות של ירושלים אז אלו שהוא עדיין לא שמע יושמעו כחדשות. ככה זה נותן לי לנהל את המודעות בצורה הכי טובה.כמה שהצלחתי לחשוב האופציה הכי טובה היא פשוט לעשות מודעות חדשות פר לקוח. זה על הרעיון של מה שהצעתם לי כאן.
תאריך כניסה אחרונה לא עוזר לי, כי יכול להיות שהוא לא שמע את כל המודעות שהיו עד עכשיו ואם אחשב לפי תאריך שמיעה אחרונה אז הוא יפספס מודעות.
בטבלת הסינונים כבר יש מזהה לקוח - הטלפון.
מהסיבה הנ"ל אני לא יכול לחשב סינון בזמן אמת, כי אני צריך אינדיקציה ברורה מה הוא שמע ומה לא.מה שהציעו לך באשכול השני זה לא לשכפל את המידע אלא ליצור טבלה של "מה המשתמש קרא כבר" ואז בזמן אמת לעשות בשאילתה בדיקה שהמודעה לא מופיעה בטבלה השניה (כלומר לא נקראה)
זה יכול להיות גם בלי טבלה נפרדת, כעמודה של "מזהי משתמשים שקראו" בטבלת המודעות, אבל אז אתה מאבד את המידע הנוסף כמו כמה פעמים המשתמש נכנס למודעה, מתי, ועוד, שזה מידע שעשוי להיות שימושיהאם להשתמש בזה או בתאריך כניסה אחרונה שהצעתי זה באמת שיקול עסקי
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
מה שהציעו לך באשכול השני זה לא לשכפל את המידע אלא ליצור טבלה של "מה המשתמש קרא כבר" ואז בזמן אמת לעשות בשאילתה בדיקה שהמודעה לא מופיעה בטבלה השניה (כלומר לא נקראה)
ככה בהתחלה עשיתי, אבל ברגע שאני מסמן רק מה הוא כבר קרא אז אוטומטית כל השאר מוגדר כ"לא נקרא" גם אם היא מודעה לא רלוונטית מלפני שנתיים. הדרישה של הלקוח שלי היא שיהיו לו מודעות "חדשות" דהיינו שהוכנסו אחרי שהוא קבע את הסינון, וזה כמה שהצלחתי להבין אפשר רק אם אני מסמן מה חדש (הוכנס מאותו פרק זמן והלאה ועדיין לא נשמע) ולא מה נקרא או לא נקרא.
כרגע אין דרישה לכמה פעמים הוא נכנס למודעה מסויימת, באמת לא חשבנו על זה לא אני ולא הלקוח... ושוב, תאריך כניסה אחרון לא עוזר לי כי אם הוא נכנס ב-ז כסלו אבל לא שמע מודעה שהוכנסה ב-ה כסלו - אם נלך לפי השיטה של תאריך כניסה, הוא יפספס את המודעה ההיא ואם נלך לפי חדש שלא נקרא הוא לא יפספס אותה.
לא ידעתי שאפשר בעמודה אחת להכניס כמה "מזהי משתמשים שקראו", איך אפשר? פשוט להוסיף פסיק ואחריו את המזהה החדש ואז כשקוראים את זה להפריד למערך לפי הפסיקים?
-
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
לא כ"כ הבנתי את ההצעה שלך, אני לא כ"כ חזק בsql ומסדי נתונים.
יש טבלה אחת כללית של מודעות
וטבלה אחת של מודעות חדשות פר לקוח וזה בגלל שאני צריך לדעת להבדיל בין המודעות החדשות שהן לאו דווקא חדשות, אלא אלו שהוא לא שמע עדיין גם אם הוא שמע כבר אחרות, זאת אומרת יכול להיות שהוא נכנס ושמע את הדירות של בית שמש, אבל לא את של ירושלים אז אלו של ירושלים עדיין יושמעו בתור חדשות, גם אם הן הוכנסו לפני של בית שמש. וכן אם הוא רק התחיל לשמוע את המודעות של ירושלים אז אלו שהוא עדיין לא שמע יושמעו כחדשות. ככה זה נותן לי לנהל את המודעות בצורה הכי טובה.כמה שהצלחתי לחשוב האופציה הכי טובה היא פשוט לעשות מודעות חדשות פר לקוח. זה על הרעיון של מה שהצעתם לי כאן.
תאריך כניסה אחרונה לא עוזר לי, כי יכול להיות שהוא לא שמע את כל המודעות שהיו עד עכשיו ואם אחשב לפי תאריך שמיעה אחרונה אז הוא יפספס מודעות.
בטבלת הסינונים כבר יש מזהה לקוח - הטלפון.
מהסיבה הנ"ל אני לא יכול לחשב סינון בזמן אמת, כי אני צריך אינדיקציה ברורה מה הוא שמע ומה לא.מה שהציעו לך באשכול השני זה לא לשכפל את המידע אלא ליצור טבלה של "מה המשתמש קרא כבר" ואז בזמן אמת לעשות בשאילתה בדיקה שהמודעה לא מופיעה בטבלה השניה (כלומר לא נקראה)
זה יכול להיות גם בלי טבלה נפרדת, כעמודה של "מזהי משתמשים שקראו" בטבלת המודעות, אבל אז אתה מאבד את המידע הנוסף כמו כמה פעמים המשתמש נכנס למודעה, מתי, ועוד, שזה מידע שעשוי להיות שימושיהאם להשתמש בזה או בתאריך כניסה אחרונה שהצעתי זה באמת שיקול עסקי
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
מה שהציעו לך באשכול השני זה לא לשכפל את המידע
אבל אני לא מבין, אני לא משכפל את המודעה, אני רק מכניס טלפון ומזהה מודעה (הID שלה).
-
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
מה שהציעו לך באשכול השני זה לא לשכפל את המידע אלא ליצור טבלה של "מה המשתמש קרא כבר" ואז בזמן אמת לעשות בשאילתה בדיקה שהמודעה לא מופיעה בטבלה השניה (כלומר לא נקראה)
ככה בהתחלה עשיתי, אבל ברגע שאני מסמן רק מה הוא כבר קרא אז אוטומטית כל השאר מוגדר כ"לא נקרא" גם אם היא מודעה לא רלוונטית מלפני שנתיים. הדרישה של הלקוח שלי היא שיהיו לו מודעות "חדשות" דהיינו שהוכנסו אחרי שהוא קבע את הסינון, וזה כמה שהצלחתי להבין אפשר רק אם אני מסמן מה חדש (הוכנס מאותו פרק זמן והלאה ועדיין לא נשמע) ולא מה נקרא או לא נקרא.
כרגע אין דרישה לכמה פעמים הוא נכנס למודעה מסויימת, באמת לא חשבנו על זה לא אני ולא הלקוח... ושוב, תאריך כניסה אחרון לא עוזר לי כי אם הוא נכנס ב-ז כסלו אבל לא שמע מודעה שהוכנסה ב-ה כסלו - אם נלך לפי השיטה של תאריך כניסה, הוא יפספס את המודעה ההיא ואם נלך לפי חדש שלא נקרא הוא לא יפספס אותה.
לא ידעתי שאפשר בעמודה אחת להכניס כמה "מזהי משתמשים שקראו", איך אפשר? פשוט להוסיף פסיק ואחריו את המזהה החדש ואז כשקוראים את זה להפריד למערך לפי הפסיקים?
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
ככה בהתחלה עשיתי, אבל ברגע שאני מסמן רק מה הוא כבר קרא אז אוטומטית כל השאר מוגדר כ"לא נקרא" גם אם היא מודעה לא רלוונטית מלפני שנתיים. הדרישה של הלקוח שלי היא שיהיו לו מודעות "חדשות" דהיינו שהוכנסו אחרי שהוא קבע את הסינון, וזה כמה שהצלחתי להבין אפשר רק אם אני מסמן מה חדש (הוכנס מאותו פרק זמן והלאה ועדיין לא נשמע) ולא מה נקרא או לא נקרא.
אתה מסנן בשאילתה שורות של מודעות שעומדות בשני התנאים, גם לא נקרא וגם חדש מתאריך X
אכן מה שהצעתי בהתחלה לעבוד רק לפי תאריך לא מתאים לצורך העסקי פה וצריך גם לשמור את המידע איזה מודעות נקראו כבר על ידי המשתמש@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
לא ידעתי שאפשר בעמודה אחת להכניס כמה "מזהי משתמשים שקראו", איך אפשר? פשוט להוסיף פסיק ואחריו את המזהה החדש ואז כשקוראים את זה להפריד למערך לפי הפסיקים?
לא כתבת איזה מסד נתונים אתה משתמש, בפוסטגרס יש ממש סוג עמודה של מערך שתומכת באינדקסים והכל
באחרים באמת צריך לעשות מופרד בפסיקים או שדה JSON, או טבלה נפרדת כמו שdovid הציע בשרשור השני@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
מה שהציעו לך באשכול השני זה לא לשכפל את המידע
אבל אני לא מבין, אני לא משכפל את המודעה, אני רק מכניס טלפון ומזהה מודעה (הID שלה).
אתה לא משכפל את כל המידע של המודעה אבל אתה משכפל מידע שהוא נגזרת של שאילתה על טבלת המודעות (איזה שורות עומדות בתנאים XYZ), כטבלה סטטית נוספת
ואז לדוגמה כשאתה יוצר מודעה אתה יוצר לה שורות עבור כל המשתמשים שיש להם התראה מתאימה, וכשהמודעה נמחקת אתה צריך למחוק לא רק את השורה של המודעה, אלא גם את כל השורות שלה בטבלת "מודעות מתאימות למשתמשים"
זה לא תקין, גם אם יש בעיית ביצועים בשאילתה הפתרון הוא אינדקסים ולא שכפול המידע לטבלה סטטיתאבל אם אתה רוצה לפתור את הבעיה "Quick and dirty" פשוט תשמור את המודעות במקום לפי מזהה משתמש, לפי מזהה סינון, ואז אתה ממש לא צריך לגעת בכלום
נ.ב. לגבי מה שכתבתי לשמור גם הסטוריה, כעת אני חושב שגם אם היית רוצה הסטוריה מלאה זה לא אמור להיות ביחד עם המידע האם הטבלה נצפתה כן או לא, אלא בנפרד כטבלת הסטוריה ו-View/Materialized View של viewed ads, או שהטבלה השניה תתעדכן ע"י טריגרים
אבל כיוון שלא צריך, אפשר פשוט לשמור את מספר הצפיות ותאריך צפיה אחרונה ואז מספיק טבלה אחת
