שמירת נתונים בטבלה א הנמצאים בטבלה ב

[dovid]

@חוקר אמר בשמירת נתונים בטבלה א הנמצאים בטבלה ב:

לבצע שאילתאות ממוזגות יכול ליצור בלגן גדול בשרת כי זה טבלה של מעל 60K מנויים ומעל 4.5G השתתפויות.

לא הבנתי. JOIN פשוט אמור לעשות את העבודה מצויין.

[חוקר]

@dovid אמר בשמירת נתונים בטבלה א הנמצאים בטבלה ב:

לא הבנתי. JOIN פשוט אמור לעשות את העבודה מצויין.

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

[avr416]

@חוקר אמר בשמירת נתונים בטבלה א הנמצאים בטבלה ב:

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

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

select firstName, lastName, migdar
 from Users as u
Where u.migdar = 'male' and u.id in
(select X from activities where date )

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

מקווה שהובנתי, אם לא - תשאל

[avr416]

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

[חוקר]

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

select count(id), city from usersAnswers
GROUP BY city

בשתי טבלאות זה יחייב JOIN

[חוקר]

פוסט זה נמחק!

[avr416]

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

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

אבל שוב, אני לא מכיר את הפריימווורק הזה

[MusiCode]

@avr416 אמר בשמירת נתונים בטבלה א הנמצאים בטבלה ב:

(וכמובן אלף פעמים לשים לב לאבטחה ולניקוי קלט של משתמש!!)

בימות, ובאסטריסק כללי, אין הזרקת SQL...

[חוקר]

@MusiCode אמר בשמירת נתונים בטבלה א הנמצאים בטבלה ב:

בימות, ובאסטריסק כללי, אין הזרקת SQL...

בממשק ללקוחות..

[WWW]

@MusiCode אמר בשמירת נתונים בטבלה א הנמצאים בטבלה ב:

@avr416 אמר בשמירת נתונים בטבלה א הנמצאים בטבלה ב:

(וכמובן אלף פעמים לשים לב לאבטחה ולניקוי קלט של משתמש!!)

בימות, ובאסטריסק כללי, אין הזרקת SQL...

ככה נראה לך?

אם אתה דואג לחסום פיירוול, אתה צודק.