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

מקורות:
http://stackoverflow.com/questions/15051869/relationship-of-primary-key-and-clustered-index
https://en.wikipedia.org/wiki/Unique_key
https://docs.microsoft.com/en-us/sql/relational-databases/indexes/heaps-tables-without-clustered-indexes
https://www.mssqltips.com/sqlservertip/1254/clustered-tables-vs-heap-tables/
http://dba.stackexchange.com/questions/28370/what-are-valid-usage-scenarios-for-heap-tables

עברית
http://www.ildba.co.il/indexes-in-sql-server/
http://blogs.microsoft.co.il/gerireshef/2010/11/29/אינדקסים-וספריית-אוניברסיטת-חיפה/
http://blogs.microsoft.co.il/gerireshef/2014/03/20/lookup-לטבלה-heapclustered-index/

פורסם במקור בפורום CODE613 ב26/03/2017 09:05 (+03:00)

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

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

פורסם במקור בפורום CODE613 ב24/03/2017 15:35 (+03:00)

יעלה תזרקו עגבניות.

פורסם במקור בפורום CODE613 ב24/03/2017 15:29 (+03:00)

@רחמים

לא מדברים על clustered index אלא על primary key

בשם כל המתפרצים, עמך הסליחה.

אי הבנה קטנה, לא נורא, קורה

פורסם במקור בפורום CODE613 ב24/03/2017 15:03 (+03:00)

לא מדברים על clustered index אלא על primary key

בשם כל המתפרצים, עמך הסליחה.

פורסם במקור בפורום CODE613 ב24/03/2017 14:38 (+03:00)

מפתח ראשי זה אינדקס. לכל דבר, ושמו clustered index. ועל זה הנושא מתחילת האשכול, ותסלח לי שאני קובע שאתה ממש לא יודע מספיק במסד נתונים וממילא זה די חמור שאתה חולק וקובע כבקיא ורגיל. היית כול לכתוב מה שכתבת עם "שמא" ו"נראה לי" זה היה יותר נורמלי.
אתה חושב שכשקובעים מפתח ראשי זה עניין למשתמש - ואין לזה קשר לעבודה מאחורי הקלעים והבאת ראיות לכך. נתחיל מתחילה:

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

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

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

דוד, גם אתה מתפרץ לדלת פתוחה, כשאני אומר מפתח ראשי אני לא מתכוון לאינדקס שמאחורי הקלעים, וגם פותח האשכול לא דיבר על האינדקס הזה, פותח האשכול דיבר על עמודה בטבלה, עמודת המפתח הראשי, לא על אינדקס. לא מדברים על clustered index אלא על primary key.
כל מה שאמרתי לא דיברתי על האינדקס אלא על העמודה. וכל מה שאמרתי נכון בהחלט על העמודה. יכול להיות שמה שארכיטקט אמר נכון בהקשר לאינדקס, אבל הוא הזכיר את המילים 'מפתח ראשי' ולא אמר אינדקס.
גם מערך בויקיפדיה שקישרתי אליו לעיל עולה בברור שמפתח ראשי הכוונה לעמודה ולא לאינדקס כל שהוא.

פורסם במקור בפורום CODE613 ב24/03/2017 14:28 (+03:00)

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

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

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

פורסם במקור בפורום CODE613 ב24/03/2017 14:15 (+03:00)

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

כדאי שתלמד דבר או שניים אודות אינדקסים לפני שאתה קובע קביעות.
@רחמים

חוץ מזה שמפתח ראשי הרבה פעמים הוא GUID.

מה זה קשור לנושא????

@רחמים

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

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

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

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

פורסם במקור בפורום CODE613 ב24/03/2017 13:08 (+03:00)

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

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

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

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

פורסם במקור בפורום CODE613 ב24/03/2017 13:05 (+03:00)

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

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

פורסם במקור בפורום CODE613 ב24/03/2017 12:55 (+03:00)

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

כדאי שתלמד דבר או שניים אודות אינדקסים לפני שאתה קובע קביעות.
@רחמים

חוץ מזה שמפתח ראשי הרבה פעמים הוא GUID.

מה זה קשור לנושא????

@רחמים

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

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

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

פורסם במקור בפורום CODE613 ב24/03/2017 12:49 (+03:00)

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

אני חושב שאתה צודק רק באקסס. בSQLSERVER אני לא חושב ככה - למה שלא יהיה רצף רשומות כמו שורות בקובץ דטה?

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

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

פורסם במקור בפורום CODE613 ב24/03/2017 08:55 (+03:00)

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

אני חושב שאתה צודק רק באקסס. בSQLSERVER אני לא חושב ככה - למה שלא יהיה רצף רשומות כמו שורות בקובץ דטה?

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

פורסם במקור בפורום CODE613 ב22/03/2017 10:37 (+02:00)

@דוד ל.ט.
הבנתי שזה קשור למנגנון איך שEF עוקב אחרי הרשומות אבל לא הבנתי למה א"א שהמנגנון לא יעבוד בטבלה הזו וזהו.

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

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

פורסם במקור בפורום CODE613 ב22/03/2017 09:59 (+02:00)

הבנתי שזה קשור למנגנון איך שEF עוקב אחרי הרשומות אבל לא הבנתי למה א"א שהמנגנון לא יעבוד בטבלה הזו וזהו.

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

פורסם במקור בפורום CODE613 ב22/03/2017 08:13 (+02:00)

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

אני חושב שאתה צודק רק באקסס. בSQLSERVER אני לא חושב ככה - למה שלא יהיה רצף רשומות כמו שורות בקובץ דטה?

פורסם במקור בפורום CODE613 ב22/03/2017 03:03 (+02:00)

פורסם במקור בפורום CODE613 ב21/03/2017 16:28 (+02:00)

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

מה פתאום? EF תומך במפתח ראשי שמשתרע על כמה עמודות (Composite keys).
השאלה שלך היה למה בכלל צריך מפתח ראשי, ואני מצטרף לשאלה. הבנתי שזה קשור למנגנון איך שEF עוקב אחרי הרשומות אבל לא הבנתי למה א"א שהמנגנון לא יעבוד בטבלה הזו וזהו.
אכן יש גם המלצה שהמפתח יהיה אישי לטבלה - שכל שורה בה תהיה ישות משלה (ולא צרוף של מפתחות זרים): http://softwareengineering.stackexchange.com/a/45152/112215 לא היה לי כח להבין למה.
אני גם שמעתי בעבר המלצה תמיד שהמתח ראשי יהיה identity כלומר מס' אוטומטי ואני מבין שזה קשור לבעיות של הצבת הערך בו זמנית וכודמה, ולא בגלל שיקולים עמוקי הבנה אבל אולי אני טועה.

פורסם במקור בפורום CODE613 ב21/03/2017 13:54 (+02:00)

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

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

לא רואה פה תשובה.

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

פורסם במקור בפורום CODE613 ב21/03/2017 13:23 (+02:00)

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

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

פורסם במקור בפורום CODE613 ב21/03/2017 11:59 (+02:00)

פורסם במקור בפורום CODE613 ב21/03/2017 07:44 (+02:00)