האם המפתחות שלכם יעילים ?

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

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

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

Firebird SQL מספק לנו יכולת של הבנת יעילות של מפתח על ידי יצירת סטטיסטיקה על כל מפתח שנוצר במסד הנתונים (הוא לא מסד הנתונים היחיד שעושה את זה, גם PostgreSQL ו MS-SQL עושים את זה עד כמה שאני יודע). כל מפתח מקבל שם ייחודי שאפשר למצוא אותו בטבלה בשם RDB$INDICES.

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

SET STATISTICS INDEX index_name;

כלומר ללכת לאינדקס שאנחנו רוצים (לפי השם ב RDB$INDICES ולא השם של השדה בטבלה) ולהגיד לו לאסוף מחדש את הסטטיסטיקה עליו.

ואם רוצים לעשות את זה עבור כל המפתחות בפעם אחת, אפשר פשוט ליצור בלוק ריצה כזה (או כ stored procedure):

set term !! ;

EXECUTE BLOCK AS
declare variable index_name VARCHAR(31);
BEGIN
for select RDB$INDEX_NAME from RDB$INDICES into :index_name do
  execute statement 'SET statistics INDEX ' || :index_name || ';';
END!!

set term ; !!

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

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

select 1.0/count(distinct(field)) from table;

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

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s