עדכון קל 331919
כשתכנסו לעמוד ותקראו את כל התגובות בו, ולא רק את כל התגובות החדשות, תגלו שכל התגובות מסומנות כחדשות (התשובה לשאלה 12 עודכנה בהתאם). כמו כן, מידת ההזחה המקסימלית במקרים כאלה תקבע לפי ברירת המחדל ולא לפי הבחירה בהתאמה האישית שלכם.
עדכון קל 331934
מדוע ולמה, בעצם?
עדכון קל 331939
כדי שכל טעינה של סיפור מלא (לחיצה על "הסיפור המלא" מהעמוד הראשי, למשל) תתבסס, במידת האפשר, על cache (מטמון מבוסס-דיסק). מצד אחד זה חוסך, בקצב הנוכחי, כמה מאות אלפי שאילתות למסד הנתונים מדי שעה. מצד שני זה אומר שהעמוד יראה זהה לכולם (למעט skin שונה).
עדכון קל 331943
תודה.
עדכון קל 331945
בעצם זה מפתיע אותי: למה יש כל כך הרבה לחיצות על "הסיפור המלא"? בדרך כלל משתמשים בלינק הזה פעם אחת לכל מאמר.
עדכון קל 331983
נכון. אלפי משתמשים, כל אחד מהם פעם אחת לכל מאמר... אמנם לא תמיד כל בקשה כזו תעזר ב-cache – בפרט, אם היו תגובות נוספות מאז שנכתב ה-cache, הוא יימחק והדף יטען במלואו (וישמר ל-cache באותה הזדמנות, עבור הקורא הבא). אבל מסתבר שבכל זאת, זה עוזר. מאוד, אפילו.

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

(כהחלטה עקרונית, כל האתר חייב לעבוד גם מול דפדפנים ללא תמיכת JS).
מוזר... 380844
את כל הנתונים על המשתמש ששמורים בשרת, חוץ מזמני הביקורים במאמרים.

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

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

איזה דפדפנים לא תומכים בגאווהסקריפט?

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

- דפדפנים שכיבו בהם את התמיכה בJS
- דפדפנים טקסטואלים כגון lynx
מוזר... 380862
אבל אלה מקרים בודדים, לא?

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

