מה מותר XML מ DATABASE ?
- פותח הנושא Darren
- פורסם בתאריך
XML הוא לא מסד נתונים
XML הוא תקן לארגון הנתונים. כיוון שאני מניח שאצלך "מסד נתונים" = "מסד נתונים טבלאי", אתה בודאי מתכוון לארגון הנתונים בטבלאות. XML מעניק יתרון בניהול תכנים. קל יותר לאין ערוך לשמור את התכנים ב-XML, לקבלם, להפיצם ולהציגם בפורמט זה. באמצעות XML ניתן לשמור כל סוג של תוכן ובקלות, שלא לדבר על האצת תהליך הפיתוח ופישוטו. לשאלתך, חלילה לך לשלוף נתונים ממסד נתונים ולארגן אותם שוב ב-XML. אין בכך כל הגיון - מבחינות של ביצועים, שלמות הנתונים, סטנדרטיות ועוד סיבות רבות. ולשאלתך המתבקשת, מסמכי XML לא נשמרים במסדי נתונים טבלאיים. הם בעלי אופי הירארכי והסטנדרטים לטיפול בהם שונים בתכלית (לדוגמא - סכמות למודל הנתונים, XQuery לשליפה ועוד). לצורך שמירה וניהול של מסמכי XML יש לעשות שימוש בשרתי XML, אשר נועדו לכך. ולמען ההבחנה - מסדי הנתונים הטבלאיים ישמשו לנתונים הטראנזאקציוניים, לנתונים בעלי אופי טבלאי ועוד. התכנים, מנגד, ישמרו וינוהלו ב-XML. שאלות ?
XML הוא תקן לארגון הנתונים. כיוון שאני מניח שאצלך "מסד נתונים" = "מסד נתונים טבלאי", אתה בודאי מתכוון לארגון הנתונים בטבלאות. XML מעניק יתרון בניהול תכנים. קל יותר לאין ערוך לשמור את התכנים ב-XML, לקבלם, להפיצם ולהציגם בפורמט זה. באמצעות XML ניתן לשמור כל סוג של תוכן ובקלות, שלא לדבר על האצת תהליך הפיתוח ופישוטו. לשאלתך, חלילה לך לשלוף נתונים ממסד נתונים ולארגן אותם שוב ב-XML. אין בכך כל הגיון - מבחינות של ביצועים, שלמות הנתונים, סטנדרטיות ועוד סיבות רבות. ולשאלתך המתבקשת, מסמכי XML לא נשמרים במסדי נתונים טבלאיים. הם בעלי אופי הירארכי והסטנדרטים לטיפול בהם שונים בתכלית (לדוגמא - סכמות למודל הנתונים, XQuery לשליפה ועוד). לצורך שמירה וניהול של מסמכי XML יש לעשות שימוש בשרתי XML, אשר נועדו לכך. ולמען ההבחנה - מסדי הנתונים הטבלאיים ישמשו לנתונים הטראנזאקציוניים, לנתונים בעלי אופי טבלאי ועוד. התכנים, מנגד, ישמרו וינוהלו ב-XML. שאלות ?
שמירת נתונים ב- XML ?
שלום לכולם !, יש לי שאלה בנוגע לסוגיית ה- XML ו- DB. בסיסי נתונים טבלאיים מספקים יתרונות בעבודה מולם. לדוגמא, האפשרות לזרז ביצועים על ידי יצרית אינדקסים, וסוגי האינדקסים השונים. מסמך XML יהיה בדרך כלל איזשהו STREAM שעובר ממקום למקום, וכאשר צריך לשמור אותו, בדרך כלל להוסיף את המידע שהוא מכיל למידע קיים בבסיס הנתונים, נראה לי הגיוני יותר לפרק אותו למרכיביו ולשמור את המרכיבים כך שכשנצטרך את המידע שוב, נוכל להפעיל QUERY פשוט, לקבל את הנתונים, לבנות את ה- XML ולשלוח אותו לאן שצריך. במילים אחרות, להשתמש ב- XML אך ורק לצרכי transportation. האם יש הגיון בדבריי ? או שקיימת טכנולוגיה שאיני מודע לה / מכיר אותה, אשר מסוגלת לגשר בין מסמכי XML ולהרכיב טרנזקציית DB מהם כך שגם הנתונים יישמרו ב- XML בבסיס הנתונים, ושוב.. במקרה כזה, האם לא יישמר כל המסמך כ- BLOB או איזשהו שדה VARCHAR אינסופי ? ובמקרה כזה.. מה עם האינדקסים ? איך נשלוף מידע ספציפי ? איך נעשה חיפושים... ??? אני חושב שצריך שחברה כלשהי צריכה להרים כפפה ולייצר מנוע DB שלם מונע XML, האם יש דבר כזה ?
שלום לכולם !, יש לי שאלה בנוגע לסוגיית ה- XML ו- DB. בסיסי נתונים טבלאיים מספקים יתרונות בעבודה מולם. לדוגמא, האפשרות לזרז ביצועים על ידי יצרית אינדקסים, וסוגי האינדקסים השונים. מסמך XML יהיה בדרך כלל איזשהו STREAM שעובר ממקום למקום, וכאשר צריך לשמור אותו, בדרך כלל להוסיף את המידע שהוא מכיל למידע קיים בבסיס הנתונים, נראה לי הגיוני יותר לפרק אותו למרכיביו ולשמור את המרכיבים כך שכשנצטרך את המידע שוב, נוכל להפעיל QUERY פשוט, לקבל את הנתונים, לבנות את ה- XML ולשלוח אותו לאן שצריך. במילים אחרות, להשתמש ב- XML אך ורק לצרכי transportation. האם יש הגיון בדבריי ? או שקיימת טכנולוגיה שאיני מודע לה / מכיר אותה, אשר מסוגלת לגשר בין מסמכי XML ולהרכיב טרנזקציית DB מהם כך שגם הנתונים יישמרו ב- XML בבסיס הנתונים, ושוב.. במקרה כזה, האם לא יישמר כל המסמך כ- BLOB או איזשהו שדה VARCHAR אינסופי ? ובמקרה כזה.. מה עם האינדקסים ? איך נשלוף מידע ספציפי ? איך נעשה חיפושים... ??? אני חושב שצריך שחברה כלשהי צריכה להרים כפפה ולייצר מנוע DB שלם מונע XML, האם יש דבר כזה ?
אני חייב להסכים גם איתך
וגם עם דון פאקטו. יש היגיון בדבריך. זה אפילו עובד ברשת. כל מיני מצבים בהם בונים ומפרקים תבניות XML שונות ומכניסים אותם לתוך DB. למשל חנויות ווירטואליות הבונות את סל המוצרים פעם אחת מתוך DB ומציגות כל מיני חלקים של קובץ XML גדול. או אותן חנויות הבונות את ההזמנה בצד לקוח בתור XML ובסופה של הקניה מעדכנות את הDB בבת אחת בכל ההזמנה עם הנתונים. פה הנתונים לא נישמרים במחרוזת ארוכה אחת אלא ניכנסים לתוך התאים בDB בעזרת מניפולציות על הXMLDOM בצד שרת. או לדוגמא הפוכה - DATA BINDING של XML שמתקבל מתוך סקריפט ASP וניכנס למבנה קבוע. יש המון דוגמאות אבל היתרון העיקרי של XML הוא עיצוב מידע ושיתוף מידע. לא שמירת מידע [בשביל זה יש DB]. XML מסייעת לי המתכנת בעיצוב המידע בצורה קלה ונוחה לקריאה [אני קובע את התגיות] ומאפשרת לי לשלוח ולשתף זאת עם שרתים אחרים או משתמשים אחרים, דבר שלא יכלו לעשות לDB שלי [אם הוא לא RDMS כמובן].
וגם עם דון פאקטו. יש היגיון בדבריך. זה אפילו עובד ברשת. כל מיני מצבים בהם בונים ומפרקים תבניות XML שונות ומכניסים אותם לתוך DB. למשל חנויות ווירטואליות הבונות את סל המוצרים פעם אחת מתוך DB ומציגות כל מיני חלקים של קובץ XML גדול. או אותן חנויות הבונות את ההזמנה בצד לקוח בתור XML ובסופה של הקניה מעדכנות את הDB בבת אחת בכל ההזמנה עם הנתונים. פה הנתונים לא נישמרים במחרוזת ארוכה אחת אלא ניכנסים לתוך התאים בDB בעזרת מניפולציות על הXMLDOM בצד שרת. או לדוגמא הפוכה - DATA BINDING של XML שמתקבל מתוך סקריפט ASP וניכנס למבנה קבוע. יש המון דוגמאות אבל היתרון העיקרי של XML הוא עיצוב מידע ושיתוף מידע. לא שמירת מידע [בשביל זה יש DB]. XML מסייעת לי המתכנת בעיצוב המידע בצורה קלה ונוחה לקריאה [אני קובע את התגיות] ומאפשרת לי לשלוח ולשתף זאת עם שרתים אחרים או משתמשים אחרים, דבר שלא יכלו לעשות לDB שלי [אם הוא לא RDMS כמובן].
ואני דווקא לא מסכים איתך ../images/Emo132.gif
אני מסכים דווקא עם ניר דגן, שהסביר מדוע תרגום של XML לעולם הטבלאי בעייתי. XML הוא אוסף של סטנדרטים שנועדו לניהול תכנים. הנושא של "עיצוב מידע ושיתוף מידע", אם לצטט אותך, הוא רק חלק קטן מהעניין. לעניות דעתי, אם אתה נוקט בשבירה של ה-XML לטבלאות, אתה מחמיץ חלק גדול מאוד מיתרונות ה-XML. אין יותר יישות לוגית שנקראת מסמך, אלא רק רסיסים ויש לכך משמעות על ביצועים (Join היא פעולה מאוד כבדה), של סטנדרטים (הפירוק של ה-XML הוא מאוד propriatery), של שלמות הנתונים ועוד ועוד. גם אנו התעמקנו בשאלה הזו אצלנו בחברה ולפי דעתי, כל חברה, שניגשת ל-XML, תעסוק בסוגיה. אני לא אלאה אתכם בפרטים, אבל המסקנות שלנו היו לעשות שימוש במסדי נתונים טבלאיים לנתונים בעלי אופי טבלאי (כמו טבלת קודי עובדים) ובשרתי XML לניהול נתוני XML. ולמני, ששאל, אין צורך להרים את הכפפה. היא קיימת ושרירה.
אני מסכים דווקא עם ניר דגן, שהסביר מדוע תרגום של XML לעולם הטבלאי בעייתי. XML הוא אוסף של סטנדרטים שנועדו לניהול תכנים. הנושא של "עיצוב מידע ושיתוף מידע", אם לצטט אותך, הוא רק חלק קטן מהעניין. לעניות דעתי, אם אתה נוקט בשבירה של ה-XML לטבלאות, אתה מחמיץ חלק גדול מאוד מיתרונות ה-XML. אין יותר יישות לוגית שנקראת מסמך, אלא רק רסיסים ויש לכך משמעות על ביצועים (Join היא פעולה מאוד כבדה), של סטנדרטים (הפירוק של ה-XML הוא מאוד propriatery), של שלמות הנתונים ועוד ועוד. גם אנו התעמקנו בשאלה הזו אצלנו בחברה ולפי דעתי, כל חברה, שניגשת ל-XML, תעסוק בסוגיה. אני לא אלאה אתכם בפרטים, אבל המסקנות שלנו היו לעשות שימוש במסדי נתונים טבלאיים לנתונים בעלי אופי טבלאי (כמו טבלת קודי עובדים) ובשרתי XML לניהול נתוני XML. ולמני, ששאל, אין צורך להרים את הכפפה. היא קיימת ושרירה.
בסיסי הנתונים תומכים ב XML
בסיסי הנתונים הגדולים תומכים תמיכה מלאה ב XML לצורכי שמירה שליפה ומחיקה במיוחד SQL SERVER 2000 התומך גם בשליפה עי פרוצדורות - select * table for xml auto, elments במידה ומתקינים רכיב של SQLXML אז ניתן לשלוף נתונים באמצעות סכמות ולהוסיף/למחוק/לעדכן במהלך אחד של גישה לDB ע"י טכנולוגיה ששמה UPDATEGRAMS מומלץ ביותר !!! שולחים XML BEFORE + XML AFTER ובסיס הנתונים מתעדכן...
בסיסי הנתונים הגדולים תומכים תמיכה מלאה ב XML לצורכי שמירה שליפה ומחיקה במיוחד SQL SERVER 2000 התומך גם בשליפה עי פרוצדורות - select * table for xml auto, elments במידה ומתקינים רכיב של SQLXML אז ניתן לשלוף נתונים באמצעות סכמות ולהוסיף/למחוק/לעדכן במהלך אחד של גישה לDB ע"י טכנולוגיה ששמה UPDATEGRAMS מומלץ ביותר !!! שולחים XML BEFORE + XML AFTER ובסיס הנתונים מתעדכן...
הם ממש ממש לא תומכים. ../images/Emo22.gif
כיוון שמסדי נתונים רלציוניים הנם מסדי נתונים לנתונים טבלאיים, הם לא נועדו לטפל בנתונים הירארכיים, כל שכן לתמוך בטכנולוגיות סביב. מה שקורה הוא שנוספה שכבת מעטפת אפליקטיבית מעל ה-DB, אשר מאפשרת כביכול לדבר XML. בוא נראה - הגישה לנתוני XML אמורה להיות XPATH/XQERY וכאן אתה נופל למעמקי ממשק מאוד propriatery. מה שמבטיח ליצרן כבילה אליו - בניגוד למה ש-XML מתכוון לעשות - ובנוסף הביצועים ירודים. מה שמובטח לך, הוא שלא תוכל לחבר בקלות מוצרים ורכיבים, אשר מדברים בסטנדרטים של XML. בסופו של היום, הנתונים למעשה נשמרים בטבלאות. מתבצע פירוק אפליקטיבי לטבלאות וחיבור מחודש, כאשר שולפים את המידע. כל מי שהתעסק קצת ברצינות עם מסדי נתונים, מבין טוב מאוד את המשמעות של פעולות Join רבות ואת שלמות הנתונים (היה מסמך ואיננו - קיימים רסיסים בכל מיני טבלאות, שרק אלוהים והממשק יודעים לגשת אליהם). אם נתעמק קצת יותר, נגלה ש-XML הוא למעשה מודל נתונים הירארכי. מודל כזה מצריך תמיכה ביכולות בסיסיות כמו אינדקסים הירארכיים, אבטחה הירארכית וכו´. גם כאן, אם ישנה תמיכה, היא מאוד חלקית ולוקה (כמה כבר אפשר למתוח את הגבולות של מוצר, שלא נועד לשם כך). אני חושב שהעיקרון כבר ברור ולא אתעמק בסיבות נוספות טובות לא פחות. איך אומרים אצלנו בארץ -קומבינה ?
אפשר לסכם ולומר, כי אם אתה צריך לשמור מסמך או שניים ויש לך DB רלציוני ואתה מצוייד בניסיון בעבודה עימו זה בהחלט יכול לעבוד. אולם אתה עוסק ב-XML קצת יותר ברצינות, זה כבר לא מתאים.
כיוון שמסדי נתונים רלציוניים הנם מסדי נתונים לנתונים טבלאיים, הם לא נועדו לטפל בנתונים הירארכיים, כל שכן לתמוך בטכנולוגיות סביב. מה שקורה הוא שנוספה שכבת מעטפת אפליקטיבית מעל ה-DB, אשר מאפשרת כביכול לדבר XML. בוא נראה - הגישה לנתוני XML אמורה להיות XPATH/XQERY וכאן אתה נופל למעמקי ממשק מאוד propriatery. מה שמבטיח ליצרן כבילה אליו - בניגוד למה ש-XML מתכוון לעשות - ובנוסף הביצועים ירודים. מה שמובטח לך, הוא שלא תוכל לחבר בקלות מוצרים ורכיבים, אשר מדברים בסטנדרטים של XML. בסופו של היום, הנתונים למעשה נשמרים בטבלאות. מתבצע פירוק אפליקטיבי לטבלאות וחיבור מחודש, כאשר שולפים את המידע. כל מי שהתעסק קצת ברצינות עם מסדי נתונים, מבין טוב מאוד את המשמעות של פעולות Join רבות ואת שלמות הנתונים (היה מסמך ואיננו - קיימים רסיסים בכל מיני טבלאות, שרק אלוהים והממשק יודעים לגשת אליהם). אם נתעמק קצת יותר, נגלה ש-XML הוא למעשה מודל נתונים הירארכי. מודל כזה מצריך תמיכה ביכולות בסיסיות כמו אינדקסים הירארכיים, אבטחה הירארכית וכו´. גם כאן, אם ישנה תמיכה, היא מאוד חלקית ולוקה (כמה כבר אפשר למתוח את הגבולות של מוצר, שלא נועד לשם כך). אני חושב שהעיקרון כבר ברור ולא אתעמק בסיבות נוספות טובות לא פחות. איך אומרים אצלנו בארץ -קומבינה ?
קומבינות
ראשית, אני עוסק בזה מאוד ברצינות ולא עושה קומבינות שנית אם אתה קורא למתודולוגית הפיתוח של מיקרוסופט חובבנות אז אני שמח להיות חובבן. שלישית אני מציע לך להוריד מאתר מיקרוסופט שני כלים המתלבשים על SQL SERVER 2000 XML View Mapper - המאפשר ליצור סכמות בקלות יחסית המבטאות את הקשרים בין הטבלאות למול ההיררכיה של המסמך SQLXML המאפשר לסכמה בצירוף ה- XPATH ליצור את הקישור המלא לבסיס הנתונים
ראשית, אני עוסק בזה מאוד ברצינות ולא עושה קומבינות שנית אם אתה קורא למתודולוגית הפיתוח של מיקרוסופט חובבנות אז אני שמח להיות חובבן. שלישית אני מציע לך להוריד מאתר מיקרוסופט שני כלים המתלבשים על SQL SERVER 2000 XML View Mapper - המאפשר ליצור סכמות בקלות יחסית המבטאות את הקשרים בין הטבלאות למול ההיררכיה של המסמך SQLXML המאפשר לסכמה בצירוף ה- XPATH ליצור את הקישור המלא לבסיס הנתונים
בוא נראה...../images/Emo26.gif
ה-XML View Mapper הוא בגירסא 1.0 שלא התעדכנה מזה שנה וחצי. זה רציני בעיניך ? ואני אשמח אם תתייחס עניינית למה שהעליתי - 1. הממשק ל-XML הוא סטנדרטי או propriatery ? 2. האם אתה זוכה ליכולות בסיסיות, כמו אבטחה הירארכית ? אינדקסים הירארכיים ? 3. לדעתך המקצועית, אתה לא משלם ביוקר על השבירות ועל החיבורים ? זה מתאים לעבודת heavy duty ? ובוא תחשוב על נקודה בסיסית - אם אתה עובר למודל הירארכי, למה לקשור אותו בכוח למודל טבלאי, שהוא, אם נחשוב לרגע, מקרה מאוד פרטי של XML ? בנוגע לביקורת על מיקרוסופט - אני חושב שחלק מהדברים שהם עושים הוא נפלא וחלק מהדברים שהם עושים הוא מזעזע. הדברים שהם אומרים אינם מקודשים בעיני משל "ראה וקדש", אלא אני מביט עליהם (ועל שאר החברות) בעיניים מקצועיות וביקורתיות. מצטער, אבל אין לי מניות של אף חברה. מה שכן, יש לי לקוחות שדורשים את הפתרונות הטובים ביותר.
ה-XML View Mapper הוא בגירסא 1.0 שלא התעדכנה מזה שנה וחצי. זה רציני בעיניך ? ואני אשמח אם תתייחס עניינית למה שהעליתי - 1. הממשק ל-XML הוא סטנדרטי או propriatery ? 2. האם אתה זוכה ליכולות בסיסיות, כמו אבטחה הירארכית ? אינדקסים הירארכיים ? 3. לדעתך המקצועית, אתה לא משלם ביוקר על השבירות ועל החיבורים ? זה מתאים לעבודת heavy duty ? ובוא תחשוב על נקודה בסיסית - אם אתה עובר למודל הירארכי, למה לקשור אותו בכוח למודל טבלאי, שהוא, אם נחשוב לרגע, מקרה מאוד פרטי של XML ? בנוגע לביקורת על מיקרוסופט - אני חושב שחלק מהדברים שהם עושים הוא נפלא וחלק מהדברים שהם עושים הוא מזעזע. הדברים שהם אומרים אינם מקודשים בעיני משל "ראה וקדש", אלא אני מביט עליהם (ועל שאר החברות) בעיניים מקצועיות וביקורתיות. מצטער, אבל אין לי מניות של אף חברה. מה שכן, יש לי לקוחות שדורשים את הפתרונות הטובים ביותר.
תשמע...
אכן גם לי אין מניות באף חברה ובטח לא במיקרוסופט גם אורקל וגם SQL SERVER מציעים פתרונות לעבודה עם XML בסופו של דבר הלקוח בוחר פתרון המתאים לו הסטנדרטיזציה היא חשובה לתעבורת המידע למשל בין ספקים שונים והיא לא מופרת כאשר אתה מחזיק את המידע גם בבסיס הנתונים שבחרת יתר על כן עוד לא ראיתי לקוח שיוותר על אכסון המידע במקביל בבסיס הנתונים ולו לשם הפקת דוחות,תחזוקה וגיבוי גם אם המבנה היררכי הרי מסדי הנתונים יכולים לחולל עץ היררכי לדוגמא עם דאטה שייפ כמו בכל דבר אין אמת אחת וכל דבר הוא בהתאם לנסיבות והדרישות של הלקוח להזכירך השאלה המקורית היתה מה מותר XML על בסיס הנתונים אני רואה את עיקר היתרון בעבודה בצד הלקוח ומניעת תעבורת רשת רבה לאחר שמשתמש סיים לערוך את המידע בגישה אחת לשרת הוא שומר אותו המבנה ההיררכי מאפשר לנו להעביר לצד הלקוח הרבה מהדברים שנעשו בעבר בגישות מרובות לבסיס הנתונים כמו מיון, חיפוש, רשימות בחירה התלויות אחת בשניה וכיוצא בזה אני לא באתי כאן לבדוק למי יש אבא יותר חזק אלא סך הכל כולנו רוצים ללמוד כאן וניסיתי להציג גישה אחרת מי שירצה יפנים ומי שלא שיהיה לו בהצלחה חוץ מזה ה-XML View Mapper הוא אכן בגרסה 1.0 אבל בדוט נט הם מציעים פתרון המשך הם לא המשיכו עם הפתרון הקודם משום שהוא תמך בפורמט XDR והם עברו ל XSD מכיוון שהתקן שהם הציעו לא אושר אבל עדיין ניתן לעבוד איתו
אכן גם לי אין מניות באף חברה ובטח לא במיקרוסופט גם אורקל וגם SQL SERVER מציעים פתרונות לעבודה עם XML בסופו של דבר הלקוח בוחר פתרון המתאים לו הסטנדרטיזציה היא חשובה לתעבורת המידע למשל בין ספקים שונים והיא לא מופרת כאשר אתה מחזיק את המידע גם בבסיס הנתונים שבחרת יתר על כן עוד לא ראיתי לקוח שיוותר על אכסון המידע במקביל בבסיס הנתונים ולו לשם הפקת דוחות,תחזוקה וגיבוי גם אם המבנה היררכי הרי מסדי הנתונים יכולים לחולל עץ היררכי לדוגמא עם דאטה שייפ כמו בכל דבר אין אמת אחת וכל דבר הוא בהתאם לנסיבות והדרישות של הלקוח להזכירך השאלה המקורית היתה מה מותר XML על בסיס הנתונים אני רואה את עיקר היתרון בעבודה בצד הלקוח ומניעת תעבורת רשת רבה לאחר שמשתמש סיים לערוך את המידע בגישה אחת לשרת הוא שומר אותו המבנה ההיררכי מאפשר לנו להעביר לצד הלקוח הרבה מהדברים שנעשו בעבר בגישות מרובות לבסיס הנתונים כמו מיון, חיפוש, רשימות בחירה התלויות אחת בשניה וכיוצא בזה אני לא באתי כאן לבדוק למי יש אבא יותר חזק אלא סך הכל כולנו רוצים ללמוד כאן וניסיתי להציג גישה אחרת מי שירצה יפנים ומי שלא שיהיה לו בהצלחה חוץ מזה ה-XML View Mapper הוא אכן בגרסה 1.0 אבל בדוט נט הם מציעים פתרון המשך הם לא המשיכו עם הפתרון הקודם משום שהוא תמך בפורמט XDR והם עברו ל XSD מכיוון שהתקן שהם הציעו לא אושר אבל עדיין ניתן לעבוד איתו
בהחלט והרי תגובתי../images/Emo26.gif
ראשית, יש תמימות דיעים ששימוש בסטנדרטים חשוב לכל אורך הדרך ולא רק בעת הפצתו. אם אתה מקבל מידע בצורה סטנדרטית ושובר אותו בצורה propriatery כלשהי, אתה פוגע בסטנדרטים ויש לכך משמעויות כבדות משקל. אם תעצור לרגע ותחשוב, המהפכנות בטכנולוגיות XML היא בסטנדרטים ובפשטות. לשם כך, לדוגמא, מפותח סטנדרט XPATH לגישה אל מסמכי XML. אם אתה שובר את המסמך לרסיסים רבים, והגישה אליהם איננה סטנדרטית, יש לכך משמעויות רבות - ראשית, לא תוכל לעשות שימוש בתוכנות ומודולים אחרים, אשר עובדים בהתאם לסטנדרט. שנית, העבודה אשר מושקעת בקביעת הסטנדרטים היא בין היתר לקבוע מהי הדרך המומלצת לטפל לנתונים, מבחינות מעשיות רבות. ושלישית, אתה נכבל ליישום מאוד מסוים של חברת כזו או אחרת. "..עוד לא ראיתי לקוח שיוותר על אחסון המידע במקביל בבסיס הנתונים" - אני רואה הרבה ארגונים שעושים שימוש כזה או אחר ב-XML ואני יכול להצביע על 3 מגמות - 1. ישנם ארגונים, שעושים שימוש במסד הנתונים הראלציוני, שנמצא בד"כ בשימוש. הקמה מהירה אולם לאורך זמן מתגלות בעיות רבות - כמו ביצועים, אבטחה, סטנדרטיות, פתיחות וכו´. 2. חברות לא מעטות הבינו כי טכנולוגיית XML אינה מתאימה לעולם הרלציוני, ומבלית ברירה, הם שומרים את הנתונים ב-filesystem עם או בלי ממשק מתאים. מצד אחד הם מרוויחים את הטכנולוגיה אולם מצד שני, קובץ הוא קובץ (ואף אחד לא רוצה להמציא את הגלגל מחדש). 3. כיוון שהטכנולוגיה היא מורכבת ומצריכה טיפולים חדשים, הופיעו שרתי XML אשר מספקים אפשרות לשמור את הנתונים. מצד אחד, הם סטנדרטים וביצועיסטים מהמסד עד הטפחות. מצד שני, הם חדשים בשוק. XML הוא לא מסד נתונים ולכן אין מקום למשפט כמו "מותר XML על בסיס הנתונים". מסד נתונים הוא מנוע לשמור נתונים. לצורך העניין - מסד נתונים XML-י, כמו Xindice נועד לשמור את המסמכים במבנה המקורי. בנוגע לנקודה זו, הייתי מציע לך לחפש מה אמר מנהל המוצר של Oracle 9i בחברת Oracle העולמית, בנוגע למקום הטוב ביותר לנהל בו מסמכי XML. אני חושב שתופתע. "אני רואה את עיקר היתרון בעבודה בצד הלקוח ומניעת תעבורת רשת רבה לאחר שמשתמש סיים לערוך את המידע בגישה אחת לשרת הוא שומר אותו המבנה ההיררכי מאפשר לנו להעביר לצד הלקוח הרבה מהדברים שנעשו בעבר בגישות מרובות לבסיס הנתונים כמו מיון, חיפוש, רשימות בחירה התלויות אחת בשניה וכיוצא בזה". אני חושב שיתרונות התקן הם הרבה יותר רחבים. אם תביט על התמונה השלמה, תגלה שלראשונה יש סטנדרט לייצוג נתונים. אם תחשוב מה היינו עושים לפני הופעת התקן, תגלה שהיינו כבולים לטכנולוגיות מסויימות, למוצרים כאלו ואחרים, לפיתוחים מיותרים, חרקנו שיניים כאשר רצינו לבצע אינטגרציה בין מערכות, כססנו ציפורניים בעצבנות עם הופעת מדיות תצוגה שונות (סלולר, PDA, וכו´), בילינו זמן רב מאוד בפיתוח, קביעת סטנדרטים מערכתיים ובנרמול של טבלאות, ועוד ועוד. ובסופו של דבר, אנחנו פה אכן ללמוד אחד מהשני ולקיים דיונים. אני חושב שתסכים עימי שהרבה יותר נחמד להציג דיעות שונות ולהתווכח מאשר להשיב על שאלה קטנה על תחביר כזה או אחר (הגם שכבודה של שאלה כזו במקומו מונח).
ראשית, יש תמימות דיעים ששימוש בסטנדרטים חשוב לכל אורך הדרך ולא רק בעת הפצתו. אם אתה מקבל מידע בצורה סטנדרטית ושובר אותו בצורה propriatery כלשהי, אתה פוגע בסטנדרטים ויש לכך משמעויות כבדות משקל. אם תעצור לרגע ותחשוב, המהפכנות בטכנולוגיות XML היא בסטנדרטים ובפשטות. לשם כך, לדוגמא, מפותח סטנדרט XPATH לגישה אל מסמכי XML. אם אתה שובר את המסמך לרסיסים רבים, והגישה אליהם איננה סטנדרטית, יש לכך משמעויות רבות - ראשית, לא תוכל לעשות שימוש בתוכנות ומודולים אחרים, אשר עובדים בהתאם לסטנדרט. שנית, העבודה אשר מושקעת בקביעת הסטנדרטים היא בין היתר לקבוע מהי הדרך המומלצת לטפל לנתונים, מבחינות מעשיות רבות. ושלישית, אתה נכבל ליישום מאוד מסוים של חברת כזו או אחרת. "..עוד לא ראיתי לקוח שיוותר על אחסון המידע במקביל בבסיס הנתונים" - אני רואה הרבה ארגונים שעושים שימוש כזה או אחר ב-XML ואני יכול להצביע על 3 מגמות - 1. ישנם ארגונים, שעושים שימוש במסד הנתונים הראלציוני, שנמצא בד"כ בשימוש. הקמה מהירה אולם לאורך זמן מתגלות בעיות רבות - כמו ביצועים, אבטחה, סטנדרטיות, פתיחות וכו´. 2. חברות לא מעטות הבינו כי טכנולוגיית XML אינה מתאימה לעולם הרלציוני, ומבלית ברירה, הם שומרים את הנתונים ב-filesystem עם או בלי ממשק מתאים. מצד אחד הם מרוויחים את הטכנולוגיה אולם מצד שני, קובץ הוא קובץ (ואף אחד לא רוצה להמציא את הגלגל מחדש). 3. כיוון שהטכנולוגיה היא מורכבת ומצריכה טיפולים חדשים, הופיעו שרתי XML אשר מספקים אפשרות לשמור את הנתונים. מצד אחד, הם סטנדרטים וביצועיסטים מהמסד עד הטפחות. מצד שני, הם חדשים בשוק. XML הוא לא מסד נתונים ולכן אין מקום למשפט כמו "מותר XML על בסיס הנתונים". מסד נתונים הוא מנוע לשמור נתונים. לצורך העניין - מסד נתונים XML-י, כמו Xindice נועד לשמור את המסמכים במבנה המקורי. בנוגע לנקודה זו, הייתי מציע לך לחפש מה אמר מנהל המוצר של Oracle 9i בחברת Oracle העולמית, בנוגע למקום הטוב ביותר לנהל בו מסמכי XML. אני חושב שתופתע. "אני רואה את עיקר היתרון בעבודה בצד הלקוח ומניעת תעבורת רשת רבה לאחר שמשתמש סיים לערוך את המידע בגישה אחת לשרת הוא שומר אותו המבנה ההיררכי מאפשר לנו להעביר לצד הלקוח הרבה מהדברים שנעשו בעבר בגישות מרובות לבסיס הנתונים כמו מיון, חיפוש, רשימות בחירה התלויות אחת בשניה וכיוצא בזה". אני חושב שיתרונות התקן הם הרבה יותר רחבים. אם תביט על התמונה השלמה, תגלה שלראשונה יש סטנדרט לייצוג נתונים. אם תחשוב מה היינו עושים לפני הופעת התקן, תגלה שהיינו כבולים לטכנולוגיות מסויימות, למוצרים כאלו ואחרים, לפיתוחים מיותרים, חרקנו שיניים כאשר רצינו לבצע אינטגרציה בין מערכות, כססנו ציפורניים בעצבנות עם הופעת מדיות תצוגה שונות (סלולר, PDA, וכו´), בילינו זמן רב מאוד בפיתוח, קביעת סטנדרטים מערכתיים ובנרמול של טבלאות, ועוד ועוד. ובסופו של דבר, אנחנו פה אכן ללמוד אחד מהשני ולקיים דיונים. אני חושב שתסכים עימי שהרבה יותר נחמד להציג דיעות שונות ולהתווכח מאשר להשיב על שאלה קטנה על תחביר כזה או אחר (הגם שכבודה של שאלה כזו במקומו מונח).
היתרונות תלויים בסוג התכנים
יש תכנים שמאוד קשה לייצג בצורה מתקבלת הדעת בבסיס נתונים טבלאי. קח למשל מאמר שמורכב מפסקאות ושיש בו מילים מודגשות|סגדש| אתה רוצה נגיד מידע שתוכנה תוכל לקרוא אודות אילו מילים הן מודגשות. כדי לעשות זאת בבסיס נתונים טבלאי, עליך לכתוב שורה בטבלה עבור כל מילה, לציין בכל שורה עמודה שמסמנת את מיקום המילה בפסקה, עמודה נוספת לאיזה פסקה המילה שייכת, ועמודה נוספת בוליאנית לציין אם המילה מודגשת או לא. ב-XML סדר הפסקאות והמילים נובע מהסדר שלהם במסמך, וניתן לסמן את ההדגשה בצורה ישירה וטבעית. ניתן לשלוף בקלות את כל הביטויים המוגשים מהפסקה השלישית באמצעות XSLT
יש תכנים שמאוד קשה לייצג בצורה מתקבלת הדעת בבסיס נתונים טבלאי. קח למשל מאמר שמורכב מפסקאות ושיש בו מילים מודגשות|סגדש| אתה רוצה נגיד מידע שתוכנה תוכל לקרוא אודות אילו מילים הן מודגשות. כדי לעשות זאת בבסיס נתונים טבלאי, עליך לכתוב שורה בטבלה עבור כל מילה, לציין בכל שורה עמודה שמסמנת את מיקום המילה בפסקה, עמודה נוספת לאיזה פסקה המילה שייכת, ועמודה נוספת בוליאנית לציין אם המילה מודגשת או לא. ב-XML סדר הפסקאות והמילים נובע מהסדר שלהם במסמך, וניתן לסמן את ההדגשה בצורה ישירה וטבעית. ניתן לשלוף בקלות את כל הביטויים המוגשים מהפסקה השלישית באמצעות XSLT
בדיוק! (וזוהי אכן הסיבה ש-XML הגיע)
לפני ש-XML הגיע למחוזותינו, זו היתה הדרך הפופולרית (והיחידה, למעשה)לשמור את התכנים ולנהלם - פירוק והרכבה, עם כל הבעייתיות של כך. XML הגיע וחלק מהמהפיכה שהוא הביא עימו היה - עבור תכנים יש להשתמש בתקן, המיועד ישירות לכך. תקנים, סטנדרטים ושלל טכנולוגיות לטיפול בתכנים.
לפני ש-XML הגיע למחוזותינו, זו היתה הדרך הפופולרית (והיחידה, למעשה)לשמור את התכנים ולנהלם - פירוק והרכבה, עם כל הבעייתיות של כך. XML הגיע וחלק מהמהפיכה שהוא הביא עימו היה - עבור תכנים יש להשתמש בתקן, המיועד ישירות לכך. תקנים, סטנדרטים ושלל טכנולוגיות לטיפול בתכנים.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.