גישת ה-Getting Real של 37Signals טוענת (ולטעמי בצדק) שקודם כל כדאי שיהיו משתמשים, ורק אחר כך אפשר יהיה לדאוג לביצועים. זה לא שזה לא נכון, ואכן אין סיכוי לדעת בתחילת הפיתוח איפה יהיו צווארי הבקבוק בעתיד. אבל מכאן, ועד פיתוח לקוי הדרך ארוכה מאוד. לכן, הגישה שלי היא תמיד לתכנן ולחשוב קדימה, לתכנן הכי פשוט שאפשר, אבל (וזה לא אבל קטן), אם יש אופציה אשר עדיפה בביצועים, תמיד לבחור בה. גם אם זה לוקח עוד 20% זמן.
בכל מקרה, זו היתה ההקדמה לפוסט:
החלק שתמיד הפריע לי ב-ORM, כגון ActicveRecord, הוא חוסר השליטה המליאה על השאילתות שיוצאות, ולכן, לעיתים על מנת להגיע לביצועים טובים יותר, יהיה עדיף להשתמש ב-find_by_sql
לאחרונה, למדתי על פונקציה מגניבה של ActiveRecord, שנקראת Eager Loading Association. אני חושב שהלינק מסביר הכל אבל בגדול, אם אני כותב את השורה הזו:
בכל מקרה, זו היתה ההקדמה לפוסט:
החלק שתמיד הפריע לי ב-ORM, כגון ActicveRecord, הוא חוסר השליטה המליאה על השאילתות שיוצאות, ולכן, לעיתים על מנת להגיע לביצועים טובים יותר, יהיה עדיף להשתמש ב-find_by_sql
לאחרונה, למדתי על פונקציה מגניבה של ActiveRecord, שנקראת Eager Loading Association. אני חושב שהלינק מסביר הכל אבל בגדול, אם אני כותב את השורה הזו:
clients = Client.all(:include => :address, :limit => 10)
אז ריילס "חכם מספיק" להביא לי את עשרת Clients עם ה-Adress שלהם בשתי שאילתות בלבד, וכל זאת למרות שיש קשר של Association בין טבלת clients לטבלת adressees. קרי, שתי טבלאות נפרדות, שתי שאילתות ומקבלים את כל המידע הרלוונטי - חגיגה!
0 comments:
הוסף רשומת תגובה