לא מאוד יעיל? אולי. אבל נותן יחס אישי...
מוזר... 380902
אבל אתה בעצמך אמרת שביטול השאילתה על מידת ההזחה המקסימלית עוזר, ''מאוד, אפילו''. על זה הגבתי. בגלל זה, בקריאת המאמר המלא, אין התייחסות להעדפה האישית של כל משתמש. אם היית משתמש בקוקיות במקום לבצע את השאילתה הזאת היה אפשר לקרוא את ההעדפות האלו בלי להעמיס על השרת.
מוזר... 380917
פיספסת משהו. זו לא השאילתה על מידת ההזחה המקסימלית של המשתמש דרשה זמן רב. מה שדרש זמן רב הוא בניית הדף באופן אישי עבור המשתמש, עם ההזחה האישית שלו (וסימון התגובות החדשות עבורו). מדובר בעד אלפי שאילתות (הצגת כל התגובות בדיון), ועוד עשרות אלפי פעולות החלפה של ביטויים רגולריים (הטיפול בטקסט, למשל החלפת <דִיון 1> בדיון 1, וכו').

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

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

אבל כמה דברים שעכשיו לא מבינה:

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

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

(דרך אגב, אפשר לכתוב <דיון 1> אם מחליפים את הרווח ב-&nbsp;)
מוזר... 380931
> לא הבנתי. דרושה שאילתה אחת עבור כל הצגה של העמוד, לא?

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

> לא עדיף שהטיפול הזה יתבצע עם שמירת התגובה?

אולי. התקורה של ההחלפה היא, למעשה, מינימלית‏2. מצד שני, זה חוסך הסתבכות מיותרת ב-DB עם גרסה לכל תגובה בכל עיצוב (skin). ושוב, שיקולי זיכרון: הגדלת ה-DB באופן שכזה גם תפגע באפקטיביות של ה-query cache, כך שסביר ששכרנו יצא בהפסדנו.

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

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

(nbsp עשוי להפוך לרווח בעדכון עתידי של האתר. חיריק, לא סביר שיעלם).

-----
1 MySQL לא מעביר ל-PHP סמן (cursor) אלא בלוק עם התוצאה כולה. טיפול בכמה עשרות משתמשים בו-זמנית – לא נדיר, אחרי הכל יש כמה אתרים על אותו שרת, המריצים את אותה התוכנה – יוביל לגלישה מהירה מאוד לזיכרון וירטואלי (איטי).
2 בערך 1% מהביצועים הכוללים של השרת, לאחר שהדיונים המלאים עברו ל-cache. לא שווה את המאמץ.
(מזועזעת...) 381037
אבל אני איאלץ לקבל כל מה שאמרת כי אלה עניינים של sql שאין לך שליטה עליהם, ובטח אין לך כוח להתעסק עם זה או לבנות בעצמך מסד נתונים. מה שכן, אני עכשיו יודעת ביתר ביטחון ש-sql זה השטן.

אבל עוד כמה דברים שרציתי לשאול, מתוך סקרנות:

1. יש סטטיסטיקה של אחוז הכניסות של דפדפנים שלא תומכים בגאווהסקריפט?
2. האם הטיפול ב-cache של השרת (שמירה ועדכון) הוא אוטומטי או שיש לך שליטה עליו?
3. כמה מקום בדיסק תופס כל האתר?
(מזועזעת...) 381042
0. לגבי SQL - המסקנה שלי הפוכה (כלומר, לא שהוא המלאך גבריאל, אבל הוא גם לא השטן).
1. לא (בד"כ לא מדובר בדפדפנים לא תומכים אלא במשתמשי IE/FF שמכבים את התמיכה).
2. לא הבנתי. יש כמה דרגות cache שונות. זה של עמודים שלמים מנוהל לחלוטין ע"י התוכנה שלי; זה של MySQL הוא "אוטומטי" (כלומר לא בשליטתי) אבל יש דרכים שונות לקנפג אותו.
3. (לכל האתרים גם יחד - האייל, עין הדג ואחרים) מעל 10GB (ל-DB בלבד, לא כולל cache למשל).
(מזועזעת...) 381049
"(כלומר, לא שהוא המלאך גבריאל, אבל הוא גם לא השטן)".
עד כה לא הבנתי כלום מהדיון, אבל עכשיו אתם עוברים לתיאולוגיה?
(מזועזעת...) 381559
אם *זה* נראה לך מוזר, מה תגיד על זה שכשטל כתב (תגובה 380931) "טיפול בכמה עשרות משתמשים בו-זמנית [...] יוביל לגלישה מהירה מאוד לזיכרון וירטואלי (איטי)", פירוש הדבר שזה יוביל לגלישה *איטית* מאוד?
(מזועזעת...) 381565
אה, זה בסדר - את שני המובנים האלה של ''גלישה'' אני מבינה...
הבעיה של היא עם מלים אחרות.
(מזועזעת...) 381057
10GB? פעם זה היה הרבה פחות... (אני זוכר תגובה שלך שבה ציינת פחות מ-‏100MB, <דמיין קישור כאן>). איך זה צמח כל כך הרבה?
תמונה>1000 מילים 381062
כל המאמרים עם צילומים של יצירות ארכיטקטוניות :)
(מזועזעת...) 381066
בלי להזכיר שמות (הם כבר יזכירו את עצמם), התגובות של אחדים מאיתנו עוברות סינגל קיבורדד את ה-‏100MB.
(מזועזעת...) 381149
מעניין אם יש מקום שבו קיימים הנתונים הללו, באמת.
(מזועזעת...) 381154
שכ''ג מחזיק את הנתונים האלה אצלו, במרתף של החשמנית.
(מזועזעת...) 381089
שינוי מבנה ה-DB (לא מבנה הטבלאות אלא סוג ה-DB, מבין הסוגים ש-MySQL תומך בהם), והוספת אינדקס מילים לחיפוש.
(מזועזעת...) 381166
"מאמרים: כ- 5.5MB, תגובות (לא כולל כאלה שהוסרו): כ- 74MB. המספרים מתייחסים לגוף הטקסט בלבד (לא כולל כותרות, שמות הכותבים, ומטא-מידע)."

תגובה 190500
(מזועזעת...) 381407
אה. לפי שיטת המדידה הזו, מאמרים: 7MB, תגובות (לא כולל מוסרות): כ-‏133MB. או במילים אחרות, המערכת הורידה קצב, הציבור הרחב דווקא לא. מפתיע מישהו?
(מזועזעת...) 381605
אחת ולתמיד: כמה מהמגה בייטים הללו תרם מופע האימים של דורון שדמי?
(מזועזעת...) 381614
עם הציור או בלי?
rx1תודה... 381385
אבל שאילתה לכל תגובה במקום שאילתה לכל צפייה זה מבחינתי זוועה שלא תעלה על הדעת.

שאלה אחרונה:
מאיזו סיבה מכבים את התמיכה בגאווהסקריפט?
rx1תודה... 381405
לא לכל תגובה, לכל דרגת עומק בעץ, או משהו. למה זוועה? כמות המידע שעובר כך מ-MySQL לתוכנה הוא קטן יותר מאשר בשאילתה אחת גדולה. הזמן שנדרש ע"י השרת לשם ביצוע parsing לשאילתה, וכו' הוא בטל ב-‏6,000. יוצא ששרת ה-SQL עושה עבורי את עבודת המיון והסינון שאחרת הייתי עושה בעצמי, ו(סביר להניח) שבביצועים טובים יותר ממה שאני הייתי משיג (ולו משום השרת כתוב ב-C, הקוד שלי ב-PHP לא מקומפל).

אני אישית עובד עם FireFox, ומשתמש ב-plugin שנקרא NoScript. כך, JavaScript (וגם Flash) כבוי כברירת מחדל, אבל אני יכול להחליט להפעיל אותו פר-אתר, או רק באופן זמני לאתר מסוים. התוצאה: גלישה ללא אנימציות מציקות, ללא פרסומות קופצות, ללא יכולת לאתר לרמות אותי ולהציג בשורת הסטטוס יעד קישור השונה מהיעד האמיתי, וכו'. אם באתר מסוים אני זקוק ל-JS, אני יכול להפעילו בלחיצה זריזה – רק להפעם, או באופן קבוע לאתר זה. מאוד, מאוד נוח.

אני מניח שלגולשים אחרים יש שיקולים נוספים.
rx1תודה... 381535
סליחה על הקטנוניות המתמשכת, אבל:

"ולו משום השרת כתוב ב-C, הקוד שלי ב-PHP לא מקומפל"

גם עכשיו הקוד שלך לא מקומפל, לא?
הרי כל הפונקציות ב-php כתובות בסופו של דבר ב-c, לא רק של mysql. אז מה ההבדל בעצם, מהבחינה הזאת, בין תוכנית שמשתמשת ב-sql לתוכנית שמשתמשת, נגיד, במערכת נתונים מבוססת-קבצים?
rx1תודה... 381566
אני מעביר ל-MySQL בקשה. MySQL, בשל מבני הנתונים שלו (כגון אינקסים תומכים) מסוגל לבצע את החיפוש (כולל ה-parsing של הבקשה עצמה, מחרוזת SQL) מהר בהרבה מכפי שיכולתי אני לעשות זאת ב-PHP. מכמה סיבות - שפת התכנות, מומחיות כותבי הקוד בתחום, וכו'. גם אם יכולתי לעשות זאת ב-PHP ולהגיע לאותם ביצועים (ספק), או לביצועים טובים יותר (פנטזיה), המאמץ הנדרש היה כה רב שקשה להצדיק זאת.
rx1תודה... 381595
לדעתי אתה טועה - האלגוריתמים שמתבצעים במסד נתונים כמו באתר הזה הם פשוטים להפליא וקל מאוד להביא אותם לייעול מקסימלי, דבר ששום מסד נתונים מוכן לא יוכל להגיע אליו. זה גם הרבה יותר... מספק, כזה.

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

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

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

כדאי לקחת בחשבון שגם בפרוייקטים גדולים בהרבה, שם לביצועים משמעות גדולה בהרבה, עדיין משתמשים ב-SQL. כדאי לך לשאול את עצמך למה. [ההערה שלך על טעינת פונקציות לא הכרחיות מעידה על חוסר בקיאות מסוים באופן הפעולה של מערכות תוכנה גדולות בימינו. קוד נטען on-demand על-ידי מיפוי של קובץ ה-executable ל-page file של המערכת; אף פונקציה לא נטענת לפני שמשתמשים בה (עד כדי טעות בגודל דף, כלומר אולי הפונקציה נטענה במקרה כי היינו זקוקים לפונצקיה אחרת ששכנה באותם 4KB).]

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

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

מה הסיבוך שאתה רואה בתכנון כזה? האלגוריתמים החשובים היחידים הם חיפוש בתוך קובץ ושינוי של קובץ, עם תוספות של שמירה ב-cache וכו'.

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

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

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

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

"[ההערה שלך על טעינת פונקציות לא הכרחיות מעידה על חוסר בקיאות מסוים באופן הפעולה של מערכות תוכנה גדולות בימינו. קוד נטען on-demand על-ידי מיפוי של קובץ ה-executable ל-page file של המערכת; אף פונקציה לא נטענת לפני שמשתמשים בה (עד כדי טעות בגודל דף, כלומר אולי הפונקציה נטענה במקרה כי היינו זקוקים לפונצקיה אחרת ששכנה באותם 4KB).]"

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

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

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

חזרה לעמוד הראשי המאמר המלא

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