לקבלת עדכון מימד / למעשה חייב לקבוע אם שיא קיים. זה נעשה בדרך כלל על ידי הסתכלות עסקית המפתח (המפתח הטבעי) בממד. אם לא נמצא, זה שיא חדש וזה צריך להיות לך להוסיף. אם זה נמצא וזה השתנה צריך להיות מעודכן כדי להקליט (סוג 1) או שיא חדש צריך להיות נוצר (סוג 2). אני מה expirementeren כבר בתהליך של ביצוע בדיקת להאיץ. הנה הממצאים שלי עד כה.
האם בדיקה על הערך שלם יותר מהר varchar. כל המפתחות העסק אני לדון במחסן הנתונים שלי כמו שדות varchar, לעיתים קרובות שילוב של שני התחומים. זה כדי למנוע טעויות בעתיד אם כך נקודת ההחלטה להוסיף מוצר: תצוגה מקדימה:
- DimElement: קוד החברה יסוד + קוד
- DimUitvoerCode: קוד החברה + קוד הפעלה
אנחנו יכולים לבחור מפתח המקור במימד קשורים ישירות ו כשדה לחנות, למשל, 100_101 (קוד החברה, קוד הרכיב). אנחנו לא יכולים לעשות חיפוש ולקרוא על שני שדות. ההעדפה שלי היא לאסוף את שני השדות, ואחריו תחתון כך את המפתח ניתן לעקוב אחר מהמקור.
אפשרות נוספת היא בדיקת / חשיש ליצור שני שדות מעל. היתרון הוא בכך בדיקה נעשה על שדה אחד בלבד ועל שמות של משאב זה המפתח הוא גנרי. כל המשאבים שאנו מכנים למשל המפתח של תמיד מקור Hash הוא סוג אורך זהה.
T-SQL בדיקת תפקוד SSIS U. S. חיל הים
בדיקת הוא שדה שלם 4 בתים ולכן לא יכולה להיות בדיקה מהירה לעשות. בדיקת הוא לא טוב יש כמה עמודות ליצור מאז בדיקת כפילויות עלולה להתרחש (מוכח). הפקת בדיקת על businesskey אינה אמינה.
אם אני יוצר CRC32 על שלושת העמודים בצורת מפתח העסק אני מקבל הרבה בדיקות סיכום כפילויות (כגון טבלה מתוכנית חשבונאות).
לבחור, COUNT (*) כמספר
FROM
(SELECT BINARY_CHECKSUM (cmpcode, doccode, DocNum) כמו
FROM dbo.oas_dochead_REG כמו ד"ה
) כמו X
GROUP BY
HAVING COUNT (*)> 1
SSIS רכיבי
http://www.sqlis.com/post/Checksum-Transformation.aspx
בדיקת SSIS רכיב מהקהילה תומך סוגים שונים של בדיקות סיכום.
CRC32
האחת היא CRC32. אני צריך לבדוק את זה רק יוצר כפילויות, ולכן הוא לא אמין. זה מתרחש גם בדורו של בדיקת מעל עמודה לעמודות מרובות.
Frameworkchecksum
הטכניקה frameworkchecksum יוצר כפילויות. בדקתי את זה עם 200,000 רשומות היו שני העתקים שנוצר.
מקורי
ההודעה האחרונה יהיה גם מבחן עבור שמונה בדיקות סיכום כפולות, והוא לא מתאים.
מסקנה
פונקציה MD5 שירים מן כמובן T-SQL הייתי משתמש, הוא רק כ 50% יותר לאט בגלל זה הוא שדה varchar. בדיקת הוא שדה שלם. במקרה הזה אני יכול גם לעשות בדיקה על המקור המפתח, הוא אפילו קטן יותר.
עדכון:
במחסן שלנו אנו משתמשים בינארי (20) בתחום כמו מימדים LookupHash. היתרון הוא שיש שם גנרי נוצר מפתח המקור. בדיקת מידע כדי לקבל surrogatkey לאכלוס העובדה שאתה יכול עכשיו לעשות על LookupHash השדה. יתרון נוסף הוא כי לאינדקס שדה בינארי הוא טוב.
בקיצור: בעת יצירת מימד שלך תמיד יהיה ליצור עמודה LookupHash של בינארית סוג (20). הבא לעשות את JOIN המפתח מכך גם להמיר את הבינארי זהה (20) על אותן עמודות, התוצאה היא זהה בממד. אז אתה יכול להשיג במהירות surrogatkey!
תגיות 
