auto increament (Oracle)

[nahsh]

auto increament (Oracle)

הי. יש לי DB ובו כמה טבלאות שאחת מהן היא "ראשית", כלומר שלכל שורה בטבלה הזו, משוייכות שורות אחרות בטבלאות אחרות. אני אתן דוגמא: נניח שיש טבלה A שבה ישויות מסוג a. בטבלה B מוחזקות ישויות מסוג b כך שכל אחת מהן משוייכת לa ספציפי (one to many). הID של כל b הוא הID של הa אליו הוא משוייך - בתוספת מספר רץ, נגיד: 0_1 1_1 2_1 0_2 1_2 2_2 0_3456 1_3456 וכו'. את הID הזה אני בונה מתוך האפליקציה, ע"י פירוק הID האחרון של b ששייך לאותו a, והוספת 1. יש דרישה חדשה שלפיה אני צריך שהIDs האלו לא יחזרו על עצמם. אבל בממימוש הנוכחי, אם מוחקים את הb האחרון, הID שלו יווצר שוב בפעם הבאה. זה לא טוב. אני יכול אולי להשתמש בsequence כך שכל ID של b יהיה שונה לגמרי - זה סיוט מבחינת QC (כי הטסטים לא יהיו קונסיסטנטיים ולא צפויים) ואני ממש מעדיף לא להכנס לזה. אשמח לכל רעיון (ולא, אי אפשר לשנות את המבנה/דרישות). תודה.

 

[pitoach]

תשתמש ב בsequence עבור טבלה A

בטבלה A תעבוד עם בsequence על מנת לקבל ID ייחודי בטבלה B אתה בונה את ה ID כמו עד עכשיו כחישוב על ה ID של A + חלק נוסף בצורה זו גם A ייחודי וגם B יחודי (נגזר מ A) והעיקר שהניהול מבוצע בקלות כמו עכשיו * בערך מתאים גם לבניית פורום לא רקורסיבי

אבל זה דיון אחר

 

[nahsh]

ידעתי שיהיה לי קשה להסביר את עצמי...

אין לי בעיית יחודיות כרגע. הבעיה היא מול מערכות אחרות שמתממשקות לשלי. אם אני מוחק איבר מB שהוא בעל תת ID הכי גבוה, אז בפעם הבאה שיווצר איבר מסוג B עבור אותו a, הוא יקבל את אותו ID. דוגמא: יש לי a שיש לו מזהה 123 יש לו שלושה bים: 0_123 1_123 2_123 אם נמחק ה b האחרון, יהיו לa הזה רק שני b: 0_123 1_123 בb הבא שייוצר, האפליקציה תפרק את הID של האחרון, תקבל 1, ולכן הID החדש יהיה שוב 2_123. אני צריך דרך בעצם לשמור עבור כל a, את התת-מזהה האחרון שלו. היה נח אם הייתי יכול לשמור בטבלה A עמודה עם מספרים עולים (auto-increament) לכל שורה בנפרד. אין מנגנון כזה באורקל (אני חושב שבmySQL יש, אם אני לא טועה). צריך לבנות כזה לבד, או לחשוב על פתרון שונה לגמרי.

 

[pitoach]

ננסה שוב

