הסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת
-
תודה.
אבל כמו שאמרתי, אני לא רוצה שינויים מהותיים, גם ככה הקוד מסורבל בגלל הוספות של הלקוח שהייתי צריך בגללם לשנות את הקוד בצורה מהותית. וזו גם הסיבה לטבלאות כביכול מיותרות.השאלה, הדרך שהוספתי לא יותר קלה ופשוטה? בלי לשנות או להוסיף טבלאות, בלי לשנות את מבנה הקוד (כל שינוי כזה צריך להיות בכמה מקומות ואין לי כח לסבב באגים נוסף...
-
תודה.
אבל כמו שאמרתי, אני לא רוצה שינויים מהותיים, גם ככה הקוד מסורבל בגלל הוספות של הלקוח שהייתי צריך בגללם לשנות את הקוד בצורה מהותית. וזו גם הסיבה לטבלאות כביכול מיותרות.השאלה, הדרך שהוספתי לא יותר קלה ופשוטה? בלי לשנות או להוסיף טבלאות, בלי לשנות את מבנה הקוד (כל שינוי כזה צריך להיות בכמה מקומות ואין לי כח לסבב באגים נוסף...
-
תודה.
אבל כמו שאמרתי, אני לא רוצה שינויים מהותיים, גם ככה הקוד מסורבל בגלל הוספות של הלקוח שהייתי צריך בגללם לשנות את הקוד בצורה מהותית. וזו גם הסיבה לטבלאות כביכול מיותרות.השאלה, הדרך שהוספתי לא יותר קלה ופשוטה? בלי לשנות או להוסיף טבלאות, בלי לשנות את מבנה הקוד (כל שינוי כזה צריך להיות בכמה מקומות ואין לי כח לסבב באגים נוסף...
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
השאלה, הדרך שהוספתי לא יותר קלה ופשוטה? בלי לשנות או להוסיף טבלאות, בלי לשנות את מבנה הקוד (כל שינוי כזה צריך להיות בכמה מקומות ואין לי כח לסבב באגים נוסף...
לכאורה הדרך שלי יותר קלה פשוטה ונכונה ועם פחות שינויים בקוד, כמובן שאיני נביא וייתכן שאצלך זה ייצא אחרת, אני לא יודע לייעץ לך טוב יותר.
-
@eido לא נשמע לי הוגן לתת ללקוח אפליקציה שכמו שנשמע עשויה להתפתח עוד בעתיד, שהסכמה שלה בנויה בצורה עקומה, בגלל שאין לך כח לשנות
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@eido לא נשמע לי הוגן לתת ללקוח אפליקציה שכמו שנשמע עשויה להתפתח עוד בעתיד, שהסכמה שלה בנויה בצורה עקומה, בגלל שאין לך כח לשנות
אתה תופס אותי על המילה...
האפליקציה בנויה היטב (לפחות במושגים שלי, ואני משתדל לא להתחבא מאחורי סיסמאות כמו "זה לא באג זה פיצ'ר" כמו שקורה לעיתים אפילו בחברות הגדולות ביותר...), רק שיכולתי לקצר חלק מהקוד ולעשות פונקציות יותר גנריות, כך שבסוף יש קוד כפול אבל די מובן.אני לא חושב שיש עוד התקדמות לקוד הזה, זו מערכת גדולה וכתבתי כאן רק חלק ממנה. וגם אם יש, אם יבקש ממישהו אחר, סביר להניח שגם ככה היה מסתבך, אנשים מעדיפים לכתוב את הכל מחדש ולא להתחיל לשנות קוד של מישהו אחר. ואם יבוא אליי אז מצויין, אדע כבר מה לעשות.
אם כבר, אני זה שהגדלתי ראש ובאתי לקראתו (ושלמתי על זה ביוקר...), הלקוח ביקש API לקו ואני חילקתי את זה ובניתי לו "ליבה" וקוד לקו, כך שאם מחר ירצה להוסיף אתר או משהו יוכל להתממשק לליבה בלי צורך לבנות הכל מחדש.
וגם אם לא הכל חלק, לדעתי זה מחיר של שינויים מהותיים (הלקוח לא יודע מה מהותי ומה לא מבחינתו זה "שינוי קטן") בפיתוח (ועוד שינוי בחינם!), אחרי שהמערכת כבר כמעט בנויה אני לא אזרוק הכל לפח בגלל איזה שינוי שהוא רוצה, ננסה להתאים את הקוד.
גם שים לב, הבעיה הזאת היא לא בעיה אמיתית, היא רק עלולה להיווצר בתנאים מסויימים מאוד (בתנאי שהיו כמה סינונים מקבילים, בתנאי שמחקו אחד מהם והתחרטו והוסיפו אותו ובתנאי שמוכר הדירה לא מחק את המודעה אחרי שכבר מכר אותה... כי אם עוד לא מכר אז המודעה רלוונטית ואם מכר אז סביר להניח שמחק אותה כדי שלא יחפרו לו סתם...) ובכל זאת אני מנסה לסדר את זה, אבל לא רוצה להגזים בתיקון.
-
האמת שהשתדלתי לפרט אבל רצתי להוציא את הילדים אז השתדלתי לצמצם במסגרת ההרחבה.
יש 4 טבלאות בעיקרון, אבל מה שמעניין אותנו זה 3 כמו שאמרת:
מודעות:id, buyorrent, city, betShemesh, region, street, number, floor, room, price, phone, phone2, created_at, kidum
סינונים: id, buyorrent, city, betShemesh, region, room, phone
מודעות לפי לקוח: id, phone, adId.האפליקציה (לא אוהב לקרוא לזה ככה זה כולה קוד בnodejs על שרת....) לוקח את הסינונים שהגדיר הלקוח, ועל פיהם הוא מושך את המודעות הID שלהם נמצא עם מספר הלקוח. כמובן המודעה נמצאת רק פעם אחת בטבלה של המודעות לפי לקוח.
מושכים את המודעות לפי הסינון, לכל סינון בנפרד, ככה לכל סינון מקבלים את כל המודעות המבוקשות, גם אם הן כפולות שהרי אם מישהו הגדיר ירושלים וירושלים + שכונה הוא יקבל מודעה גם בירושלים וגם בירושלים + שכונה.עכשיו במקרה שאני לא מוחק את ההודעות המשוייכות אליו (מהטבלה של מודעות לפי לקוח), אם מחר הוא ימחק את ירושלים, אבל לא את ירושלים + שכונה הכל בסדר הוא עדין יראה את המודעות האלו. אבל אם הוא הגדיר רק ירושלים ומחק את זה ועוד שנתיים הוא הגדיר שוב ירושלים, הוא יקבל את המודעות האלו, שהם כבר ישנות, כי לא מחקנו אותן.
אם אני כן מוחק את המודעות האלו, אז אם הוא ימחוק רק את הסינון של ירושלים, ימחקו לו גם מודעות של ירושלים + שכונה.
ככה שאני צריך למצוא פתרון שמצד אחד לא ישארו מודעות מיותרות ומצד שני לא למחוק מודעות רלוונטיות.
אני לא רוצה לשנות את הצורה שהקוד עובד בצורה משמעותית, כי במחינתי הקוד גמור ומוכן למסירה וזה עכשיו לשנות הכל.לכן חשבתי על הפתרון הנ"ל. לבדוק ברשימת כל המודעות איזו מודעה מופיעה כמה פעמים וזה אומר שהיא שייכת לכמה סינונים ואותה לא למחוק, ומה שלא מופיע כמה פעמים כנראה לא שייך לכמה סינונים ואפשר למחוק.
-
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
האפליקציה (לא אוהב לקרוא לזה ככה זה כולה קוד בnodejs על שרת....)
סתם להבין, מה לדעתך ראוי בכבוד לשם אפליקציה?
-
אני בונה מערכת לנדל"ן, לקוח יכול לבחור לקבל התראה על דירות חדשות לפי סינון, הוא יכול גם למחוק את הסינון. המודעות הרלוונטיות נשמרות במסד נתונים מסוים עם טלפון של הלקוח, וID של המודעה והספרה 1 בתור אינדיקציה שהיא חדשה (המבנה מאולץ בגלל שינויים הכרחיים).
הסינון יכול להיות לדוגמא. ירושלים / ירושלים + שכונה / ירושלים + שכונה + חדרים.
אם הלקוח מוחק התראה אז הוא לא ישמע יותר את המודעות הלא רלוונטיות כי מושכים את המודעות לפי הסינונים שלו ובגלל שהסינון הזה כבר לא קיים הוא לא ישמע את המודעה למרות שהיא עוד קיימת אצלו, הבאג שיכול להיווצר הוא שהוא יכול למחוק עכשיו את הסינון ועוד חודשיים להחזיר אותו, ויעלו לו גם ההודעות הישנות, שזה לא טוב. ואני לא יכול למחוק את ההודעות מהמסד נתונים בגלל שאם היו לו 2 סינונים ירושלים וירושלים + שכונה, והוא מחק רק את הירושלים + שכונה, אם נמחק את כל המודעות שלו זה ימחק גם הודעות שכן אמורות להתפס בסינון של ירושלים...אני צריך למצוא דרך למחוק רק את ההודעות שלא אמורות להישאר בגלל שום סינון.
חשבתי לעבור על כל ההודעות שנשמרו (האפליקציה שומרת את כל המודעות של כל הסינונים, גם אם הן כפולות בגלל שיש כמה סינונים) ולראות אם יש ID כפול אז לא למחוק ואם אין ID כפול למחוק.
אני יודע שזה לא הדרך הכי טובה, אבל אני לא רוצה לשנות את כל המבנה כי אני ממש בסוף הפרוייקט ואני מאמין שאם משהו עובד - אל תיגע בו, כי תחזור כמה צעדים אחורה.
השאלה אם בכל זאות זו דרך טובה או שיש דרך אחרת.@eido
איפה המסד \ אפליקצייה יושב זה מסד סודי? פרטי?
אולי אתה פשוט יכול פרסם קישור.
ואם יש למישהו זמן יעיף מבט במה שעשית. -
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
אתה צריך להוסיף מזהה לקוח לטבלת הסינונים,
אם אתה מתעקש להמשיך עם המבנה הנוכחי תעשה את הטבלה במקום מודעות לפי מזהה לקוח, מודעות לפי מזהה סינון, אבל רצוי יותר לוותר לגמרי על הטבלה הזו ולחשב את המודעות המתאימות לסינון בזמן אמת@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
לא כ"כ הבנתי את ההצעה שלך, אני לא כ"כ חזק בsql ומסדי נתונים.
יש טבלה אחת כללית של מודעות
וטבלה אחת של מודעות חדשות פר לקוח וזה בגלל שאני צריך לדעת להבדיל בין המודעות החדשות שהן לאו דווקא חדשות, אלא אלו שהוא לא שמע עדיין גם אם הוא שמע כבר אחרות, זאת אומרת יכול להיות שהוא נכנס ושמע את הדירות של בית שמש, אבל לא את של ירושלים אז אלו של ירושלים עדיין יושמעו בתור חדשות, גם אם הן הוכנסו לפני של בית שמש. וכן אם הוא רק התחיל לשמוע את המודעות של ירושלים אז אלו שהוא עדיין לא שמע יושמעו כחדשות. ככה זה נותן לי לנהל את המודעות בצורה הכי טובה.כמה שהצלחתי לחשוב האופציה הכי טובה היא פשוט לעשות מודעות חדשות פר לקוח. זה על הרעיון של מה שהצעתם לי כאן.
תאריך כניסה אחרונה לא עוזר לי, כי יכול להיות שהוא לא שמע את כל המודעות שהיו עד עכשיו ואם אחשב לפי תאריך שמיעה אחרונה אז הוא יפספס מודעות.
בטבלת הסינונים כבר יש מזהה לקוח - הטלפון.
מהסיבה הנ"ל אני לא יכול לחשב סינון בזמן אמת, כי אני צריך אינדיקציה ברורה מה הוא שמע ומה לא. -
תודה על הפירוט הנוסף.
תכין טבלה נוספת "מודעות להסתרה", עמודות: מס' לקוח, מס' מודעה.
בעת השליפה תחבר את המודעות לפי לקוח לטבלה הזו עם 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 שלה).
