מיספור אוטומטי SqlServer
-
האם יש אפשרות להגדיר ל-ID ספרות לפני הערך
דוגמא:
בטבלה אחת יתחיל המספר סידורי כך: 01/1, 01/2, 01/3 וכו'
ובטבלה שניה כך: 02/1, 02/2, 02/3 וכו'
ה'סלש' -/ לא מעכבכשאתה עושה identity יש גם מאפיין שנקרא sid שם אתה קובע את הערך ההתחלתי, להוסיף אפסים קודם לא נראה לי שאפשר כי הערך הוא int ולא varchar
@דוד ל.ט.
כמו שארכיטקט אמר - תוכל להגדיר את הערך ההתחלתי גדול במיוחד ואז תהיה בטוח בקידומת (בהנחה שגידול השורות לא רציני).
ויכול להיות שהוא פשוט רוצה קידומת כדי שיוכל לעשות טבלת משנה ולהכניס בתוך עמודה אחת את מ2 הטבלאות.
לדוגמא:
נניח שהוא עושה טבלת שליחת מיילים, ויש לו טבלת תורמים וטבלת הורי תלמידים (בלי להיכנס לדיון אם נכון לעשות כך או לא.)
אז במקום לעשות בטבלת שליחת המיילים ID של ההורה/תורם + עמודה של הטבלה, הוא יכול לעשות רק עמודה של ID, ובשביל לזהות תורם הוא יבדוק אם יש קידומת 1, והורה זה קידומת 2 וכו'.
אם זה הכיוון, בSQL SERVER יש אפשרות להוסיף עמודה מחושבת, ואז אתה יכול להוסיף קידומת, ולהשתמש בזה כמפתח ראשי.
הנה הקוד SQL:CREATE TABLE [dbo].[test]( [id] [int] IDENTITY(1,1) NOT NULL, [sid] AS (CONVERT([int],'1'+CONVERT([nvarchar](23),[ID],(0)),0)), [LastName] [nvarchar](50) NULL ) ON [PRIMARY]שים לב שהייתי חייב בדוגמא "להמיר" את המספר לטקסט, כי אחרת הוא יחבר את הID עם הסיפרה 1 (ולא עוזר שזה מתוחם בגרשיים,הוא מספיק חכם להבין שזה מספר ולחבר אותו במקום לשרשר) ולהמיר אותו בחזרה למספר - בשביל שזה לא יעשה התנגשות בסוגי נתונים בקשרי גומלין.
פורסם במקור בפורום CODE613 ב22/05/2014 00:08 (+03:00)
-
ClickOne יפה מאוד שהצלחת לרדת לסוף דעתו, למצוא דוגמה שצריך את זה!
ואיזה יופי הרעיון!!! לקח לי זמן להבין...אבל, הרעיון הזה זה רק לספורט נכון
? כי לכאורה אין לרעיון הזה ייתרון על העצה הפשוטה של ארכיטקט. שים לב שגם הוספת עמודה פר טבלה (הורים ותורמים) ושעמודה מחושבת זה עמודה עם עלות מסויימת מבחינת ביצועים (במיוחד עם סטרינג!).פורסם במקור בפורום CODE613 ב22/05/2014 09:45 (+03:00)
-
יכול להיות שהוא פשוט רוצה קידומת כדי שיוכל לעשות טבלת משנה ולהכניס בתוך עמודה אחת את מ2 הטבלאות.
אני נהנה לשמוע שלומדים את כוונותי
אם כבר, לדוגמה בעסק שמנפיק חשבוניות וכמובן הם חייבים להיות לפי סדר רץ
כאשר רוצים להתחיל מיספור מחדש או אפילו בו זמנית להשתמש בשני מיספורים שונים אז עושים סדרות בצורה כזו (כך עד כמה שידוע לי)
סדרה אחת: 01/1, 01/2, 01/3 וכו',
סדרה 2: 02/1, 02/2, 02/3 וכו',
דרך אגב: נראה לי שהסלש הוא רק עניין תצוגתי להפריד כל פעם את שני הספרות הראשונות, אני צודק?פורסם במקור בפורום CODE613 ב22/05/2014 11:02 (+03:00)
-
אם גידול הרשימות משמעותי הפיתרון של ארכיטקט לא ישים. (גם אם המספר ההתחלתי הוא מליון והוא כותב מערכת גדולה הוא כבר נכנס לסיכון [במיוחד אם הטבלה הראשית שעליה הוא מדבר היא לא של אנשי קשר (שאין הרבה) אלא של מיילים לדוגמא - הוא לא יכול להגביל את עצמו למליון])
ובאמת לא הוספתי עמודה פר טבלה (יכול להיות שזה הפיתרון היותר נכון בדוגמא הספציפית הזו [או עמודה נוספת שרק תספר לנו מאיזו טבלה נלקח המפתח הזר]) כמו שכתבת, אלא הרעיון הוא שמספר זר 11 זה ID 1 בטבלת תרמים ומספר זר 21 זה ID 1 בטבלת הורים וכו'.
עמודה מחושבת זה אכן עלות מבחינת ביצועים, וגם עמודה נוספת שמכילה את מקור הטבלה של המפתח הזר היא כלות ביצועים.
באופן אישי בגלל הסיבה הזו אני לא אוהב שדברים כאלו נמצאים כעמודה מחושבת בטבלה אלא בVIEW שמיועד לאותו מקרה ספציפי בלבד.לגבי הביזבוז עם סטרינג, אני רק רוצה להזכיר שסטרינג בהחלט יכול לשמש כמפתח ראשי על אף הבזבזנות שלו (ועל אף הרצון של כולנו להשתמש דווקא במספר אוטו') - לדוגמא: GUID, שממומש במקרים רבים כסטרינג + מפתח ראשי ולא כסוג uniqueidentifier.
פורסם במקור בפורום CODE613 ב22/05/2014 11:13 (+03:00)
-
אם גידול הרשימות משמעותי הפיתרון של ארכיטקט לא ישים. (גם אם המספר ההתחלתי הוא מליון והוא כותב מערכת גדולה הוא כבר נכנס לסיכון [במיוחד אם הטבלה הראשית שעליה הוא מדבר היא לא של אנשי קשר (שאין הרבה) אלא של מיילים לדוגמא - הוא לא יכול להגביל את עצמו למליון])
תראה, גידול רשומות הוא סיכון בכל טבלה עם מאפיין int ייחודי, רק שכאן הוא מגיע יותר מהר. הסיכון נמצא במידה שווה גם בדוגמתך, כל עוד הקונוורט שלך הוא לint. זה נכון שאפשר לעשות אותו לסטרינג כמו שכתבת:
לגבי הביזבוז עם סטרינג, אני רק רוצה להזכיר שסטרינג בהחלט יכול לשמש כמפתח ראשי על אף הבזבזנות שלו (ועל אף הרצון של כולנו להשתמש דווקא במספר אוטו') - לדוגמא: GUID, שממומש במקרים רבים כסטרינג + מפתח ראשי ולא כסוג uniqueidentifier.
אני התכוונתי על בזבוז מעבד וזיכרון ברגע החישוב, לא על זיכרון דיסק באחסון (זה בכלל עמודה מחושבת!!).
לגבי מקום בדיסק או ביצועי השוואה (כאינדקס, וכמפתח ראשי) אין הבדל כלל בין סטרינג למספר, בתנאי שהסטרינג אורך קבוע (לא varchar), ושההשוואה היא מול מספר של קנה מידה שווה (עם זה char(10) לדוגמה, אז כל char זה byte שלם, מה שאומר מספר ענק.
אגב אפשר להשתמש למקרה שלנו גם בטיפוס binary, לכאורה זה חוסך.פורסם במקור בפורום CODE613 ב22/05/2014 11:50 (+03:00)
-
@דוד ל.ט.
@ClickOne
אם גידול הרשימות משמעותי הפיתרון של ארכיטקט לא ישים. (גם אם המספר ההתחלתי הוא מליון והוא כותב מערכת גדולה הוא כבר נכנס לסיכון [במיוחד אם הטבלה הראשית שעליה הוא מדבר היא לא של אנשי קשר (שאין הרבה) אלא של מיילים לדוגמא - הוא לא יכול להגביל את עצמו למליון])תראה, גידול רשומות הוא סיכון בכל טבלה עם מאפיין int ייחודי, רק שכאן הוא מגיע יותר מהר. הסיכון נמצא במידה שווה גם בדוגמתך, כל עוד הקונוורט שלך הוא לint. זה נכון שאפשר לעשות אותו לסטרינג כמו שכתבת:
הסיכון לא נמצא גם אצלי, כי אצלי תמיד המספר יתחיל ב1 - אפילו כשזה יגיע למיליארד. (אתה מדבר כנראה על הגבול שINT יכול להגיע, ואני מדבר על זה שאפילו BIG יכול להוות בעייה אם נעשה התחלה ממליון)
@דוד ל.ט.@ClickOne
לגבי הביזבוז עם סטרינג, אני רק רוצה להזכיר שסטרינג בהחלט יכול לשמש כמפתח ראשי על אף הבזבזנות שלו (ועל אף הרצון של כולנו להשתמש דווקא במספר אוטו') - לדוגמא: GUID, שממומש במקרים רבים כסטרינג + מפתח ראשי ולא כסוג uniqueidentifier.אני התכוונתי על בזבוז מעבד וזיכרון ברגע החישוב, לא על זיכרון דיסק באחסון (זה בכלל עמודה מחושבת!!).
לגבי מקום בדיסק או ביצועי השוואה (כאינדקס, וכמפתח ראשי) אין הבדל כלל בין סטרינג למספר, בתנאי שהסטרינג אורך קבוע (לא varchar), ושההשוואה היא מול מספר של קנה מידה שווה (עם זה char(10) לדוגמה, אז כל char זה byte שלם, מה שאומר מספר ענק.
אגב אפשר להשתמש למקרה שלנו גם בטיפוס binary, לכאורה זה חוסך.גם אני התכוונתי לבזבוז ביצועים ולא מקום (בגלל שזה עמודה מחושבת), למרות שיכול להיות שהפיתרון אמיתי כאן זה עוד עמודה(לא מחושבת) שתתחיל ב1. צריך פעם אחת לבדוק במקרה כזה האם ההשפעה שלחישוב מול מקום מה עדיף. - וכמובן, תמיד אפשר לתכנן את הDB שונה.
@ClickOne
יכול להיות שהוא פשוט רוצה קידומת כדי שיוכל לעשות טבלת משנה ולהכניס בתוך עמודה אחת את מ2 הטבלאות.אני נהנה לשמוע שלומדים את כוונותי
אם כבר, לדוגמה בעסק שמנפיק חשבוניות וכמובן הם חייבים להיות לפי סדר רץ
כאשר רוצים להתחיל מיספור מחדש או אפילו בו זמנית להשתמש בשני מיספורים שונים אז עושים סדרות בצורה כזו (כך עד כמה שידוע לי)
סדרה אחת: 01/1, 01/2, 01/3 וכו',
סדרה 2: 02/1, 02/2, 02/3 וכו',
דרך אגב: נראה לי שהסלש הוא רק עניין תצוגתי להפריד כל פעם את שני הספרות הראשונות, אני צודק?לענ"ד הסלש באמת רק תצוגתי, ולפי הוראות מס הכנסה אין חיוב לעשות סדרות - זה בא לידי ביטוי בד"כ רק בחברות ענק כמו חברת החשמל שלא רוצים להגיע למספרי חשבוניות דמיוניים. אני מניח שמס' הסידרה נמצא בשדה אחר (בחברת החשמל לדוגמא מס' הסידרה זה השנה - עכשיו זה 2014)
פורסם במקור בפורום CODE613 ב22/05/2014 12:36 (+03:00)
-
@דוד ל.ט.
ושעמודה מחושבת זה עמודה עם עלות מסויימת מבחינת ביצועים (במיוחד עם סטרינג!).
עמודה מחושבת זה אכן עלות מבחינת ביצועים, וגם עמודה נוספת שמכילה את מקור הטבלה של המפתח הזר היא כלות ביצועים.
אין עלות ביצועים של שליפה כאשר משתמשים במאפיין is persisted. לפי מה שאני מבין אין לו שינויים תכופים במספרים, אלא רק פעם אחת בעת היצירה, אז אם הוא מצליח לממש את is persisted (זה לפעמים קצת קשה אם זה פונקציה מותאמת אישית הוא צריך לעשות לה WITH SCHEMABINDING ולא תמיד זה אפשרי)
פורסם במקור בפורום CODE613 ב22/05/2014 13:32 (+03:00)