אם יש לך נתון ב A שהמזהה שלו זה 123 ויש לך רשומות מקושרות אליו ב B שהחיבור שלהם הוא המקור של המספר X בכיתוב 123_X אז אכן sequence יבטיח שלא תהיה לך חזרה על נתון שכבר היה. אל תחשוב על sequence לפי טבלה מסויימת אלא על sequence כאוביקט נפרד שפשוט מבצע מיספור ועולה כל פעם ב 1 (ואם יש צורך תמיד אפשר להגדיר אובייקט כזה נפרד ואפילו במסדי נתונים כמו אקסס שאין sequence אפשר לבנות כזה על ידי טבלה נפרדת שבה יש IDENTITY ושומרת את הערכים של sequence הוירטואלי שלנו) אז גם אם מחקת את 123_2 ונשארת עם 0_123 1_123 ה sequence לא מתאפס והוא כבר הגיע למיספר 2 ולכן האיבר הבא שלו יהיה 3 ותקבל 123_3 אם הבעיה שלך זה שהאפליקציה קובעת את הגודל של ה X בפורמט שלנו 123_X אז אתה לא עובד טוב עם ה רעיון של sequence שנועד להיות ברמת מסד הנתונים והוא נשמר במסד הנתונים. האפליקציה יכולה לדעת מה המזפר הבא על ידיד פנייה ל sequence למשל ** דרך אגב נראה לי שכל האפיון של המסד נתונים (ה DDL) והאפליקציה יכול לעבור חשיבה נוספת. אני לא יודע מה הסיבות והמטרות מהן הגעת למצב שאתה מבקש כאן ויכול להיות שבכלל הדרך לפתרון נכון יהיה שינוי של האפיון. כמובן שאין לנו נתונים על כל האפיון שלך ואני רק מגיב לשאלה ספציפית ביותר

. *** כך למשל הנתון 123_X אמור להתקבל פשוט מחיבור JOIN פשוט של הנתון בטבלה A עם הנתון בטבלה D עם סימון הפרדה _ אני לא בטוח שכל הטור הזה לא מיותר והייתי ממלית לך לחשוב על אפיון האפליקציה שוב אולי **** באופן דומה אם האפליקציה בונה וקובעת את הנתון 123_ אז היכן עשית שימוש ב sequence ועוד נקודות שאולי צריך להבהיר אם היית מצרף DDL+DML אז מי שיש לו אורקל אולי היה יכול לעזור יותר

 

[nahsh]

הבעיה עם sequence שהוא, כמו שכתבת, גלובלי

ואז אני אקבל את מה שאני רוצה (וזה אולי הפתרון שיבחר), אבל לא ניתן יהיה לחזות את המזהה של כל b מראש. הבעיה מחמירה בהרצות חוזרות של טסטים על אותו בסיס נתונים - שוב תוצאות לא צפויות: נגיד שיש לי שלושה aים, 123, 456, 789 בשיטה הזו, אם נוסיף b לa הראשון, המזהה שלו יהיה 0_123. נוסיף לו עוד אחד, והמזהה שלו יהיה 1_123. עכשיו נוסיף b לa השני, ונקבל 2_456 וכו'. ולצערי אני לא יכול להוסיף פרטים ממש - זו אפליקציה מיסחרית...

 

[pitoach]

הדוגמה שאתה מביא לגבי מה יקבל ה B של האיבר A

הבא בדיוק מהווה חלק מהעניין של אפיון שנראה לי שעל פני השטח בכלל אינו מתאים. אכן אתה צודק ובאפיון הנוכחי שלך האיבר הבא יהיה 2_456

אני דיי בטוח שלא הייתי בכלל מגיע למצב שאתה מתאר ולא הייתי בוחר להגיע למשל למצב בו אני עובד עם רשומה מפורמטת כ A_B כש A מגיע מטבלה אחת ו B מטבלה אחרת. אחרת הכל מספיק לי להחזיק את Bבטבלה של b כנתון ייחודי ובטור אחר להחזיק את המפתח הייחודי של A * אפליקציה מיסחרית צריכה להיות מאופיינת הרבה יותר לעומק ובפירוט מאפליקציה בפיתוח עצמי לימוד בדרך כלל. ויכול להיות שמומלץ לך להעזר בייעו חיצוני לאפיון האפליקציה לפני שאתה משקיע זמן על הפיתוח שלה. במקרה זה תכין מראש את כל הבעיות שעלו לך באפיון שלך וכבר ימצאו לך פתרון יעיל ככל הנראה. כאן אנחנו יכולים רק לזרוק נקודות כלליות בלי לראות את האפיון ** ייעוץ חיצוני היא לא מילה גסה בפיתוח

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

 

[jonjac]

אי אפשר לקבל הכול

