sql server COLUMNS_UPDATED function

[ארכיטקט]

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

משהו בסיגנון הזה, אין לי זמן לבדוק עד הסוף אני מקוה שעובד:

insert into dbo.LogTable([Contrnt])
   select 
    c.name
    from sys.columns  c
        inner join sys.objects  o on c.object_id=o.object_id
		where (UPDATE (c.name)) and o.name='Questions'

פורסם במקור בפורום CODE613 ב26/12/2013 15:05 (+02:00)

[dovid]

ארכיטקט שווה לך לעבור על 8 פוסטים של גדי רשף:
זה הראשון, דפדף קדימה עד לסיום הסדרה.

מה שהכי נוגע לענייננו זה הפוסט הזה
http://blogs.microsoft.co.il/gerireshef/2010/05/13/האח-הגדול-עינו-פקוחה-5-מי-שינה-את-הנת/

ושלוש שנים (!) אח"כ פשוט בהרבה:
http://blogs.microsoft.co.il/gerireshef/2013/07/16/האח-הגדול-עינו-פקוחה-6-מי-שינה-את-הנת/

פורסם במקור בפורום CODE613 ב26/12/2013 15:18 (+02:00)

[ארכיטקט]

בסופו של יום יש פתרון לנושא אולם פרט אחד חסר העלנו שאלה לסטאק

אם תהיה תשובה נעדכן גם כאן.

פורסם במקור בפורום CODE613 ב26/12/2013 16:46 (+02:00)

[dovid]

סיכום ביניים לטריגר רגיל:

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

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

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

פורסם במקור בפורום CODE613 ב26/12/2013 21:22 (+02:00)

[ארכיטקט]

אגב לתדהמתי אני רואה פתאום שבאקסס 2013 הם עשו אירועים ברמת הטבלה, ושם אתה מקבל בדיוק מה שרצינו ומה שאמרת שאין ב sql server ערך ישן, ערך חדש, ושם השדה בסטרינג.

לא יאומן איזה גורל, מחליטים בשביל האקססאים לעשות שכלולים שאין לך דרך להשיג אותם ב sql server!!!

פורסם במקור בפורום CODE613 ב31/12/2013 17:42 (+02:00)

[ארכיטקט]

יש אור בקצה המנהרה!!
אפשר להריץ SQL כמחרוזת כזה:

EXECUTE ( 'select * from Contacts')

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

פורסם במקור בפורום CODE613 ב31/12/2013 18:12 (+02:00)

[dovid]

לא הוגן לומר אין בsql sever.
לא הצלחנו עדיין.

פורסם במקור בפורום CODE613 ב31/12/2013 19:14 (+02:00)

[dovid]

@ארכיטקט

יש אור בקצה המנהרה!!
אפשר להריץ SQL כמחרוזת כזה:

EXECUTE ( 'select * from Contacts')

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

ברור שאפשר וזה ידעתי מתחילה רק שזה ממש לא נראה לי דרך נורמלית.

פורסם במקור בפורום CODE613 ב31/12/2013 19:16 (+02:00)

[clickone]

@ארכיטקט

אגב לתדהמתי אני רואה פתאום שבאקסס 2013 הם עשו אירועים ברמת הטבלה, ושם אתה מקבל בדיוק מה שרצינו ומה שאמרת שאין ב sql server ערך ישן, ערך חדש, ושם השדה בסטרינג.

לא יאומן איזה גורל, מחליטים בשביל האקססאים לעשות שכלולים שאין לך דרך להשיג אותם ב sql server!!!

כבר מילתי אמורה בנושא זה רק חבל שמייקרוסופט לקחה את האקסס לכיוון של ה.... עם מאקרו (לך תעשה FOR במאקרו, [לא אמרתי שא"א אבל מעיק]) במקום לכיוון של המתכנתים עם יכולות מורחבות.

פורסם במקור בפורום CODE613 ב31/12/2013 23:25 (+02:00)

[ארכיטקט]

העניין צץ בשנית, והנה אני רואה ערך ערוך בויקיפדיה, האם זה לא אומר משהו???

פורסם במקור בפורום CODE613 ב26/01/2014 18:19 (+02:00)

[רחמים]

@ארכיטקט

http://en.wikipedia.org/wiki/Log_trigger

לטובת החסומים, מה כתוב שם?
תודה.

פורסם במקור בפורום CODE613 ב26/01/2014 18:22 (+02:00)

[ארכיטקט]

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

פורסם במקור בפורום CODE613 ב26/01/2014 18:28 (+02:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב26/01/2014 19:03 (+02:00)

[clickone]

לא.
ארכיטקט צודק.
תמיד מה שאפשר בDB עדיף שייעשה שם ולא בקוד.
בחברות הגדולות יש DBA, שזו בדיוק העבודה שלו.

הכי הגיוני לעשות טבלאות הסטורייה וכו כטריגר. (אני בעוונות עדיין עושה בקוד - בגלל אקסס)

פורסם במקור בפורום CODE613 ב26/01/2014 19:54 (+02:00)

[ארכיטקט]

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

פורסם במקור בפורום CODE613 ב26/01/2014 21:01 (+02:00)

[רחמים]

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

פורסם במקור בפורום CODE613 ב27/01/2014 06:48 (+02:00)

[clickone]

@רחמים

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

לא. - שים לב למה שארכיטקט הסביר - בצדק:
@ארכיטקט

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

אם כבר, יש אפשרות להפעיל פונקציות CLR שכתובות בC# או VB, אבל זה כבר עניין אחר.
בכל מקרה השאיפה היא לעשות כמה שיותר בDB. זה נקרא שכבת פלדה.

פורסם במקור בפורום CODE613 ב27/01/2014 08:19 (+02:00)

[ארכיטקט]

@רחמים

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

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

התחושה האישית שלי, שהנושא של UI הוא הרבה יותר נמצא בתהליכי התפתחות מואצים, מאשר המנועים האמיתיים, כגון דטה בייסים, וקוד ליבה. קח את שפת C ושפת SQL מאז שהמציאו אותן, לא נס ליחן ולא כהתה עינן, הן משרתות להערכתי 90 אחוז מכוח המיחשוב ברחבי העולם!!!! כל הפיתוחים שאנחנו רואים לא מפריעים בכלל למערכות קיימות, אלא רק משפרות ומשכללות. מאידך כמה מהמורות ותמורות עובר תחום ה UI בעשרים שנה האחרונות, כל אחד בא ומחסל את מה שעשה זולתו קודם לכן....

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

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

@ClickOne

אם כבר, יש אפשרות להפעיל פונקציות CLR שכתובות בC# או VB, אבל זה כבר עניין אחר.
בכל מקרה השאיפה היא לעשות כמה שיותר בDB. זה נקרא שכבת פלדה.

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

פורסם במקור בפורום CODE613 ב27/01/2014 15:59 (+02:00)