הסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת

[eido]

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

מה שהציעו לך באשכול השני זה לא לשכפל את המידע

אבל אני לא מבין, אני לא משכפל את המודעה, אני רק מכניס טלפון ומזהה מודעה (הID שלה).

[צדיק תמים]

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

ככה בהתחלה עשיתי, אבל ברגע שאני מסמן רק מה הוא כבר קרא אז אוטומטית כל השאר מוגדר כ"לא נקרא" גם אם היא מודעה לא רלוונטית מלפני שנתיים. הדרישה של הלקוח שלי היא שיהיו לו מודעות "חדשות" דהיינו שהוכנסו אחרי שהוא קבע את הסינון, וזה כמה שהצלחתי להבין אפשר רק אם אני מסמן מה חדש (הוכנס מאותו פרק זמן והלאה ועדיין לא נשמע) ולא מה נקרא או לא נקרא.

אתה מסנן בשאילתה שורות של מודעות שעומדות בשני התנאים, גם לא נקרא וגם חדש מתאריך X
אכן מה שהצעתי בהתחלה לעבוד רק לפי תאריך לא מתאים לצורך העסקי פה וצריך גם לשמור את המידע איזה מודעות נקראו כבר על ידי המשתמש

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

לא ידעתי שאפשר בעמודה אחת להכניס כמה "מזהי משתמשים שקראו", איך אפשר? פשוט להוסיף פסיק ואחריו את המזהה החדש ואז כשקוראים את זה להפריד למערך לפי הפסיקים?

לא כתבת איזה מסד נתונים אתה משתמש, בפוסטגרס יש ממש סוג עמודה של מערך שתומכת באינדקסים והכל
באחרים באמת צריך לעשות מופרד בפסיקים או שדה JSON, או טבלה נפרדת כמו שdovid הציע בשרשור השני

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

מה שהציעו לך באשכול השני זה לא לשכפל את המידע

אבל אני לא מבין, אני לא משכפל את המודעה, אני רק מכניס טלפון ומזהה מודעה (הID שלה).

אתה לא משכפל את כל המידע של המודעה אבל אתה משכפל מידע שהוא נגזרת של שאילתה על טבלת המודעות (איזה שורות עומדות בתנאים XYZ), כטבלה סטטית נוספת
ואז לדוגמה כשאתה יוצר מודעה אתה יוצר לה שורות עבור כל המשתמשים שיש להם התראה מתאימה, וכשהמודעה נמחקת אתה צריך למחוק לא רק את השורה של המודעה, אלא גם את כל השורות שלה בטבלת "מודעות מתאימות למשתמשים"
זה לא תקין, גם אם יש בעיית ביצועים בשאילתה הפתרון הוא אינדקסים ולא שכפול המידע לטבלה סטטית

אבל אם אתה רוצה לפתור את הבעיה "Quick and dirty" פשוט תשמור את המודעות במקום לפי מזהה משתמש, לפי מזהה סינון, ואז אתה ממש לא צריך לגעת בכלום

---

נ.ב. לגבי מה שכתבתי לשמור גם הסטוריה, כעת אני חושב שגם אם היית רוצה הסטוריה מלאה זה לא אמור להיות ביחד עם המידע האם הטבלה נצפתה כן או לא, אלא בנפרד כטבלת הסטוריה ו-View/Materialized View של viewed ads, או שהטבלה השניה תתעדכן ע"י טריגרים
אבל כיוון שלא צריך, אפשר פשוט לשמור את מספר הצפיות ותאריך צפיה אחרונה ואז מספיק טבלה אחת

[eido]

@צדיק-תמים אומר לך את האמת, אני עדיין חושב שהדרך שלי הכי קלה, אבל בגלל שאתם כמומחים (אני מניח) מתעקשים שלא, אז כנראה שלא...
מה דעת @dovid ?

אני משתמש בphpmyadmin עם מריה אני חושב.

אז למסקנה, מה בדיוק ההמלצה בשבילי, במילים פשוטת שאבין.

אני לא צריך לשמור הסטוריה, ולשמור מזהים מופרדים בפסיק ולהמיר למערך או כג'סון נראה לי לוקח זמן לעבד, אבל אם אתם אומרים אז...

[Shmuel754]

