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

[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 העלת באמת טענה עם הד"ת וכו', השאלה כמה אני חייב לדאוג ללקוח לכל הסיפור הזה, זה לא משהו שסוכם מראש, ותכלס יש לוגים די מפורטים על כל פעולה של המאזין, חשבתי במוצר המוגמר לבטל את רובם כמעט, אבל אחרי הטענות שלך אולי אשאיר כמה שיכולים להיות חשובים.
הענין שלוגים זה דבר שאפשר בקלות לשנות ולשכתב.

[eido]

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

[צדיק תמים]

@eido נראה לי שכתבתי כבר את כל ההסברים, זה נהיה דיון מעגלי.

[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

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