מצד אחד, אתה לא רוצה שמספרים יחזרו על עצמם. מצד שני, אתה לא רוצה חורים ברצף. אז תחליט במה אתה בוחר. לדעתי ההימנעות מחורים ברצף יוצרת מצבים בלתי-אפשריים ממש מבחינת עיצוב המערכת, הרבה יותר מפגיעה ב"טעם הטוב" של מנתח מערכות כזה או אחר שלא אוהב חורים במספר הרץ. ולגבי המפתח המחריד על טבלה B, תעשה לעצמך טובה ואל תגרום לכל מי שבא לתחזק את המערכת לקלל את זה שלא שמע על מפתח רב-עמודתי. תפריד את השדה לשני שדות - האחד מצביע על A והשני מכיל מספור שמגיע מSEQUENCE אחר. כל מה שנותר הוא לבלוע את הצפרדע של "אוי ואבוי יש חורים ברצף!"

 

[nahsh]

וואו! איזו התקפה!!

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

 

[jonjac]

התקפת סייבר

אתה צריך להבין שאיפיון שדורש: א. אין חורים ברצף ב. מספר שנמחק לא ייכנס שוב ג. כל בדיקת QC תיראה זהה לקודמתה זהו איפיון שטומן בחובו פרדוקס אחד אם לא יותר. אני צריך להסביר מדוע? העובדה שאתה לא איפיינת את זה לא מסירה ממך את האחריות להגיד ללקוח: "אי אפשר" מקריאה חוזרת של התגובות שלך, עולות מספר הערות: א. אתה צריך לעמוד על עקרונותיך המקצועיים מול צוות הQC שעושה רושם שהוא קצת מתעצל להתמודד עם מערכות שיוצרות פלט לא עקבי (כמה נוח היה לעשות QC למערכת שלא משתנה בכלל!) ב. אתה מתחיל לנסח שם באופן כללי רעיון של פיתוח SEQUENCE פרטי שלא יוצר חורים, במקום פשוט להשתמש במה שאורקל נותן לך ג. לגבי הבעיה שSEQUENCE הוא גלובלי - הפתרון הפשוט הוא לתת רק למשתמש מסוים או לCONTEXT מסוים הרשאה לקדם את הSEQUENCE ואז אף אחד לא ישחק לך בSEQUENCE ד. עדיין נותרת הבעיה של טרנזאקציות שבוטלו אשר יוצרות חורים, ושוב עולה בפי הקצף על קריאות ה"אוי ואבוי" על החור ברצף ה. למה לא לכתוב לבד SEQUENCE שלא יכול ליצור חורים? כי המשמעות של זה היא או נעילות רבות בין משתמשים או יצירה של מידע לא עקבי במערכת.

 

[nahsh]

אלהים אדירים!

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

 

[jonjac]

תודה, אין צורך במחמאות

כתבת במפורש שאתה צריך יכולת לחזות מראש את המספר הבא של B.

 

[nahsh]

נכון. אבל לא אכפת לי מה הוא יהיה

האמת היא שהדרישות הן הפוכות ממה שחשבת: חייבים להיווצר חורים ברצף כי אסור לחזור על ID פעמיים - אף פעם. הבעיה עם sequence בהקשר של QC הוא שהוא לא מתאפס. QC ממלאים ומרוקנים את הDB הלוך ושוב, אבל הsequence רק הולך וגדל. זה לא כ"כ נורא יחסית, וכמו שכבר כתבתי - זה כנראה יהיה הכיוון למרות הכל. מה שאני מנסה לעשות זה לברר אם ישנה אלטרנטיבה מתאימה יותר לפני שאני הולך לשם. זה הכל.

 

[jonjac]

כל כלל יוצר פרדוקס

אם אסור לחזור על ID פעמיים - אף פעם - אז SEQUENCE זה בדיוק המענה לבעיה שלך. כל מה שנותר הוא לטפל בQC. אפשר להסיר את הSEQUENCE וליצור אותו מחדש לפני כל בדיקה. בסביבת הבדיקות אני מניח שלא תהיה בעיה כזו. או שכן?

 