@eido
לפי איך שאני מבין אתה צריך כמה דברים, יתכן שחלקם יש לך ואתה עובד כך, נפרט
תאריך פרסום - בכל מודעה שינוי סטטוס של מודעה אמור להיות תאריך פרסום, שזה אומר שההודעה הזו בתוקף מאותו תאריך.
שינוי סטטוס אומר גם ירידת מחיר מ3000 ל2800 לדוגמא, שינוי כזה יש לסדר מחדש ללקוח מאחר ויתכן שבמחיר 3000 זה לא רלוונטי אבל ב2800 יש על מה לדבר, אתה יכול להוסיף נתון שהמחיר בעבר היה גבוה יותר, וכן פרסום של שכירות משנה קודמת שכרגע הוא שוב בשוק, אמור להיות מוגדר חדש למרות שאותו לקוח שמע בעבר.
הסינון - לולאת הסינון אמור לקחת את כל הפרסומים הרלבנטיים (מינוס X ימים אחורה), ולפתוח רשומה טבלה נוספת הכולל זיהוי לקוח, זיהוי פרסום, תאריך פרסום, תאריך שמיעה.
בהשמעה - אתה משמיע רק את את מה שלא שמע, בכל העברת רשומה בIVR אתה מעדכן תאריך שמיעה.
הבעיה שאתה מציג שבעת החזרת הסינון אחרי שנמחק הסינון, אתה אמור להוסיף רק את הפרסומים הרלוונטיות (מינוס X ימים אחורה) ולא אמור להוסיף את כל הקודמים שהם פחות רלוונטים כרגע.

במשפט קצר, אתה אמור לסנן פרסומים ולא לסנן נכסים, לכל נכס יש הרבה פרסומים בהמשך הזמן.
לגבי מהירות הסינון, כל הDB שלך בגדול הוא 50 אלף רשומות שמבוסס על מספרים אם הוא מאונדקס נכון, אין בעיה של זמן סינון, גם את הלולאה של יצירת רשימות ההשמעה ללקוח, אתה יכול לעשות כטריגר בעת הוספת פרסום ואז שירוץ על כל השורות המכילות את התנאי של הנכס ומתאים לסינון ולהכניס לרשימה, או שפעם בכמה דקות תפעיל לולאה כזו על כל הפרסומים החדשים.
כשהלקוח מתקשר אמור להישלף מה DB רק את הפרסומים המוכנים בשבילו בטבלה ולא יצירה מחדש של סינון דימני.

[eido]

@צדיק-תמים הקוד הבא זה מה שהתכוונת?

$sqlNew = "SELECT * 
        FROM appartments 
        WHERE $where 
        AND created_at >= ?
        AND alreadyRead NOT LIKE ?
         ORDER BY created_at DESC";

$sqlOld = "SELECT * 
        FROM appartments 
        WHERE $where 
        AND (created_at < ? OR alreadyRead LIKE ?)
         ORDER BY created_at DESC";

וזה מסמן כנקרא

$sql = "UPDATE appartments
SET alreadyRead = IF(alreadyRead LIKE ?, alreadyRead, CONCAT(alreadyRead, ?))
WHERE adId = ?";
$stmt = $conn->prepare($sql);
$stmt->bind_param("ssi", "%".$_REQUEST['phone']."%", $_REQUEST['phone'].", ", $_REQUEST['adId']);

[eido]

@Shmuel754 האמת זה רעיון מה שאתה אומר, אומנם לא הצלחתי להבין את כולו (אני לא חזק בתחום הזה), אבל מה שכן הבנתי, מראה על מערכת יותר חכמה.

כבר עכשיו במערכת כל עדכון משנה את ה"תאריך יצור" של המודעה. אך זה לא שומר את הפרטים מה שהיה לפני כן. אז מצד אחד המאזין יקבל אותה כהודעה חדשה אך אני לא אדע מה השתנה בה אם בכלל (יש גם אפשרות של "קידום מודעה"). למרות שאם אני הולך עם הדרך של צדיק תמים אז הוא לא יקבל אותה כחדשה כי היא כבר מסומנת כנקראה.

גם אני חשבתי שחיפוש דינמי פחות טוב, אבל @צדיק-תמים טוען שלא כך צריך להיות... אתה יכול לראות למעלה את טענותיו ולהגיב.

[צדיק תמים]

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

הסינון - לולאת הסינון אמור לקחת את כל הפרסומים הרלבנטיים (מינוס X ימים אחורה), ולפתוח רשומה טבלה נוספת הכולל זיהוי לקוח, זיהוי פרסום, תאריך פרסום, תאריך שמיעה.

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

כשהלקוח מתקשר אמור להישלף מה DB רק את הפרסומים המוכנים בשבילו בטבלה ולא יצירה מחדש של סינון דימני.

בשביל מה טבלה סטטית נוספת שמתוחזקת על ידי לולאת הסינון? אתה יוצר כפילות מיותרת של מידע

לגבי הפרדת פרסומים מנכסים זה כיוון מעניין אבל לדעתי לא צריך להגיע לזה. בגדול זה לוח מודעות דיגיטלי, לא מערכת ניהול נכסים, לא בטוח בכלל שאת אותו נכס יפרסם אותו אדם כל פעם, לא אמור להיות יישות נפרדת של נכס לדעתי

[Shmuel754]

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

