inner join on varchar VS bigint

[AvidaEinav]

inner join on varchar VS bigint

שלום לכולם,
יש לי טבלה עם שדה מסויים שמוגדר כרגע בתור (10)VARCHAR השדה מכיל מספר טלפון באורך 10 ספרות.
אין לי אפשרות להגדיר מפתח מסוג IDENTITY ולעבוד איתו בשביל JOIN'ים עתידיים מכיוון שיכולים להיות שינויים על שאר השדות של אותו המספר אשר צריכים להשמר:
nomber |fromDate | toDate | status
5 | 1/1/2011 | 1/1/2010 | 1234567890
9 | 1/1/2012 | 1/1/2011 | 1234567890
7 | | 1/1/2012 | 1234567890
8 | 1/1/2010 | 1/1/2000 | 9987654321
1 | | 1/1/2010 | 9987654321

בהנחה שהמספרים לא מתחילים ב '0' וישנם פעולות JOIN עם טבלאות אחרות על שדה number האם נכון יותר מבחינת ביצועים לשנות לו את הסוג ל bigint או שבגדלים האלה אפשר להשאיר על varchar?
אני עובד על MS-SQL 2008

תודה מראש... וחודש טוב לכולם!

 

[pitoach]

ההבדל בין מספר לבין שרשרת טקס גדול מאוד

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

 

[גרי רשף]

לדעתי זה לא כל כך משנה

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

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

 

[AvidaEinav]

אין אגרגציה יש רק JOIN..

תודה לשניכם שעניתם...

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

האם יהיה נזק משמעותי בביצועים?

 

[pitoach]

אם אתה מדבר על שרשרת באורך קבוע בערך ז"א

נניח אתה מגדיר שדה char(10) אז ההבדל במסדי נתונים קטנים לא יורגש כמעט אולי. אני מניח שאתה לא עובד עם מסד נתונים גדול.

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

** במקרה כזה (אורך קבוע או מאוד קרוב לקבוע למשל תמיד 9 או 10 תווים) בשום אופן אל תעשה שימוש בטור מסוג varchar אלא char מפני ש varchar יעלה לך בעוד 20% מקום במקרה של שרשרת באורך 10 ואם האורך כמעט תמיד 10 אז עדיף כבר לתפוס את כל ה 10 (זה תלוי באפיון אבל זה כלל אצבע דיי חשוב). זה גם ימטב את שמירת הזכרון להפעלת השאילתות לאחר בניית תוכנית ההרצה טורי VAR נשמר להם מקום רק חצי מהגודל המקסימלי שלהם... אם לא הבנת את המשפט האחרון נאז עזוב... זה מעט OFF כרגע

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

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

 

[AvidaEinav]

בעיתיות עם CHAR

תוך כדי חיפוש התשובה "בשדות זרים" ראיתי שיש אנשים שכתבו ששימוש
בשדה (10)CHAR אשר לא מולא ב 10 תווים יגרור הכנסת רווחים אוטומטית מה שאומר שלשם השוואה תמיד תיצטרך לשים ()RTRIM - מה שלא בא בחשבון מבחינת ביצועים!!!

'declare @a char(10) = 'hh
(select DATALENGTH(@a

'declare @c char(10) = 'hh
((select DATALENGTH(rtrim(@c

'declare @b varchar(10) = 'hh
(select DATALENGTH(@b

אז במה (10)CHAR עדיף על (10)VARCHAR?

תודה

 

[pitoach]

20% יותר

VAR הם טורים בעלי גודל לא קבוע. מה שאתה קובע זה הגודל המקסימלי ולא הגודל המדוייק. אז כיצד השרת יודע מה הגודל המדוייק? בכל רשומה נשמרים 2 תווים נוספים שבהם נרשם הגודל של השרשרת
לכן אם יש לך שרשרת של 10 תווים ואתה עובד עם CHAR נשמר לך מקום בדיוק עבור 10 תווים, אבל אם אתה עובד עם VAR אז בעצם נשמרים לך 12 תווים וזה 20% יותר: 20% יותר זכרון בכל פעולה, 20% יותר מקום בדיסק וכו'

* לא במקרה יש כמה סוגים שונים של טורים ולכל טור יש את התפקיד שלו והשימוש שלו וכמובן הייתרונות מצד אחד והחסרונות מצד שני. לפי האפיון צריך לבחור. כמו שאמרתי אם יש לך שרשרת של 9-10 תווים אז VAR בכל מקרה יקח 11-12 תווים שזה תמיד יותר מ 10 אז למה לא לעשות שמוש ב CHAR של 10 בדיוק ? ההחלטה שלך ורק אתה מכיר את האפיון והנוחיות שלך

 

[pitoach]

דרך אגב אני לא יודע מי סיפר לך את העניין הזה

ומי נתן לך את הבדיקה המטעה הזו

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

למה לא בדקת פשוט בשאילתה ומגיע למסקנה שלך?
אולי השאילתה בקובץ יעזור לך להבין

 

[AvidaEinav]

פילפול

כאשר אתה משתמש בפונק' LEN היא עושה TRIM לפני התוצאה ואתה מקבל רק את האורך של המחרוזת ולא כמה היא תופסת!
לעומת זאת DATALENGTH מחזירה לך את המקום שהמחרוזת תופסת.
http://blogs.lessthandot.com/index....ming/the-differences-between-len-and-dataleng

כאשר אתה עושה השוואות על שדה CHAR מאחורי הקלעים נעשה TRIM לשם ההשוואה ובכך אתה מוסיף עוד פעולה..

 

[pitoach]

עתה נשאר לך לכן רק לבדוק כמו שאמרתי מה מתאים

לך