מקום טוב להתחיל בו הוא הורדה של הגרסה העדכנית של דרופל בעברית.
להורדת דרופל בעבריתלשפות וגרסאות אחרות, Drupal.org
יש לנו באתר מדריכים שונים, הכוללים מדריך להתקנת דרופל על המחשב המקומי או על שרת אירוח באינטרנט, כמו גם מדריכים לעיצוב ופיתוח.
בעזרת המדריכים השונים באתר ובעזרת קבוצות הדיון שלנו, אפשר למצוא את כל המידע הנחוץ להקמה והתאמה אישית של אתרי דרופל. כדאי לבדוק גם את ערוצי התמיכה הנוספים שלנו
שלום לך. הרכיב Node reference
שלום לך.
הרכיב Node reference field נועד לחיבור בין פריטי תוכן ברמת התצוגה והוא אינו מהווה קישור במסד הנתונים.
בדרופל בחרו שקשר בין הטבלאות באופן לוגי בלבד, ללא חיבור פיזי ביניהן. כלומר, הקשרים בין הטבלאות הן לוגיים וההתייחסות לקשרים וההסתמכות עליהם מבוצעים ברמת הקוד - רכיבים קיימים או רכיבים שייבנו על ידך.
הדאגה למהירות ברמת מסד הנתונים אינה ברורה לי, אלא אם יש לך מערכת לא מנורמלת. רצוי שתנרמל אותה באופן מיטבי, כולל דה-נורמליזציה במקומות שצריך. מה שחשוב זה הלוגיקה שבין הטבלאות - יחס ישויות תקינים. אם זה יהיה בסדר, הדאגה שלך בקשר לביצועים תעבור, באופן בריא, לרמת התעבורה, רמת הקוד ואופן רנדור התצוגה.
אמיר
| פרקטיקול - בונים לך אתר דרופל | קורס דרופל! | עזרה מידית בקבוצה שלנו בפייסבוק! | מכללת קוד פתוח
היי אמיר, תודה על תושבתך
היי אמיר,
תודה על תושבתך המהירה :)
מה הכוונה למערכת לא מנורמלת ואיך אני יכול לדאוג שהיא תהייה כזו?
הדאגה למהירות ברמת מסד הנתונים היא בחשיבה קדימה כשיהיו לי מאות אלפי רשומות...האם דורפל תדע להתמודד עם זה בצורה יעילה ולהציג מידע בזמן סביר?
יש בכלל הבדל אם אני מאחד טבלאות מהתרשים לסוג תוכן אחד לעומת יצירה של סוג תוכן לכל טבלה מהתרשים?
לדוגמא: אם באחת הטבלאות בתרשים יש לי שדה של קוד מדינה שמקושר לטבלת מדינות, האם עדיף להגדיר את המדינות ב allowed values של סוג תוכן מסוים או ליצור סוג תוכן של מדינות שיקושר ברמת התצוגה לשדה הזה?
התכנון כרגע הוא להסתמך על מודולים קיימים ולא לבנות מודולים חדשים.
אחלק את תשובתי לפי 4 הנושאים
אחלק את תשובתי לפי 4 הנושאים שהעלית:
הדאגה למהירות ברמת מסד הנתונים היא בחשיבה קדימה כשיהיו לי מאות אלפי רשומות...האם דורפל תדע להתמודד עם זה בצורה יעילה ולהציג מידע בזמן סביר?
זה ברמת מסד הנתונים, לא ברמה הדרופלית. כלומר, אתה שולח שאילתא באמצעות דרופל, אבל שליפת הנתונים היא במסד. בסופו של דבר, אם אתה מציג X נתונים, זה לא משנה לדרופל אם שלפת אותם מתוך מאה רשומות או מיליון רשומות. כנ"ל לגבי הישות המחוברת באמצעות נוד-רפרנס.
יש בכלל הבדל אם אני מאחד טבלאות מהתרשים לסוג תוכן אחד לעומת יצירה של סוג תוכן לכל טבלה מהתרשים?
לדוגמא: אם באחת הטבלאות בתרשים יש לי שדה של קוד מדינה שמקושר לטבלת מדינות, האם עדיף להגדיר את המדינות ב allowed values של סוג תוכן מסוים או ליצור סוג תוכן של מדינות שיקושר ברמת התצוגה לשדה הזה?
לדעתי לא צריך להיות הבדל משמעותי, אבל אשמח לשמוע מה אומרים אחרים. בעיקרון, ליצור סוג תוכן פר מחלקה (טבלה המייצגת ישות במערכת) זה נכון, וחיבור עבור התצוגה באמצעות נוד-רפרנס נותן לך הכוח להשתמש בנתונים בראייה מונחית-עצמים.
מה הכוונה למערכת לא מנורמלת ואיך אני יכול לדאוג שהיא תהייה כזו?
קרא על זה באינטרנט. אם תרצה, צור תרשים של מסד הנתונים שלך באמצעות MySQL Workbench והעלה לכאן את הקובץ (סיומת mwb). זה יאפשר לראות את המערכת שלך באופן חזותי ואוכל לתת לך חוות דעת על רמת הנירמול שביצעת.
התכנון כרגע הוא להסתמך על מודולים קיימים ולא לבנות מודולים חדשים.
זה תמיד חכם ומועיל.
| פרקטיקול - בונים לך אתר דרופל | קורס דרופל! | עזרה מידית בקבוצה שלנו בפייסבוק! | מכללת קוד פתוח
הוספתי את תרשים מסד הנתונים
הוספתי את תרשים מסד הנתונים כקובץ jpg (מקווה שזה מספיק...אם לא אני אצור אותו ב MySQL Workbench). כמובן שטבלאות users ו comments נוצרות עם התקנת דרופל.
באופן כללי זה נראה מנורמל
באופן כללי זה נראה מנורמל באופן נכון.
שאלות:
1. עבור מה קיימת הטבלה רבים לרבים בשם UserDefaultAccounts?
2. הטבלה IsForward נראית כנירמול יתר. אני מניח שזה נעשה מתוך ידיעה מצדך שרוב הסוחרים לא יהיו מקודמים, ואז אתה לא מעוניין שיהיה סתם NULL ברוב הרשומות. אבל זה לא שדה כבד, אז נראה לי שניתן לוותר על הטבלה ולהוסיף את השדה בטבלת הסוחרים. הסתייגות: אם אתה צופה שדות נוספים בטבלה זו, אז דווקא יש לה מקום. אם אתה משאיר את הטבלה ואם לא, השם שלה לא נכון כי אינו מציין ישות - חשוב על משהו נכון, זה גם יעזור לך להבין מהותית את הצורך או אי הצורך בטבלה. דבר אחרון בקשר לטבלה זו, במקום לשאול "האם מקודם" בשם השדה (או בשם הטבלה), עדיף לשאול "איך מקודם" - זה יאפשר לך מספר סוגים של קידומים ללא הוספה של שדות בטבלה. אם סוחר יכול להיות מקודם ביותר מדרך אחת, השתמש בBIT-WISE, כלומר: 1, 2, 4, 8 וכולי.
3. עניין סמנטי - נסה למצוא מילה בודדת המגדירה CommissionGroup - אם קיים משהו כזה בעולם הדיון הרלוונטי.
4. לא הבנתי למה שייכת תיבת Comments
5. איך השתמשת בכלי של מיקרוסופט עבור מסד של מייאסקיואל?
אמיר
| פרקטיקול - בונים לך אתר דרופל | קורס דרופל! | עזרה מידית בקבוצה שלנו בפייסבוק! | מכללת קוד פתוח
היי אמיר, 1.הטבלה
היי אמיר,
1.הטבלה UserDefaultAccounts מתארת חשבון ברירת מחדל עבור כל משתמש (הכוונה לחשבון בנק).
2.אתה צודק לגבי IsForward . זו תוספת עתידית למערכת במטרה לתאר את סוג העסקאות מטבלת Trades. יש צורך להוסיף עוד שדות ובהחלט לשנות את השם.
3.CommissionGroup בא במטרה לסווג סוגי עמלות לפי קבוצות כדי שיהיה יותר קל בקוד לאתר את העמלה שמשולמת לפי פרטי העסקה.
4.טבלת Comments משמשת לכתיבת הערות (אם יש) לכל ערך שמוכנס לאחת הטבלאות (בעיקר ל trades ששם רוב הפעילות). הטבלה הזו כבר קיימת בהתקנת דרופל.
5.התרשים נוצר רק לצורך המחשת המערכת. הבנייה של הטבלאות תעשה דרך הממשק של דרופל כאשר כל טבלה היא למעשה סוג תוכן ב CCK . האם בכלל ניתן לבנות קודם את הטבלאות בMYSQL ואז לטעון אותן לדרופל??
נכתב על ידי lotsofun: האם
האם בכלל ניתן לבנות קודם את הטבלאות בMYSQL ואז לטעון אותן לדרופל??
אתה יכול לשלוט במסד הנתונים בלי קשר לדרופל. כמובן שזה לא מומלץ לגבי טבלאות דרופליות, בשביל זה יש ממשק ל-99% מהדברים.
יש לך אפשרות לבנות את הטבלאות ידנית או בסקריפט ישירות בבמסד.
הדרך הנכונה לעשות את זה דרופלית היא לבנות רכיב ייעודי, שבחלק ה-install שלו יוצר את הטבלאות. אבל לא חובה אם זה פרויקט חד-פעמי וייחודי.
| פרקטיקול - בונים לך אתר דרופל | קורס דרופל! | עזרה מידית בקבוצה שלנו בפייסבוק! | מכללת קוד פתוח
לא הבנתי איך אפשר לשלוט
לא הבנתי איך אפשר לשלוט בטבלאות אם אני יוצר את המערכת דרך הממשק של דרופל...
אני יודע שכדי ליצור מודול חדש חייבים ליצור גם טבלה במסד הנתונים כדי שדרופל תוכל לעבוד עם המודול החדש.
התכנון שלי כרגע זה ליצור סוג תוכן עבור כל טבלה בתרשים, לקשר ביניהם ע"י node ,reference להשתמש ב computed_field לצורך חישובים ולהציג דוחות בעזרת Views.
אלא אם כן יש דרך אחרת למימוש...
נתת לך כמה כיוונים... ואידך
נתת לך כמה כיוונים... ואידך זיל גמור!
תלמד על בניית רכיבים, יש קובץ install עבור כל רכיב שרץ בפעם הראשונה שמפעילים אותו ובונה טבלאות.
מקווה שעזרתי לך.
אמיר
| פרקטיקול - בונים לך אתר דרופל | קורס דרופל! | עזרה מידית בקבוצה שלנו בפייסבוק! | מכללת קוד פתוח
תודה על העזרה :)
תודה על העזרה :)
היי אמיר, שאלה נוספת
היי אמיר,
שאלה נוספת ואחרונה...
קראתי בסופ"ש ספר שלם על פיתוח רכיבים והחלטתי שהדבר הכי נכון לעשות זה לכתוב רכיב חדש עבור המערכת הנ"ל.
למדתי גם שדרופל יכולה לעבוד עם יותר ממסד נתונים אחד.
השאלה שלי היא כזו: האם כדאי ליצור את כל הטבלאות החדשות במסד נתונים חדש במקום בקיים? כלומר להפריד בין מסד הנתונים של דרופל למסד הנתונים של הרכיב החדש שבו ישבו בעצם הנתונים העיקריים של האתר?
נכתב על ידי lotsofun: האם
האם כדאי ליצור את כל הטבלאות החדשות במסד נתונים חדש במקום בקיים? כלומר להפריד בין מסד הנתונים של דרופל למסד הנתונים של הרכיב החדש שבו ישבו בעצם הנתונים העיקריים של האתר?
אני לא רואה איזה אינטרס יש לך לעשות דבר כזה.
כמו כן, לא בטוח שאתה צריך לבנות רכיבים, יש הרבה דברים שאפשר באמצעות בניית סוג תוכן עם שדות CCK + רפרנס לפריט תוכן אחר (מאותו הסוג או מסוג אחר).
| פרקטיקול - בונים לך אתר דרופל | קורס דרופל! | עזרה מידית בקבוצה שלנו בפייסבוק! | מכללת קוד פתוח
אם אתה עומד לבנות מערכת
אם אתה עומד לבנות מערכת מורכבת (להפקת דו"חות, לחיתוכים שונים וכו') שתכיל כמות רבה מאד של רשומות, המלצתי לך היא לבנות טבלאות שיכילו את המידע הרלוונטי לך, ויתממשקו לדרופל לטבלאות הבסיס (שימוש ב-User IDוכו' בצורה בסיסית). לא הייתי אומר זאת בכל מצב, כי כאמור פתרונות CCK אכן מאפשרים לך הוספת "עמודות" לישויות מסויימות בצורה "דרופלית" שנתמכים אחר כך ב--Viewsוכו', אבל פתרונות כאלו לא יתנו לך בעתיד את היכולת ל-Tuningעדין של הביצועים הדרושים לך.
לאחר שתבין היטב כיצד בונים מודולים, זו תהיה לדעתי הדרך הקלה והיעילה שלך להגיע מצד אחד ל-Back end חזק שיסתמך על הטבלאות והמודול שלך, ומצד שני ל-Front End שיסתמך על דרופל.
היי צחי, אני חושב ללכת על
היי צחי,
אני חושב ללכת על הפתרון של cck + node reference + taxonomy + views
לפי התרשים המצורף אני צריך ליצור רק 6 סוגי תוכן לטבלאות הבסיס: trades, instruments, dailycurrency, activities, accounts, commissions
לכל סוג תוכן שאני יוצר דרך הממשק של דרופל נוצרת טבלה עצמאית במסד הנתונים עם השדות הנחוצים.
טבלאות כמו users ו comments כבר קיימות בדרופל
את שאר הטבלאות המשמשות לתיאור סיווגים וקבוצות אפשר לבצע בעזרת taxonomy.
מה שכן אני צריך גם לבנות טופס מילוי יעודי לטבלת הtrades בצורה של גיליון אלקטרוני כמו ב excel שכולל חישובים בזמן אמת.
אשמח לדעת אם בכל זאת יש יתרון בבניית הטבלאות שלא דרך CCK והאם אני אוכל להשתמש ב view כדי להציג מידע מהטבלאות האלו.
כמו שאמרתי, על פניו ניתן לממש
כמו שאמרתי, על פניו ניתן לממש הכל "דרופלית" על ידי מה שכתבת. הדבר היחידי שצריך לקחת בחשבון הוא האם כל מה שאתה אמור לעשות עם המידע לאחר מכן יהיה ניתן לבצע על ידי views וכלי דרופל נוספים, כי במידה ותצטרך לכתוב מודולים שישתמשו בהעלאת nodes & taxonomies בצורה יזומה, זה יהיה מאד כבד. כל מה שאני אומר הוא בהסתייגות כי אינני מכיר את דרישות המערכת שלך מעבר לטבלאות (כתבת "מידע פיננסי", יתכן ומדובר בשליפות וחישובים מסובכים ...), וכמובן לא ניתן לבצע אנליזה "בהתכתבות", רק קח בחשבון את עניין הביצועים בעתיד.
אני מעדיף לעתים להיות "הילד הרע" ולכתוב דברים לבד, עם גישות לבסיסי נתונים באופן עצמאי כדי לשפר ביצועים ולא להפעיל קריאות פנימיות מרובות כדי להביא טקסונומי זה או אחר, אבל זה כבר עניין אישי :-).
מדובר על כ 2,000 רשומות
מדובר על כ 2,000 רשומות (nods) ביום בטבלה המרכזית שהיא trades
החישובים לא יותר מידי מסובכים... חישובי רווח והפסד, חישובי עמלות לפי עסקאות והצגת הנתונים במטבעות שונים.
האם יש איזו שהיא הגבלה לגודל מסד הנתונים של דרופל?
למסד הנתונים אין הגבלה ...
למסד הנתונים אין הגבלה ... כמו שאין לאף מסד נתונים בעיקרון (למחשב יש מגבלה, ליפח הדיסק יש מגבלה), מסדי נתונים גדולים מאד פשוט מנוהלים אחרת, אבל זה כבר לדיון אחר.
בעיקרון, 2000 רשומות ליום הן לא משהו גדול מדי, אבל אם אתה מתרגם את זה לדרופל ומייצר node לכל רשומה (trade) זה נראה לי מוגזם. ואז, יש מצב שאתה צריך פתרון אחר בתוך דרופל.
בנוסף לכך, במערכות פיננסיות אתה יכול לבצע אגרגציות ולשמור נתונים ישנים יותר בצורה אחרת, מתומצתת ויעילה יותר לשימוש. אני מבצע אגרגציות באתר מסחר אלקטרוני עבור נתונים מסויימים שיהיה לי קל יותר לשלוף בהמשך. אגב - גם אגרגציות אתה יכול לבצע על ידי שדות CCK.
לדעתי הדיון הזה ממצה את עצמו. כדאי לך להעזר במומחה בסיסי נתונים לפני שאתה הולך לעקם את כל ה-Designכדי לעבוד דרופלית, ולהכין מסמך דרישות שיתאר את כל מה שאתה צריך ליישם, כדי שתראה אם אתה עונה על כל הצרכים, ואיך אתה מתמודד עם כל scenario.