שלח תשובה

זירת השאלות

262
צפיות
80
תשובות

דיון- איך בונים מערכת ניהול לאתר

,‏ 14 באפריל, 2004

לאחר זמן ממושך חזרנו עם דיון חדש:
איך בונים מערכת ניהול לאתר (מבחינה תיאורטית, ולא קוד).


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


האפשרויות שצריכות להיות לכל כתבה הם:
כותרת
טקסט בקצרה
הכתבה עצמה
תאריך (יתווסף אוטומטי)
שעה (יתווסף אוטומטי)
שם הכתב (יתווסף אוטומטי)

*הכתבות יתפרסמו לפי סדר כרונולוגי מבחינת התאריך והשעה, כאשר הכתבה החדשה ביותר תוצג ראשונה.


המערכת תגובות תכלול:
כותרת התגובה
תאריך (יתווסף אוטומטי)
שעה (יתווסף אוטומטי)
שם המגיב
מספר תגובה



הדרישות מכם:
תכנון המסד נתונים. יש להציג בכל טבלה את השדות, ואת הקשר בין השדות (לדוגמא: בין כתב למספר ID שלו).
תכנון ברמה תיאורטית של כל דף ודף: מה ייכלל בו, והצגה אלגוריתמית בכלליות של כל דף.

תגיות:

