הסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת
-
@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, או שהטבלה השניה תתעדכן ע"י טריגרים
אבל כיוון שלא צריך, אפשר פשוט לשמור את מספר הצפיות ותאריך צפיה אחרונה ואז מספיק טבלה אחת -
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
ככה בהתחלה עשיתי, אבל ברגע שאני מסמן רק מה הוא כבר קרא אז אוטומטית כל השאר מוגדר כ"לא נקרא" גם אם היא מודעה לא רלוונטית מלפני שנתיים. הדרישה של הלקוח שלי היא שיהיו לו מודעות "חדשות" דהיינו שהוכנסו אחרי שהוא קבע את הסינון, וזה כמה שהצלחתי להבין אפשר רק אם אני מסמן מה חדש (הוכנס מאותו פרק זמן והלאה ועדיין לא נשמע) ולא מה נקרא או לא נקרא.
אתה מסנן בשאילתה שורות של מודעות שעומדות בשני התנאים, גם לא נקרא וגם חדש מתאריך X
אכן מה שהצעתי בהתחלה לעבוד רק לפי תאריך לא מתאים לצורך העסקי פה וצריך גם לשמור את המידע איזה מודעות נקראו כבר על ידי המשתמש@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
לא ידעתי שאפשר בעמודה אחת להכניס כמה "מזהי משתמשים שקראו", איך אפשר? פשוט להוסיף פסיק ואחריו את המזהה החדש ואז כשקוראים את זה להפריד למערך לפי הפסיקים?
לא כתבת איזה מסד נתונים אתה משתמש, בפוסטגרס יש ממש סוג עמודה של מערך שתומכת באינדקסים והכל
באחרים באמת צריך לעשות מופרד בפסיקים או שדה JSON, או טבלה נפרדת כמו שdovid הציע בשרשור השני@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
מה שהציעו לך באשכול השני זה לא לשכפל את המידע
אבל אני לא מבין, אני לא משכפל את המודעה, אני רק מכניס טלפון ומזהה מודעה (הID שלה).
אתה לא משכפל את כל המידע של המודעה אבל אתה משכפל מידע שהוא נגזרת של שאילתה על טבלת המודעות (איזה שורות עומדות בתנאים XYZ), כטבלה סטטית נוספת
ואז לדוגמה כשאתה יוצר מודעה אתה יוצר לה שורות עבור כל המשתמשים שיש להם התראה מתאימה, וכשהמודעה נמחקת אתה צריך למחוק לא רק את השורה של המודעה, אלא גם את כל השורות שלה בטבלת "מודעות מתאימות למשתמשים"
זה לא תקין, גם אם יש בעיית ביצועים בשאילתה הפתרון הוא אינדקסים ולא שכפול המידע לטבלה סטטיתאבל אם אתה רוצה לפתור את הבעיה "Quick and dirty" פשוט תשמור את המודעות במקום לפי מזהה משתמש, לפי מזהה סינון, ואז אתה ממש לא צריך לגעת בכלום
נ.ב. לגבי מה שכתבתי לשמור גם הסטוריה, כעת אני חושב שגם אם היית רוצה הסטוריה מלאה זה לא אמור להיות ביחד עם המידע האם הטבלה נצפתה כן או לא, אלא בנפרד כטבלת הסטוריה ו-View/Materialized View של viewed ads, או שהטבלה השניה תתעדכן ע"י טריגרים
אבל כיוון שלא צריך, אפשר פשוט לשמור את מספר הצפיות ותאריך צפיה אחרונה ואז מספיק טבלה אחת@צדיק-תמים אומר לך את האמת, אני עדיין חושב שהדרך שלי הכי קלה, אבל בגלל שאתם כמומחים (אני מניח) מתעקשים שלא, אז כנראה שלא...
מה דעת @dovid ?אני משתמש בphpmyadmin עם מריה אני חושב.
אז למסקנה, מה בדיוק ההמלצה בשבילי, במילים פשוטת שאבין.
אני לא צריך לשמור הסטוריה, ולשמור מזהים מופרדים בפסיק ולהמיר למערך או כג'סון נראה לי לוקח זמן לעבד, אבל אם אתם אומרים אז...
-
@eido
לפי איך שאני מבין אתה צריך כמה דברים, יתכן שחלקם יש לך ואתה עובד כך, נפרט
תאריך פרסום - בכל מודעה שינוי סטטוס של מודעה אמור להיות תאריך פרסום, שזה אומר שההודעה הזו בתוקף מאותו תאריך.
שינוי סטטוס אומר גם ירידת מחיר מ3000 ל2800 לדוגמא, שינוי כזה יש לסדר מחדש ללקוח מאחר ויתכן שבמחיר 3000 זה לא רלוונטי אבל ב2800 יש על מה לדבר, אתה יכול להוסיף נתון שהמחיר בעבר היה גבוה יותר, וכן פרסום של שכירות משנה קודמת שכרגע הוא שוב בשוק, אמור להיות מוגדר חדש למרות שאותו לקוח שמע בעבר.
הסינון - לולאת הסינון אמור לקחת את כל הפרסומים הרלבנטיים (מינוס X ימים אחורה), ולפתוח רשומה טבלה נוספת הכולל זיהוי לקוח, זיהוי פרסום, תאריך פרסום, תאריך שמיעה.
בהשמעה - אתה משמיע רק את את מה שלא שמע, בכל העברת רשומה בIVR אתה מעדכן תאריך שמיעה.
הבעיה שאתה מציג שבעת החזרת הסינון אחרי שנמחק הסינון, אתה אמור להוסיף רק את הפרסומים הרלוונטיות (מינוס X ימים אחורה) ולא אמור להוסיף את כל הקודמים שהם פחות רלוונטים כרגע.במשפט קצר, אתה אמור לסנן פרסומים ולא לסנן נכסים, לכל נכס יש הרבה פרסומים בהמשך הזמן.
לגבי מהירות הסינון, כל הDB שלך בגדול הוא 50 אלף רשומות שמבוסס על מספרים אם הוא מאונדקס נכון, אין בעיה של זמן סינון, גם את הלולאה של יצירת רשימות ההשמעה ללקוח, אתה יכול לעשות כטריגר בעת הוספת פרסום ואז שירוץ על כל השורות המכילות את התנאי של הנכס ומתאים לסינון ולהכניס לרשימה, או שפעם בכמה דקות תפעיל לולאה כזו על כל הפרסומים החדשים.
כשהלקוח מתקשר אמור להישלף מה DB רק את הפרסומים המוכנים בשבילו בטבלה ולא יצירה מחדש של סינון דימני.
