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

[dovid]

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

[eido]

האמת שהשתדלתי לפרט אבל רצתי להוציא את הילדים אז השתדלתי לצמצם במסגרת ההרחבה.

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

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

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

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

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

[צדיק תמים]

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

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

[dovid]

תודה על הפירוט הנוסף.
תכין טבלה נוספת "מודעות להסתרה", עמודות: מס' לקוח, מס' מודעה.
בעת השליפה תחבר את המודעות לפי לקוח לטבלה הזו עם LEFT JOIN ותוודא שמס' מודעה ריק, או שתבדוק עם NOT EXSIST שאין שמה שורה על מודעה זו.

[eido]

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

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

[צדיק תמים]

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

[dovid]

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

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

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

[eido]

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

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

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

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

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

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

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

[dovid]

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

האפליקציה (לא אוהב לקרוא לזה ככה זה כולה קוד בnodejs על שרת....)

סתם להבין, מה לדעתך ראוי בכבוד לשם אפליקציה?

[eido]

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

אני רוצה להגיב על מה שהצעת מקודם, אבל אעשה את זה במוצא"ש בעז"ה יותר בישוב הדעת.

[eido]

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