תכנון טבלאות לפרוייקט

[eido]

יש לי פרוייקט שצריך בו:
מודעות של מפרסמים
מודעות של ביקוש
דירוג של מספר טלפון (אם המספר אמין/טוב או לא)
האם צריך לצנתק למספר מסוים או לא

בכל מודעה יכולים להיות ערים או איזורים

כמובן, סימון של מודעות שנקראו.

אני עשיתי את הטבלאות הבאות:

ads - תשמש גם למפרסם וגם לביקוש ההבדל הוא בעמודה type שמבדילה בין מודעה של מפרסם למודעה של מחפש
ad_cities - שמכילה id של מודעה ועיר או איזור שקשורים אליה.
read_ads - שמכילה id של מודעה ומספר טלפון שקרא אותה.
אצטרך עוד טבלה של מספרי טלפון שצריך לצנתק אליהם.
עוד טבלה של דירוג

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

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

[dovid]

@eido כתב בתכנון טבלאות לפרוייקט:

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

אתה לא יודע, כלומר אתה טועה.

[eido]

@dovid לא מקובל לעשות כזו טבלה? כך טענו כאן בפורום או במתמחים.טופ.

[dovid]

אז טענו.
לגופה של שאלה, אני חושב שהטבלאות נכונות,
לא הבנתי מה זה:

• "דירוג של מספר טלפון" (באיזה צורה המידע מתנהל ופר מה)
• "עוד טבלה של מספר טלפון"

[eido]

@dovid כתב בתכנון טבלאות לפרוייקט:

אז טענו.
אני חושב שהטבלאות נכונות,

לא הבנתי מה זה:

• "דירוג של מספר טלפון" (באיזה צורה המידע מתנהל ופר מה)

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

• "עוד טבלה של מספר טלפון"

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

[dovid]

@eido כתב בתכנון טבלאות לפרוייקט:

מאזין מחייג ומדרג את המספר הנ"ל (יותר נכון את האדם שמאחוריו) מ1 עד 5

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

[eido]

@dovid נכון, לי הכל ברור לכן לא שמתי לב שחסרים פרטים.

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

המפרסם הוא מאזין שמפרסם מודעה.
המחפש הוא מאזין שמחפש מודעה.

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

הדירוג צריך להיות אנונימי, אחרת לא ידרגו.

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

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

[dovid]

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

[צבי-ש]

@eido כתב בתכנון טבלאות לפרוייקט:

הדירוג צריך להיות אנונימי, אחרת לא ידרגו.

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

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

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

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

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

או במקרה שלנו, אם תכניס לפונקציה 0521234567 אתה תקבל למשל אבגדהו,
תשמור בdb ״אבגדהו״ דירג 5 את מספר פלאפון xyz,
אבל אתה לעולם לא תוכל לחזור אחורה מ אבגדהו אל 0521234567,
כשתרצה לבדוק האם הוא כבר דירג, ומה הדירוג שלו, תוכל להכניס שוב את 0521234567 אל הפונקציה, לקבל שוב את אבגדהו ועליו לבדוק בdb את הנתונים )

[dovid]

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

 INSERT INTO Rating (UserPhoneHash, TargetPhone, Value) 
 VALUES (SHA1('0527123456'), '0504123456', 5) AS new
 ON DUPLICATE KEY UPDATE Value = new.Value;

בצורה הזו כל משתמש יוכל לדרג רק פעם אחת כל משתמש אחר, דירוג מחדש מעדכן את הקודם.
העמודה UserPhoneHash צריכה להיות CHAR(40) והמפתח הראשי של הטבלה Rating צריך להיות מבוסס UserPhoneHash+TargetPhone.

[eido]

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

[eido]

לgpt יש שידרוג קטן, מה אומרים?
https://chatgpt.com/share/699da101-44e0-8000-9220-1d4fff950be1

[dovid]

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

[eido]

@dovid הנה, מצאנו משהו שאתה מסכים איתי

[dovid]

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

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

[צבי-ש]

@dovid כתב בתכנון טבלאות לפרוייקט:

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

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

[dovid]

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

[dovid]

שאלתי כעת את קלוד, הוא מעיר לי שSHA1 נחשב גרוע במיוחד לזה.
לכן GPT אמר שעדיף לגבב בצד האפלקיציה.
לדברי קלוד, גיבוב באפליקציה עם Argon2 מאפשר קצב ניסוי של 500 לשניה, במחשב עם כרטיס מסך ביתי ממוצע.
אם יהיה 1,000 מפרסמים ו20 אלף מאזינים שזה ריאלי, זה 11 שעות לפי מה שאני מחשב כעת לסריקה כוללת, ממוצע לאיתור חצי מזה שזה 5.6 שעות. כל זה בשביל לדעת מי עשה דיסלייק, בעצם שווה את זה...

[eido]

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

[eido]

@dovid כתב בתכנון טבלאות לפרוייקט:

ואפילו מליון מאזינים

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

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