בשביל מה טבלה סטטית נוספת שמתוחזקת על ידי לולאת הסינון? אתה יוצר כפילות מיותרת של מידע

לגבי הפרדת פרסומים מנכסים זה כיוון מעניין אבל לדעתי לא צריך להגיע לזה. בגדול זה לוח מודעות דיגיטלי, לא מערכת ניהול נכסים, לא בטוח בכלל שאת אותו נכס יפרסם אותו אדם כל פעם, לא אמור להיות יישות נפרדת של נכס לדעתי

אין כאן כפילות של מידע, כשאתה מפרסם נכסים עבור לקוחות (דהיינו מתעניינים בפרסומים), יש לך ענף חדש לניהול שזה לקוח מתעניין איזה מידע קיבל, מתי, ולמה, זה מידע שנוצר מסינון דינמי של המידע (כל רגע נתון) למידע סטטי מול הלקוח.

וכך לגבי הפרדת פרסומים מנכסים, יש כן מקרים שאותו בעל נכס מפרסם מחדש אותו נכס, כמו בשכירות כל שנה מחדש, שהנכס אותו נכס אותם פרטים אותם בעלים, אבל הושכר לפני שנה וכעת חזר לשוק.

ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.

במילים אחרות, כל נתון שנראה לא רלוונטי כיום, הופך מאוד רלוונטי בעתיד, כשאתה נצרך לזה.

מה גם שכל הDB שלו לא יקרוס מרוב חומר, מדובר בעשרות אלפים בודדים של חומר של כמה גיגות לכל היותר, ולא צורך של גישה מרובה בכל רגע נתון.

[צדיק תמים]

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

אין כאן כפילות של מידע, כשאתה מפרסם נכסים עבור לקוחות (דהיינו מתעניינים בפרסומים), יש לך ענף חדש לניהול שזה לקוח מתעניין איזה מידע קיבל, מתי, ולמה, זה מידע שנוצר מסינון דינמי של המידע (כל רגע נתון) למידע סטטי מול הלקוח.

לא ענית למה זה צריך להיות בטבלה סטטית שמתעדכנת על ידי תהליך רקע ולא פלטור בזמן אמת

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.

אבל את כל זה אפשר לעשות גם בלי להפריד לשכבת נכסים ושכבת מודעות, אף אחד לא אמר למחוק מהדאטהבייס לגמרי את המודעה שנהפכה ללא רלוונטית או את הלוגים שלה
מה שתיארת זה audit log למקרי קצה ורגולציה זה לא אמור להשפיע על מבנה הנתונים עצמם

[צדיק תמים]

בכל מקרה, לגבי ההפרדה לנכסים ומודעות, אני לא מתנגד לזה נחרצות,
רק לטבלת ה"מודעות לצפיית הלקוח" שמשכפלת מידע שמשתנה כל רגע ואמורה להיות רק שאילתה בזמן אמת

[Shmuel754]

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

אין כאן כפילות של מידע, כשאתה מפרסם נכסים עבור לקוחות (דהיינו מתעניינים בפרסומים), יש לך ענף חדש לניהול שזה לקוח מתעניין איזה מידע קיבל, מתי, ולמה, זה מידע שנוצר מסינון דינמי של המידע (כל רגע נתון) למידע סטטי מול הלקוח.

לא ענית למה זה צריך להיות בטבלה סטטית שמתעדכנת על ידי תהליך רקע ולא פלטור בזמן אמת

כי ברגע שהוא רוצה להוציא התראה צינתוק למתעניין, התהליך של פלטור בזמן אמת הופך למשימה שלו שהוא צריך לבצע, ולכן הוא מניע את התהליך בחיפוש ורישום, תהליך חד-פעמי, שהמשך המתקשר רק שולף נתונים.

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.

אבל את כל זה אפשר לעשות גם בלי להפריד לשכבת נכסים ושכבת מודעות, אף אחד לא אמר למחוק מהדאטהבייס לגמרי את המודעה שנהפכה ללא רלוונטית או את הלוגים שלה
מה שתיארת זה audit log זה לא אמור להשפיע על מבנה הנתונים

נרשם למעלה שהוא מעדכן את תאריך המודעה בהתאם לתאריך שהוא רוצה לפרסם,
והלוג של מחר זה הנתונים של היום, וכל הנושא זה המבט מלמעלה לראות את כל ההיסטוריה בסדר יורד, מבלי לנהל לוג נפרד.

[צדיק תמים]

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

כי ברגע שהוא רוצה להוציא התראה צינתוק למתעניין, התהליך של פלטור בזמן אמת הופך למשימה שלו שהוא צריך לבצע, ולכן הוא מניע את התהליך בחיפוש ורישום, תהליך חד-פעמי, שהמשך המתקשר רק שולף נתונים.

