לא נתקלתי בנושא באופן אישי,
נראה לי שאם גודל ה-KEY שלך כל כך גדול אולי כדאי לך בכל מקרה לשקול SURROGATE KEY
נומרי במקום....
אבל זה רק ממבט ראשון, יכול להיות פה עוד גורמים שכנראה לא הבאת לידיעתנו ...
קראתי פעם מאמר על כך שניתן לייצר אינקדסים שחוצים את מגבלות הגודל של SQL SERVER עם משתמשים בפונקציות של SQL SERVER להפוך את השדה לבינארי (יש מגבלה על אינדקסים של עד 900 בייטים או משהו בסגנון בכלל ב SQL SERVER )
אבל גם כשקראתי את זה חשבתי שלסביבת DW יותר פשוט לעבוד עם מפתח נומרי כ- SURROGATE במקום (קריא יותר , קל יותר לתחזוקה , בדיקות וכיוצ"ב .. )
מצאתי את הפיתרון (מוזר אך עבד לי , אין לי הסבר למה זה קרה אך עם עובדה אי אפשר להתווכח)
ה- dataize של member name ב-attribute שגם מוגדר ה- key
היה מוגדר ל- 573 וזה בסדר מבחינתי ככה זה היה עד לפני התקלה ועבד תקופה מסויימת.
למרות שהוא מכיל בפועל אורך תווים מקסימלי של 93 תווים (אורך מחרוזת שבנויה על שירשור כל הרמות בהיררכיה עד לרמה הנמוכה עם "." שמפרידה בין רמה לרמה עד לרמה 5 הכי נמוכה (אל תשאלו אך היה לי צורך )
משום מה כאשר עם הזמן נכנסה מחרוזת כזאת עם יותר תווים כגון 100 תווים בפועל
ביצעתי רענון ל- dsv וזה היה אמור לפתור את הבעיה לפי ניסוחים שונים באתרים המקצועיים
אך זה לא עזר
מה שכן עזר הוא שגדלתי את ה-datasize ב- Attribute ל- 1000 וגם ב- MeasureGroup הרלוונטי ל- 1000 ז"א השוואה בין השניים ואחר כך
להיכנס ל- Dimension Usage ופשוט לבחור שוב את אותו החיבור מחדש בין המימד
לבין ה- measureGroup
והפלא ופלא זה עבד עד היום בלי שום בעיה
אין לי הסבר מקצועי לזה למה זה קורה או קרה
אך זה המצב
באופן אישי הייתי נמנע מלהעלות ערכים בגודל כזה.
אני חושב על המשתמש שמעוניין לבצע ניתוחים עם על מימד שתופס יותר מחצי מסך.
אולי כדי לשקול להכניסו רק ב drill