80 תשובות

  1. ניר טייב הגיב:

    באיזה מבנה אתם רוצים את התגובות
    עץ (רקורסיבי) או DC (הכל במכה)???

  2. כמה שאלות
    למה זה בדיוק מיועד?
    באיזו שפה?

  3. MCG הגיב:

    לדעתי…….
    זה יכול להתאים לXML PHP ASP SQL…

  4. אוריקס הגיב:

    התגובות הם כמו כמקובל
    כלומר "הכל במכה"…

  5. אוריקס הגיב:

    בכל שפה שהיא.
    וניתן, כמובן, להיעזר בכלים הנתמכים ע"י כל שפה כמו XML, בסיסי נתונים[כמובן] וכו’…

  6. ניר טייב הגיב:

    ועוד שאלה קטנה
    "הכל במכה" אפשרי כמו באתר של ראש 1 וכמו בוואלה(למשל)
    אץ שניהם אתם מקבלים ?

  7. ניר טייב הגיב:

    טוב אני מתחיל-מסד נתונים
    את האחרים אני אשלים אחר כך )
    אז ככה יהיו הטבלאות שלנו :
    טבלת article
    ID (מספור אוטומטי ומפתח ראשי)
    subject (נסוג טקסט עד 15 תווים required)
    theArticle (מסוג תזכיר required)
    dateHour (מסוג תאריך/שעה)
    eID (ה-ID של כותב ההודעה)(editor id)(מספר required)

    טבלת reply
    ID (ה-ID של התגובה)(מספור אוטמטי מפתח ראשי)
    rID (ה-ID של כותב התגובה)(reply Id)(מספר required)
    dhDate (תאריך/שעה)
    subject (טקסט עד 15 תווים required)
    Mreply (תזכיר עד 400 תווים)

    טבלת members
    userName (טקסט עד 15 תווים required אינדקס ללא העתקות)
    password (טקסט, 15 תווים, required)
    id (מספור אוטומטי מפתח ראשי)
    level (טקסט, validation rule: חייב להיות אחד משלושת הבאים:"רגיל","כתב רגיל","עורך" , required)

    קשרי גומלין
    קשר יחיד לרבים בין members(יחיד) ובין reply(רבים) הקשר מתבסס על rID
    קשר יחיד לרבים בין members(יחיד) לבין article (רבים) הקשר מתבסס על eID
    ובעצם כאן נוצר לנו קשר רבים לרבים בין reply ל-article

  8. אוריקס הגיב:

    שים לב שאתה שומר את אותם הנתונים
    עבור עורך ועבור משתמש רגיל.

  9. ניר טייב הגיב:

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

    בכל מקרה הכל עניין של תצוגה וסוג השליפה

  10. אוריקס הגיב:

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

  11. אם הבנתי נכון..
    אתה מתכוון שצריך לעשות לכל עממד בפורום (רגיל, כתב ועורך) טבלה משלו?

  12. אוריקס הגיב:

    לאו דווקא
    אבל הייתי הולך יותר בכוון של להפריד מנהלים ממשתמשים.

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

  13. אוריקס הגיב:

    הערה חשובה
    בסיס נתונים הוא לא הכל… חשוב לפרט באילו כילים הייתם משתמשים – משתני אפליקציה, סשנים וכו’…

    בנוסף חשוב להגדיר Views, Stored Procedures, פונקציות מרכזיות…

    כדאי גם להתייחס לנושא האבטחה.

  14. ניר טייב הגיב:

    בקשר לקטגוריות
    אפשר אז להוסיף את זה מהתחלה ואז להציג רק את הקטגורייה הראשונה.
    ואז עושים טבלת הראשות/רמות שבהם נשים רק את הנתונים החשובים כמו למשל : memberId, catId ו-level (הרמה) ובטבלה זו אנו נכניס רק את היוזרים שאנו רוצים לתת להם רמה מסוימת כמו למשל "כתב רגיל" ו"עורך" משתמשים רגילים (הקוראים) לא ייכנסו לטבלה זו הם ישארו רק ב-members

    ולגבי הפרטים :
    תן דוגמא לפרטים שצריך לדעת על המנהל שלא חייב לדעת על המשתמש?

  15. ניר טייב הגיב:

    אני ידוע פשוט מתחילים מהמסד
    ולבסוף עוברים ל-ASP אחרי הכל חלק גדול מאוד מהאפליקציה תלוי מאוד ב-DB שלנו לכן התחלתי ממנו כשלב ראשון

  16. אוריקס הגיב:

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

  17. ניר טייב הגיב:

    לפי איך שאני תיארתי את המסד
    הוא דיי דומה לפורום שלי(חוץ מהפרדת המאמרים מהתגובות) אבל בכל מקרה זה לא

  18. ניר טייב הגיב:

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

  19. ניר טייב הגיב:

    ואיזה פיתוחים עתידיים יכולים להיכנס
    לתוך מערכת חדשות?

  20. אוריקס הגיב:

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

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

  21. ניר טייב הגיב:

    עוד משהו לגבי הקטגוריות…
    כך תיראה טבלת הקטגוריות:
    catId – (מספור אוטומטי מפתח ראשי)
    catParentId (מספר)(0-קטגורייה ראשית, אחר-קטגוריית בן)
    manId – (מספר) (ה-ID של מנהל הקטגורייה)
    catName – (טקסט required)
    catDesc – (טקסט -250 תווים)(תיאור הקטגורייה)

    ועכשיו שחושבים על זה אתה צודק צריך להפריד בין טבלת היוזרים לטבלת המנהלים… אבל המנהלים חייבים להופיע בטבלת היוזרים.
    וכך תיראה טבלת המנהלים :
    manId – (מספור אוטומטי מפתח ראשי)(ה-ID של המנהל)
    userId – (מספר required)(ה-ID של המנהל בטבלת היוזרים)
    manager details … (כמו טלפון ומה שאוריקס פירט קודם)

    טבלת levels (רמת המשתמשים)
    catId – (מספר)(ה-ID של הקטגורייה)
    userId – (מספר)(ה-ID של המשתמש)
    level – (טקסט, תנאי הכנסה: in();) (הרמה בטקסט של המשתמש)

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

  22. ניר טייב הגיב:

    הא כן
    אני לא יודע SP אז אל תסמכו עלי בנושא זה

  23. אוריקס הגיב:

    לא התבלבלתי.
    נגיד ואתה מוסיף פורומים? נגיד ואתה מוסיף צ’אט?
    הטבלה הזאת כבר לא תוכל לשרת אותך…

  24. ניר טייב הגיב:

    sp=stored procedures
    ואם אני לא טועה אלו מעין פונקציות אשר לבסוף נרשמות כשאילתות SQL
    SP מונע טיולים בין טבלאות (אם אני לא טועה יש על זה משהו ב-FAQ — כשאני שאלתי משהו דומה)

  25. קודם אמרת לא שלא מדובר בפורום
    עכשיו אתה אומר שיהיו מנהלי פורומים
    אני לא מבין, כולל פורומים או לא??

  26. ניר טייב הגיב:

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

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

  28. ניר טייב הגיב:

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

  29. אוריקס הגיב:

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

  30. ניר טייב הגיב:

    ממחר אני אתחיל לסכם את הדיון…
    ובכך יהיה לנו מאמר על זה עם DB מושלם ומערכת פנטסטית…

  31. ניר טייב הגיב:

    אז הגענו להסכמה בנושא ה-DB ?
    טבלת article
    ID – מספור אוטומטי
    subject – טקסט
    article – תזכיר
    dateHour – תאריך/שעה
    eId – מספר (editor id)

    טבלת reply
    ID – מספור אוטומטי
    rID – מספר (ה-ID של המגיב)
    aId – מספר (ה-ID של המאמר)
    dateHour – תאריך-שעה
    subject – נושא התגובה_טקסט
    Mreply – התגובה_תזכיר

    טבלת membersID – מספור אוטומטי (מפתח ראשי)
    userName – טקסט (20 תווים)
    password – טקסט (10 תווים)
    eMail – טקסט

    טבלת managers
    manId – מספור אוטומטי (מפתח ראשי)
    userId – מספר (ה-ID של המתמש בטבלת members)
    phone – טקסט (הכולל מסכת קלט)
    CellPhone – טקסט (הכולל מסכת קלט)

    טבלת levels
    catId – מספר (ה-ID של הקטגוריה)
    userId – מספר (ה-ID של היוזר בטבלת members)
    level – טקסט (ואפשר גם מספר)

    טבלת cat
    catId – מספור אוטומטי (מפתח ראשי)
    catParentId – מספר (ה-ID של קטגוריית האב)
    manId – מספר (ה-ID של מנהל הקטגורייה)
    catName – טקסט
    catDesc – תזכיר

    קשרי גומלין בקובץ המצורף

  32. אוריקס הגיב:

    שתי שאלות
    1. לא הבנתי למה משמשת הטבלה Levels.
    2. מה קורה אם אותו אחד הוא מנהל של כמה קטגוריות?

  33. ניר טייב הגיב:

    levels משמשת
    לקביעת הרמה של המשתמש המסוים: "כתב רגיל" או "עורך" (במקרה שלנו)

    מצאתי עכשיו באג קטן :
    אם יש כמה מנהלים לאותה קטגוריה אז אי אפשר לקבוע לכן בטבלת cat אפשר להוריד את העמודה manID ובמקום זה מגדירים מנהל גם בטבלת levels וכך אנו יכולים להגדיר מנהל, עורך וכתב רגיל.

  34. אוריקס הגיב:

    לא טוב
    אמרנו שלא שומרים את אותם הפרטים עבור מנהל ומשתמש.

  35. ניר טייב הגיב:

    שים לב |לב|
    הפרטים הבסיסיים של המנהלים נשמרים בטבלת היוזרים (members) ופרטים נוספים על הנהלים נשמרים בטבלה אחרת והמקשר ביניהם זה ה-userId

  36. ניר טייב הגיב:

    אני בעונש של עבודות שירות לאתר
    סתם איזה עונש אני עושה הכל בהתנדבות וברוח טובה

  37. אוריקס הגיב:

    זה לא הכי חכם… תפריד בין שתי
    הטבלאות

  38. ניר טייב הגיב:

    שכחתי את מילת הקסם… (חחח )
    בבקשהההה

  39. אוריקס הגיב:

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

  40. ניר טייב הגיב:

    הבנתי אותך…. אתה יכול
    בבקשה להראות איך הטבלאות של היוזרים והמנהלים וטבלת levels (אם צריך אותה) יראו ?

  41. אוריקס הגיב:

    מצטער על העיכוב,
    מקווה להספיק מחר [היה לי יום עמוס ]

  42. אוריקס הגיב:

    אוקיי, הייתי חייב לך תשובה
    ככה:
    *קודם כל אנחנו חייבים להפריד בין טבלת המנהלים למשתמשים.
    *ה UserID בטבלת Levels יהיה מקושר לשדה manID בטבלה המנהלים.
    *השדה manID בטבלה cat יורד [אם אמרנו שיכולים להיות לנו כמה מנהלים לאותה קטגוריה, ואפילו פיצלנו טבלאות, אז זה לא הכרחי ].

    חוצמזה, לא ברור לי מה השדה eId בטבלה arcticles מציין ולמה הוא קיים [שים לב שזה גם נותן לך קשר לא ברור, מצב מאד מאד לא רצוי ].

    עוד מה שלא ברור לי זה למה השדה rid בטבלה reply משמש.

    תורך

  43. ניר טייב הגיב:

    my Turn
    eID – ה-ID של עורך המאמר (בתחילת השרשור זה היה כתוב editorId)
    rId – ה-ID של המגיב למאמר (בקשרי גומלין עם טבלת היוזרים או המנהלים בהתאם)

  44. אוריקס הגיב:

    אוקיי,
    אז עכשיו תורך להעלות תמונה עם הדיבי החדש, כולל ההערות שלי…

    וה eid צריך להיות מקושר ל manID [כי אמרנו שמפרידים מנהלים ממשתמשים רגילים].

  45. ניר טייב הגיב:

    אבל בו נגיד…
    מנהל, עורך וכתבים חייבים להיות קודם כל יוזרים במערכת לפני שהם עולים דרגות
    עכשיו כשאנחנו עושים שליפת תגובות איך נדע עם המשתמש שרשם את התגובות הוא מנהלת עורך או כתב רגיל? במקרה כזה רצוי לעשות שלמנהל יהיה ID בטבלת היוזרים ואז משתמשים ב-outer Join (או בשאילתא נפרדת ובדיקה על כל יוזר) כדי להוציא פרטים על המנהל/משתמש.

    אחרת מה אתה מציע לעשות ???

  46. ניר טייב הגיב:

    למה רק אני ואוריקס
    ובהתחלה גם תומר (mister master)
    משתתפים בדיום הוא פתוח לוכלם אז למה אתם לא משתתפים…
    צריך עוד חוות דעת של הגולשים האחרים וגם שלכם המנהלים של האתר (ילדה? שפוי ?)

  47. אוריקס הגיב:

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

    והם לא חייבים להיות יוזרים, תפריד – זו לא אותה יישות ולכן זו לא אותה הטבלה.

  48. ניר טייב הגיב:

    רק מהשרשור לא הבנתימשהו אחד…
    האם מנהל=עורך ?
    והאם משתמש רגיל = כתב רגיל ?

  49. אוריקס הגיב:

    משתמש זה יוזר
    שנרשם ומקבל שם וסיסמא…

    מנהל זה מנהל ואינו קשור לזה.

  50. ניר טייב הגיב:

    ואיך אני מבדיל בין עורכים לכתבים
    אחרי הכל כתב יכול להיות משתמש רגיל אבל עורך הוא משתמש יותר חזק…
    לכן לדעתי ב-level אנו עדיין מקשרים עם טבלת היוזרים כדי לתת רמה למשתמש מסוים בכל קטגורייה

  51. jonatan44 הגיב:

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

  52. ניר טייב הגיב:

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

  53. צר לי
    אני עמוסה מידי לאחרונה מכדי לשבת ולקרוא שרשורפלצת כזה :-/

  54. אוריקס הגיב:

    הקפצתי –
    הוא היה נעוץ מספיק. אם נצטרך – נקפיץ שוב.

  55. ניר טייב הגיב:

    טוב אוריקס… עדיין משהו אחד לא מוב
    לא מובן לי:

    איך מבדילים בין "עורך" ל"כתב רגיל" ליוזר שקורא?

  56. ניר טייב הגיב:

    לא נורא בקרוב מאוד
    אני אעלה את התמונה חדשה של ה-DB שאנו יוצרים… ואז תוכלי לעזור לנו

  57. jonatan44 הגיב:

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

  58. ניר טייב הגיב:

    המאמר ייכתב ע"י
    ואני אכתוב בו שזהו סיכום דיון שנערך בפורום

    הקטע הוא לתכנן את ה-DB ואת כל המערכת כמו שצריך שלא יהיו בה באגים ולא מערכת חדשות חובבנית (בלי התנשאות כמובן)

  59. ניר טייב הגיב:

    ה-DB החדש
    מצורף בגרסת HTM (פצצתית חחח)

  60. ניר טייב הגיב:

    *ASP = החלק הכתנותי
    מצטער זה מתוך הרגל

  61. אוריקס הגיב:

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

  62. ניר טייב הגיב:

    מצטער אני קשה הבנה…
    ההיררכיה שלנו הולכת כך:
    יוזר שקורא
    יוזר כתב
    יוזר עורך
    יוזר מנהל

    ליוזר מנהל יש טבלה משלו…
    אז איך אני מבדיל בין היוזר שקורא ליוזר שכותב ליוזר שעורך ?
    טבלת ההרשאות מדברת רק על מנהלי הקטגוריות…
    ה-DB שלנו לדעתי לא בנוי נכון…

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

    אנו צריכים לאחד את הטבלה של המנהלים עם טבלת היוזרים…

    ואוריקס לדעתי כשהפכת להיות מנהל הפורום לא ביקשו ממך טלפון ועוד פרטים ועוד פרטים אלא הפרטים שהכנסת בטופס ההרשמה מספיקים… גם איציק לא ביקש ממני עוד פרטים רק ביקש לראות עבודות מוכנות שלי כדי לבדוק את רמתי…

    אז מה אתה אומר עכשיו ?

שלח תשובה