זה לא תהליך חד פעמי, זה מתעדכן בכל הוספת/שינוי/מחיקה של מודעה. אולי לא הבנתי אותך נכון, מה מטרת הטבלה הזאת?

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

נרשם למעלה שהוא מעדכן את תאריך המודעה בהתאם לתאריך שהוא רוצה לפרסם,
והלוג של מחר זה הנתונים של היום, וכל הנושא זה המבט מלמעלה לראות את כל ההיסטוריה בסדר יורד, מבלי לנהל לוג נפרד.

אני לא מסכים, נתונים והסטוריה זה לא אותו דבר, בתפקוד השוטף של האפליקציה אין עניין להתעסק עם ההסטוריה הסטוריה מיועדת למקרי קצה שתיארת אותם יפה, שמישהו רוצה לדעת מה היה קודם ומה אחר כך, לזה מספיק טבלאות נפרדות של הסטוריה או audit log, לא הגיוני בגלל זה לסרבל את כל המבנה של הנתונים

[eido]

כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

@צדיק-תמים הקוד הבא זה מה שהתכוונת?

$sqlNew = "SELECT *
FROM appartments
WHERE $where
AND created_at >= ?
AND alreadyRead NOT LIKE ?
ORDER BY created_at DESC";

$sqlOld = "SELECT *
FROM appartments
WHERE $where
AND (created_at < ? OR alreadyRead LIKE ?)
ORDER BY created_at DESC";
וזה מסמן כנקרא

$sql = "UPDATE appartments
SET alreadyRead = IF(alreadyRead LIKE ?, alreadyRead, CONCAT(alreadyRead, ?))
WHERE adId = ?";
$stmt = $conn->prepare($sql);
$stmt->bind_param("ssi", "%".$_REQUEST['phone']."%", $_REQUEST['phone'].", ", $_REQUEST['adId']);

@צדיק-תמים

[צדיק תמים]

@eido אם אין לך אפשרות לעמודת ARRAY ממש, עדיף עם טבלה נפרדת כדי שתוכל לעשות אינדקסים

[eido]

@צדיק-תמים אין array...
השאלה כמה זה קריטי, זה לא יד2... לא מאמין שזה יהיה גדול בצורה משמעותית.

[Shmuel754]

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

כי ברגע שהוא רוצה להוציא התראה צינתוק למתעניין, התהליך של פלטור בזמן אמת הופך למשימה שלו שהוא צריך לבצע, ולכן הוא מניע את התהליך בחיפוש ורישום, תהליך חד-פעמי, שהמשך המתקשר רק שולף נתונים.

זה לא תהליך חד פעמי, זה מתעדכן בכל הוספת/שינוי/מחיקה של מודעה. אולי לא הבנתי אותך נכון, מה מטרת הטבלה הזאת? מעין לוג כדי שנוכל לראות בעתיד איזה התראות נשלחו ללקוח?

אני מסתכל על זה כך,
נכס, כוללים נתונים שאינם משתנים, לא ישוב ורחוב ולא חדרים ולא בעלים, אם זה משתנה מדובר במודעה/נכס אחר מה שמשתנה זה המחיר, ותאריך הפרסום, וזה נתונים שיש לנהל, ברור שזה מקושר למודעה וזה טבלת הפרסומים, כשאתה רושם שינוי של המודעה הכוונה כנראה לנתוני הפרסום ולא לנתוני הבסיס.
כשהנתונים לא רלוונטים, אתה לא מוחק אותם אבל זה הופך לסוג של היסטוריה, ואם תרצה תקרא לזה לוג.

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

נרשם למעלה שהוא מעדכן את תאריך המודעה בהתאם לתאריך שהוא רוצה לפרסם,
והלוג של מחר זה הנתונים של היום, וכל הנושא זה המבט מלמעלה לראות את כל ההיסטוריה בסדר יורד, מבלי לנהל לוג נפרד.

אני לא מסכים, נתונים והסטוריה זה לא אותו דבר, בתפקוד השוטף של האפליקציה אין עניין להתעסק עם ההסטוריה הסטוריה מיועדת למקרי קצה שתיארת אותם יפה, שמישהו רוצה לדעת מה היה קודם ומה אחר כך, לזה מספיק טבלאות נפרדות של הסטוריה או audit log, לא הגיוני בגלל זה לסרבל את כל המבנה של הנתונים

[eido]

@Shmuel754 העלת באמת טענה עם הד"ת וכו', השאלה כמה אני חייב לדאוג ללקוח לכל הסיפור הזה, זה לא משהו שסוכם מראש, ותכלס יש לוגים די מפורטים על כל פעולה של המאזין, חשבתי במוצר המוגמר לבטל את רובם כמעט, אבל אחרי הטענות שלך אולי אשאיר כמה שיכולים להיות חשובים.
הענין שלוגים זה דבר שאפשר בקלות לשנות ולשכתב.