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

[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 כתב בתכנון טבלאות לפרוייקט:

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

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

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

[dovid]

@eido, זה היה פילוסופיה.
הפתרון הראשון הוא מצויין,
רק את הגיבוב תעביר לאפליקציה ושיהיה משהו כמו Argon2.

[dovid]

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

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

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