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

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

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

מקווה שהייתי ברור, אשמח לעזרה בנושא. מדובר בMSSQL 2005.
תודה,
אור.

הSP צריך פשוט להחזיר JOIN של שתי הטבלאות.

[התמונה הבאה מגיעה מקישור שלא מתחיל ב https ולכן לא הוטמעה בדף כדי לשמור על https תקין: http://www.varon.co.il/signature.asp?type=.jpg]

"The reasonable man adapts himself to the world,

The unreasonable one persists in trying to adapt the world to himself,

Therefore all progress depends on the unreasonable man" --- George Bernard Shaw

join אני מכיר היטב ולא נראה לי שאפשר לעשות עם זה מה שאני רוצה, אבל אם יש דרך זה מעולה
Crosstab אני לא מכיר, תוכלו להפנות אותי למשהו שיעזור לי עם הנושא שלי ?

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

הרעיון הכללי לייצג את הדברים הנ"ל בטבלאות כך שתשאר גמישות בנוגע להוספה של קטגוריות חדשות וכן עריכה של הפרטים שאמורים להיות בכל קטגוריה הוא ע"י מספר טבלאות:
1. טבלת קטגוריות פשוטה (שם, מספר וכו').
2. טבלת מוצרים פשוטה (מספר, מספר קטגוריה [נניח שכל מוצר משתייך לאחת בלבד], מחיר).
ועכשיו הגענו לחלק הטריקי, הייצוג שבחרתי לשדות המותאמים הוא כזה (אם יש שיטה טובה יותר מה טוב):
3. טבלת שדות (שם שדה, סוג ערכים מתקבלים [מספר, מחרוזת ..], מספר קטגוריה [כל שדה שייך לקטגוריה אחת], ונגיד גם ערך ברירת מחדל).
4. טבלת ערכים לשדות המותאמים (מספר שדה [מ3], מספר מוצר רלוונטי [מ2] וכן ערך השדה כמובן).

עכשיו בסופו של דבר אני לא רוצה להתעסק עם כל הטבלאות, אני רוצה לבחור קטגוריה, ושתוצג לי טבלה אחת פשוטה שבה יש עבור כל מוצר בקטגוריה את המספר שלו, את המחיר שלו [מטבלה 2 עצמה], ובנוסף את השדות המותאמים שלו בהתאם לקטגוריה, וכן הערכים שלהם [מ4 בהצלבה עם 3].

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

תודה


עריכה: אגב הצלחתי לעשות זאת באופן חלקי בלבד ע"י יצירת שאילתת הsql באופן דינמי, אבל זה לא עובר קומפילציה בצורה זו, וכן - זה מגביל אותי מאוד.

מקוה שהבנתי את הרעיון (המקורי, דרך אגב ).

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

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

מה שאני מציע לך לעשות זה ככה - צור טבלה המכילה שדה id מסוג INT ושדה id_assoc מסוג VARCHAR.

השדה id יכיל מספרים הקשורים לכל סוג מוצר (id של מכוניות, id של מחשבים וכו').
השדה id_assoc יכיל את ה-id האסוציאטיבי של סוג המוצר, כדי שתוכל לבצע פעולות בקוד צד השרת.

כאשר מישהו מבצע חיפוש על מכוניות שיש להם id=5, אז מה שתעשה זה תשלוף את ה- id_assoc שיש לו id=5, ובעזרת קוד צד השרת (PHP או DOT NET או מה שאתה משתמש) תבצע אינקלוד לקובץ המתאים שמתעסק במכוניות, שהשם שלו הוא הערך בשדה id_assoc.
לכל סוג מוצר יהיה טבלה משלו, ושם הטבלה גם עשוי להיות הערך שנמצא ב- id_assoc.

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

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

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

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

שוב תודה,
אור.

אוקי, שיהיה בהצלחה


הנה כמה תוצאות שמצאתי מחיפוש בגוגל, מקוה שיעזרו:
http://www.simple-talk.com/sql/t-sq...-tables-in-sql/
http://www.databasejournal.com/feat...Server-2005.htm
http://www.sqlteam.com/article/dyna...bs-pivot-tables

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

היי, שוב תודה

נתקלתי כבר בחיפוש במאמרים דומים לאלו, ממה שראיתי הPIVOT וענייני הCrossTab האלה הם חזקים לנתונים מספריים, אבל לא ממש מצאתי איך אני יכול להשתמש בהם לצורך שלי.

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

וזה כבר נשמע מונוטוני, אבל:
שוב תודה.