האם 9 הספרות של המספר הקצאה, הינם חד חד ערכי

[mekev]

המספר הקצאה של רשות המיסים הינו מחרוזת עד 30 תווים
שבהצגה, ובדיווח השוטף, משדרים את ה9 ספרות האחרונות בלבד

בתיעוד שלהם מופיע מידע למפתחים
להגדיר את השדה של המספר הקצאה כ VARCHAR(30)
כי התכנון שלהם שבעתיד המספר המלא יכיל גם אותיות ותווים

השאלה היא:
האם ה 9 ספרות האחרונות של המספרי הקצאה של רשות המיסים
הינם חד-חד ערכי
או שיכול להיות מספרים כפולים

בכל מקרה חובה לשמור בסוג עמודה VARCHAR(9) כי יש אפסים מובילים
הנקודה היא: האם אני יכול להגדיר אינדקס ייחודי לעמודה

[dovid]

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

[mekev]

@dovid
בפרקטיקה של שנתיים עם מספרי הקצאה

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

בניתי ממשק של אימות ושחזור מספרי הקצאה (צד לקוח, המנכה תשומות)

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

[dovid]

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

אני לא זכרתי שיש המלצה להדפיס רק 9, אדרבא אני זוכר שחובה להדפיס הכל ורק 9 בגדול.

[mekev]

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

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