תחומים - פורום חרדי מקצועי

@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 כתב בבירור על מערכת סליקת אשראי מתאימה לאתר עם מודל מנויים:

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

https://tchumim.com/post/169274

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

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

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

@יעקב2 כתב בסליקת אשראי שיגיע לחשבון בנק שלי:

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

אפשר קישור?
באתר שלהם יש גם תשלום חודשי וגם עמלה יקרה
https://business.isracard.co.il/OnBoarding/login/

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

@ששא כתב בסליקת אשראי שיגיע לחשבון בנק שלי:

מה זה שני החברות? למה צריך את שניהם?

תהליך התשלום מורכב מהגורמים העיקריים:

• לקוח
• סוחר (בעל החנות, מקבל התשלום - Merchant)
• שער תשלום (Payment Gateway) אחראי רק לממשק הסליקה. לפעמים זו אותה חברה שמספק את שירותי התשלום, לדוגמה: upay, טרנזילה, Stripe, ולפעמים נפרד, לדוגמה: sumit
• מעבד תשלום (Payment Processor) לדוגמה: טרנזילה, upay. הוא מתחבר בפועל לסולק, מטפל בהעברת הכסף לסוחר וכו'
• סולק (Acquirer) לדוגמה: כאל, מקס, ישראכרט
• רשת כרטיסים (Card Network) בעסקאות בינ"ל זה בעיקר ויזה ומאסטרכארד העולמיות, יש שחקני נישה כמו אמריקן אקספרס ודינרס. בעסקאות בתוך הארץ זה שב"א.
• מנפיק כרטיס (Issuer) לדוגמה: כאל, מקס, ישראכרט, בנקים. מבוסס על אחת מרשתות הכרטיסים העולמיות, הוא זה שנותן את האשראי בפועל אם זה לא כרטיס חיוב מיידי debit (אשראי במונח המקצועי שלו, כלומר ההלוואה עצמה) והוא זה שמחליט אם לכבד עסקה או לא כי היא חשודה, אין כיסוי

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

@ששא כתב בסליקת אשראי שיגיע לחשבון בנק שלי:

והם יותר טובים מיש חשבונית?

אין לי נסיון עם יש חשבונית, אבל עם sumit כן והם מעולים במוצר ובשירות, וחינם/זולים מאוד למי שאין לו הרבה תנועות כל חודש

@ששא אם אתה משתמש ביש חשבונית למה שלא תשתמש בסליקת אשראי שלהם במקום לנסות לחבר כמה תוכנות?
אגב, נשמע שיספיק לך המסלול החינמי של sumit ואז אתה יכול לסלוק דרכם דרך upay ולשלם רק על הסליקה 1.1% + מע"מ שזה ממש זול ממה שביררתי, ובכללי המחירים שלהם זולים והמוצר מעולה

@תלמידהון יש רשימת חריגים (כולל שעון), לכל אחד מהם יש סיבה

@תלמידהון סתם סרגל התקדמות כן, אם זה מחוון התקדמות של זמן או מדיה המקובל בעולם הוא שלא
מקורות:
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/SupportingRight-To-LeftLanguages/SupportingRight-To-LeftLanguages.html#:~:text=Types of controls and content that should not flip in a right-to-left language are%3A

https://firefox-source-docs.mozilla.org/code-quality/coding-style/rtl_guidelines.html#what-not-to-mirror

https://m3.material.io/foundations/layout/understanding-layout/bidirectionality-rtl

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

@יעקב2 כתב בהצעה לפיתוח | סקריפט איסוף מטבעות בעלי אקספרס:

איפה הטריגר

https://developer.chrome.com/docs/extensions/reference/api/alarms

@מד צודק, ב stackexchange כתוב שזה אפשרי
אבל למה שלא תקנה דומיין? 10 שקל לשנה בשביל פרודקשן

@מד אה, זה לא אפשרי באמת. אבל ברגע שהדומיין מחובר אליהם אפשר להשתמש בתת דומיין