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

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

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

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

טוב אני מתחיל-מסד נתונים
את האחרים אני אשלים אחר כך )
אז ככה יהיו הטבלאות שלנו :
טבלת 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

אא… מה אני אמור לעשות??

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

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

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

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

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

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

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

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

אתה בסדר
אין לי טענות

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

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

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

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

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

הוא התבלבל

מה זה SP??
(לא הפירוש, המשמעות)

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

טוב לא משנה..

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

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

אז הגענו להסכמה בנושא ה-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 – תזכיר

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

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

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

ניר אתה כתב כאן??

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

הסבר… אני רוצה להבין למה ?

אווו
תודה שאת משתתפת בדיון

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

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

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

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

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

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

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

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

תנעץ את השרשור שוב

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

>נעץ

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

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

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

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

וקשרי הגומלין

אנו מסכימים ואפשר לעבור לחלק ב-ASP?

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