צ
@eido כתב בבירור על מערכת סליקת אשראי מתאימה לאתר עם מודל מנויים:
התכוונתי שבשנה הראשונה מדווחים כל חודש (וגם משלמים אם צריך) ושנה אח"כ כבר לא צריך (כך אצלי לפחות).
אני לא יודע מתי פתחת, אבל כנראה לפני רפורמת עסק זעיר
ההליך היום הרבה יותר פשוט, תיאום מס לפני סוף שנה ודיווח ותשלום מס בתחילת השנה שאחריה, שניהם בממשקים סבירים (יחסית לרשות המיסים) ולא טפסי ענק מסובכים
וזהו
@eido המידע מי שמע הוא מידע שאתה צריך אותו. הוא לא תוצר של פילטור, ולכן הגיוני לשמור אותו. המידע "המודעה הזאת מתאימה למשתמש הזה כי הוא לא ראה אותה עדיין ויש לו קמפיין מתאים" הוא תוצר של שאילתה ויכול להשתנות בכל רגע ולכן לא שומרים אותו בצורה סטטית
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות
אם תהיה לך בעיית איטיות אחרי אינדקסים מתאימים נדבר, לא נראה לי סביר שתגיע לזה
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
כי ברגע שהוא רוצה להוציא התראה צינתוק למתעניין, התהליך של פלטור בזמן אמת הופך למשימה שלו שהוא צריך לבצע, ולכן הוא מניע את התהליך בחיפוש ורישום, תהליך חד-פעמי, שהמשך המתקשר רק שולף נתונים.
זה לא תהליך חד פעמי, זה מתעדכן בכל הוספת/שינוי/מחיקה של מודעה. אולי לא הבנתי אותך נכון, מה מטרת הטבלה הזאת?
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
נרשם למעלה שהוא מעדכן את תאריך המודעה בהתאם לתאריך שהוא רוצה לפרסם,
והלוג של מחר זה הנתונים של היום, וכל הנושא זה המבט מלמעלה לראות את כל ההיסטוריה בסדר יורד, מבלי לנהל לוג נפרד.
אני לא מסכים, נתונים והסטוריה זה לא אותו דבר, בתפקוד השוטף של האפליקציה אין עניין להתעסק עם ההסטוריה הסטוריה מיועדת למקרי קצה שתיארת אותם יפה, שמישהו רוצה לדעת מה היה קודם ומה אחר כך, לזה מספיק טבלאות נפרדות של הסטוריה או audit log, לא הגיוני בגלל זה לסרבל את כל המבנה של הנתונים
בכל מקרה, לגבי ההפרדה לנכסים ומודעות, אני לא מתנגד לזה נחרצות,
רק לטבלת ה"מודעות לצפיית הלקוח" שמשכפלת מידע שמשתנה כל רגע ואמורה להיות רק שאילתה בזמן אמת
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אין כאן כפילות של מידע, כשאתה מפרסם נכסים עבור לקוחות (דהיינו מתעניינים בפרסומים), יש לך ענף חדש לניהול שזה לקוח מתעניין איזה מידע קיבל, מתי, ולמה, זה מידע שנוצר מסינון דינמי של המידע (כל רגע נתון) למידע סטטי מול הלקוח.
לא ענית למה זה צריך להיות בטבלה סטטית שמתעדכנת על ידי תהליך רקע ולא פלטור בזמן אמת
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.
אבל את כל זה אפשר לעשות גם בלי להפריד לשכבת נכסים ושכבת מודעות, אף אחד לא אמר למחוק מהדאטהבייס לגמרי את המודעה שנהפכה ללא רלוונטית או את הלוגים שלה
מה שתיארת זה audit log למקרי קצה ורגולציה זה לא אמור להשפיע על מבנה הנתונים עצמם
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
הסינון - לולאת הסינון אמור לקחת את כל הפרסומים הרלבנטיים (מינוס X ימים אחורה), ולפתוח רשומה טבלה נוספת הכולל זיהוי לקוח, זיהוי פרסום, תאריך פרסום, תאריך שמיעה.
@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
כשהלקוח מתקשר אמור להישלף מה DB רק את הפרסומים המוכנים בשבילו בטבלה ולא יצירה מחדש של סינון דימני.
בשביל מה טבלה סטטית נוספת שמתוחזקת על ידי לולאת הסינון? אתה יוצר כפילות מיותרת של מידע
לגבי הפרדת פרסומים מנכסים זה כיוון מעניין אבל לדעתי לא צריך להגיע לזה. בגדול זה לוח מודעות דיגיטלי, לא מערכת ניהול נכסים, לא בטוח בכלל שאת אותו נכס יפרסם אותו אדם כל פעם, לא אמור להיות יישות נפרדת של נכס לדעתי
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
ככה בהתחלה עשיתי, אבל ברגע שאני מסמן רק מה הוא כבר קרא אז אוטומטית כל השאר מוגדר כ"לא נקרא" גם אם היא מודעה לא רלוונטית מלפני שנתיים. הדרישה של הלקוח שלי היא שיהיו לו מודעות "חדשות" דהיינו שהוכנסו אחרי שהוא קבע את הסינון, וזה כמה שהצלחתי להבין אפשר רק אם אני מסמן מה חדש (הוכנס מאותו פרק זמן והלאה ועדיין לא נשמע) ולא מה נקרא או לא נקרא.
אתה מסנן בשאילתה שורות של מודעות שעומדות בשני התנאים, גם לא נקרא וגם חדש מתאריך X
אכן מה שהצעתי בהתחלה לעבוד רק לפי תאריך לא מתאים לצורך העסקי פה וצריך גם לשמור את המידע איזה מודעות נקראו כבר על ידי המשתמש
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
לא ידעתי שאפשר בעמודה אחת להכניס כמה "מזהי משתמשים שקראו", איך אפשר? פשוט להוסיף פסיק ואחריו את המזהה החדש ואז כשקוראים את זה להפריד למערך לפי הפסיקים?
לא כתבת איזה מסד נתונים אתה משתמש, בפוסטגרס יש ממש סוג עמודה של מערך שתומכת באינדקסים והכל
באחרים באמת צריך לעשות מופרד בפסיקים או שדה JSON, או טבלה נפרדת כמו שdovid הציע בשרשור השני
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
מה שהציעו לך באשכול השני זה לא לשכפל את המידע
אבל אני לא מבין, אני לא משכפל את המודעה, אני רק מכניס טלפון ומזהה מודעה (הID שלה).
אתה לא משכפל את כל המידע של המודעה אבל אתה משכפל מידע שהוא נגזרת של שאילתה על טבלת המודעות (איזה שורות עומדות בתנאים XYZ), כטבלה סטטית נוספת
ואז לדוגמה כשאתה יוצר מודעה אתה יוצר לה שורות עבור כל המשתמשים שיש להם התראה מתאימה, וכשהמודעה נמחקת אתה צריך למחוק לא רק את השורה של המודעה, אלא גם את כל השורות שלה בטבלת "מודעות מתאימות למשתמשים"
זה לא תקין, גם אם יש בעיית ביצועים בשאילתה הפתרון הוא אינדקסים ולא שכפול המידע לטבלה סטטית
אבל אם אתה רוצה לפתור את הבעיה "Quick and dirty" פשוט תשמור את המודעות במקום לפי מזהה משתמש, לפי מזהה סינון, ואז אתה ממש לא צריך לגעת בכלום
נ.ב. לגבי מה שכתבתי לשמור גם הסטוריה, כעת אני חושב שגם אם היית רוצה הסטוריה מלאה זה לא אמור להיות ביחד עם המידע האם הטבלה נצפתה כן או לא, אלא בנפרד כטבלת הסטוריה ו-View/Materialized View של viewed ads, או שהטבלה השניה תתעדכן ע"י טריגרים
אבל כיוון שלא צריך, אפשר פשוט לשמור את מספר הצפיות ותאריך צפיה אחרונה ואז מספיק טבלה אחת
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
לא כ"כ הבנתי את ההצעה שלך, אני לא כ"כ חזק בsql ומסדי נתונים.
יש טבלה אחת כללית של מודעות
וטבלה אחת של מודעות חדשות פר לקוח וזה בגלל שאני צריך לדעת להבדיל בין המודעות החדשות שהן לאו דווקא חדשות, אלא אלו שהוא לא שמע עדיין גם אם הוא שמע כבר אחרות, זאת אומרת יכול להיות שהוא נכנס ושמע את הדירות של בית שמש, אבל לא את של ירושלים אז אלו של ירושלים עדיין יושמעו בתור חדשות, גם אם הן הוכנסו לפני של בית שמש. וכן אם הוא רק התחיל לשמוע את המודעות של ירושלים אז אלו שהוא עדיין לא שמע יושמעו כחדשות. ככה זה נותן לי לנהל את המודעות בצורה הכי טובה.כמה שהצלחתי לחשוב האופציה הכי טובה היא פשוט לעשות מודעות חדשות פר לקוח. זה על הרעיון של מה שהצעתם לי כאן.
תאריך כניסה אחרונה לא עוזר לי, כי יכול להיות שהוא לא שמע את כל המודעות שהיו עד עכשיו ואם אחשב לפי תאריך שמיעה אחרונה אז הוא יפספס מודעות.
בטבלת הסינונים כבר יש מזהה לקוח - הטלפון.
מהסיבה הנ"ל אני לא יכול לחשב סינון בזמן אמת, כי אני צריך אינדיקציה ברורה מה הוא שמע ומה לא.
מה שהציעו לך באשכול השני זה לא לשכפל את המידע אלא ליצור טבלה של "מה המשתמש קרא כבר" ואז בזמן אמת לעשות בשאילתה בדיקה שהמודעה לא מופיעה בטבלה השניה (כלומר לא נקראה)
זה יכול להיות גם בלי טבלה נפרדת, כעמודה של "מזהי משתמשים שקראו" בטבלת המודעות, אבל אז אתה מאבד את המידע הנוסף כמו כמה פעמים המשתמש נכנס למודעה, מתי, ועוד, שזה מידע שעשוי להיות שימושי
האם להשתמש בזה או בתאריך כניסה אחרונה שהצעתי זה באמת שיקול עסקי
@eido אני מתכוון שגם עם הספריה yemot-router2 אפשר לבודד לוגיקה לפונקציות הניתנות לשימוש חוזר
@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:
אבל בגלל שכל קונטרולר הוא זרימה של ivr אז הקבצים מאוד ארוכים
למה זה סיבה?
@eido הבעיה היא שאתה משכפל נתונים (מודעות) שאמורים להיות שאילתה
שאילתה לא אמורה להיות סיבוך, בשביל זה אתה עובד עם SQL ולא עם קבצים בדיסק
@NH.LOCAL כתב בבירור על מערכת סליקת אשראי מתאימה לאתר עם מודל מנויים:
לא הצלחתי גם להבין את ההבדל בין ספק האשראי לבין מערכת סליקה (ראיתי למשל שישנם מערכות שמשתמשות במערכות אחרות במשולב, כמו נדרים פלוס)
@eido לא נשמע לי הוגן לתת ללקוח אפליקציה שכמו שנשמע עשויה להתפתח עוד בעתיד, שהסכמה שלה בנויה בצורה עקומה, בגלל שאין לך כח לשנות
אני לא מבין למה צריך טבלה סטטית של מודעות שמתאימות לאותו לקוח, תיצור טבלת מודעות וטבלה של התראות שמכילה מזהה משתמש + קריטריונים + תאריך יצירה + תאריך התראה אחרונה/כניסה אחרונה, ואז בפרוסס ששולח את ההתראות אתה שולף לכל אחד את ההתראות החדשות המתאימות לו מטבלת המודעות
אתה צריך להוסיף מזהה לקוח לטבלת הסינונים,
אם אתה מתעקש להמשיך עם המבנה הנוכחי תעשה את הטבלה במקום מודעות לפי מזהה לקוח, מודעות לפי מזהה סינון, אבל רצוי יותר לוותר לגמרי על הטבלה הזו ולחשב את המודעות המתאימות לסינון בזמן אמת
@יעקב2 כתב בסליקת אשראי שיגיע לחשבון בנק שלי:
@ששא יש את החשבון העסקי של ישראכרט בחינם אבל הכל דרך אפליקציה
אפשר קישור?
באתר שלהם יש גם תשלום חודשי וגם עמלה יקרה
https://business.isracard.co.il/OnBoarding/login/