[pitoach]

אני לא ממליץ על מחיקת ה הsequence ויצירה

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

 

[jonjac]

אז מה אתה מציע?

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

 

[pitoach]

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

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

 

[pitoach]

בוקר טוב

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

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

3. לעיתים כשאני נתקל במערכת קיימת שצריך לבצע בה שינוי או תוספת אני מוצא שהאפיון כל כך גרוע או סתם לא מתאים ומכיוון שלא ניתן לשנות את הקיים (הלקוח מסרב / אין זמן / מגבלות ידע או כל דבר אחר) שבמקרה זה כדאי ומתאים לאפיין מערכת מקבילה. אני בשום אופן לא טוען שזה המצב ובלי להכיר את המצב והאפיון המלא שלכם אני רק מציג אופציה! מערכת מקבילה יכולה להיות לפעמים הכנת VIEW שישמשו אותי כמו טבלאות וירטואליות במקום הטבלאות במבנה הקיים אם הוא לא מתאים, זה יכול להכיל אפילו מצב קיצוני של בניית טבלאות חדשות במסד הנתונים שישאבו את הנתונים מטבלאות המקור (למשל עם טריגרים כך שהכל שקוף למשתמש) והמודול החדש שאני מפתח יפנה לטבלאותל אלו ועוד הרבה פתרונות. העובדה שאפיון קיים לא אומרת שלא צריך לאפיין בצורה מסודרת את הפיתוח החדש והפורום אינו ה מתקום לביצוע אפיון מערכת אלא רק מקום לזריקת נקודות למחשבה או דיונים או פתרונות לבעיות ספציפיות. מכיוון שאין לי את האפיון של המערכת+לקוח כאמור אני רק נותן לך נקודות מהן אתה אולי תפיק את הפתרון המתאים וכמו שאמרתי בשירשור אחר אתמול (אני חושב). זה לא בושה לקחת ייעוץ חיצוני לאפיון המערכת בעקר אם לא ניתן להציג את הדברים בפורום בצורה מלאה. 4. אז מה עכשיו? א. תקרא את ההודעה שלי מעל ותבדוק אם היא עוזרת ב. תקרא את ההודעה הבא של jonjac מתחת לעומק כי יש דברים חשובים ג. תגיע להחלטה הבסיסית קודם כל לגבי האם אתה נעול על הפתרון שלך או לא (וכאמור זה לא קשור לאפיון הקיים... ראה סעיף 3) ד. בהנחה שאתה נעול על הדרך שהצגת כאן בפורום עלייך להבין את המגבלות של הבחירה ויש לך כאן בשירשור פתרון דיי סביר לפי מה שאני רואה (כמובן שיהיה חורים באפיון שדורש לא לקבל נתון שכבר היה אם זה נמחק כי המחיקה יוצרת את החור) * הערה: אישית אני בעקרון נגד מחיקת נתונים ממסד הנתונים (כשמערכת מאפשרת זאת). רוב האפליקציות עובדות עם מסדי נתונים קטנים שלא עוברים את ה 100G ובדרך כלל אין סיבות למחיקת נתונים וניתן לעקוף את זה. היתרון באי מחיקה זה בכך שלא נוצרים חורים ולא נאבדים נתונים בין השאר. הוספת טור מסוג ביט בטבלה שמסמן אם הרשומה מחוקה יכול לשמש כ"מחיקה וירטואלית" של הרשומה למשל

 

[jonjac]

לגבי מחיקה

אני מסכים איתך ב100% - לא מוחקים נתונים. מחיקת נתונים, במיוחד אם יש או היתה להם משמעות עסקית, היא טעות. ויש לכך מיליון סיבות. אלא אם מדובר על טבלאות ביניים של ETL. וגם אז, צריכה להישאל השאלה אם אין דרך טובה יותר לשמור את הנתונים, מלבד טבלה רגילה על הדיסק.