כל אחד והמרצה שמטיב לטעמו. אני ממנו לא הייתי מבין הרבה נראה לי :roll:
הנה להורדה מהדרופ שלי.
פורסם במקור בפורום CODE613 ב26/05/2014 11:32 (+03:00)
כל אחד והמרצה שמטיב לטעמו. אני ממנו לא הייתי מבין הרבה נראה לי :roll:
הנה להורדה מהדרופ שלי.
פורסם במקור בפורום CODE613 ב26/05/2014 11:32 (+03:00)
אין עלות ביצועים של שליפה כאשר משתמשים במאפיין is persisted.
במקרה כזה עדיין יש את פעם ראשונה פר שורה, ו... מקום. כי זה שומר את התוצאה כעמודה "רגילה".
פורסם במקור בפורום CODE613 ב22/05/2014 13:51 (+03:00)
אם גידול הרשימות משמעותי הפיתרון של ארכיטקט לא ישים. (גם אם המספר ההתחלתי הוא מליון והוא כותב מערכת גדולה הוא כבר נכנס לסיכון [במיוחד אם הטבלה הראשית שעליה הוא מדבר היא לא של אנשי קשר (שאין הרבה) אלא של מיילים לדוגמא - הוא לא יכול להגביל את עצמו למליון])
תראה, גידול רשומות הוא סיכון בכל טבלה עם מאפיין int ייחודי, רק שכאן הוא מגיע יותר מהר. הסיכון נמצא במידה שווה גם בדוגמתך, כל עוד הקונוורט שלך הוא לint. זה נכון שאפשר לעשות אותו לסטרינג כמו שכתבת:
לגבי הביזבוז עם סטרינג, אני רק רוצה להזכיר שסטרינג בהחלט יכול לשמש כמפתח ראשי על אף הבזבזנות שלו (ועל אף הרצון של כולנו להשתמש דווקא במספר אוטו') - לדוגמא: GUID, שממומש במקרים רבים כסטרינג + מפתח ראשי ולא כסוג uniqueidentifier.
אני התכוונתי על בזבוז מעבד וזיכרון ברגע החישוב, לא על זיכרון דיסק באחסון (זה בכלל עמודה מחושבת!!).
לגבי מקום בדיסק או ביצועי השוואה (כאינדקס, וכמפתח ראשי) אין הבדל כלל בין סטרינג למספר, בתנאי שהסטרינג אורך קבוע (לא varchar), ושההשוואה היא מול מספר של קנה מידה שווה (עם זה char(10) לדוגמה, אז כל char זה byte שלם, מה שאומר מספר ענק.
אגב אפשר להשתמש למקרה שלנו גם בטיפוס binary, לכאורה זה חוסך.
פורסם במקור בפורום CODE613 ב22/05/2014 11:50 (+03:00)
ClickOne יפה מאוד שהצלחת לרדת לסוף דעתו, למצוא דוגמה שצריך את זה!
ואיזה יופי הרעיון!!! לקח לי זמן להבין...
אבל, הרעיון הזה זה רק לספורט נכון
? כי לכאורה אין לרעיון הזה ייתרון על העצה הפשוטה של ארכיטקט. שים לב שגם הוספת עמודה פר טבלה (הורים ותורמים) ושעמודה מחושבת זה עמודה עם עלות מסויימת מבחינת ביצועים (במיוחד עם סטרינג!).
פורסם במקור בפורום CODE613 ב22/05/2014 09:45 (+03:00)
כמו שארכיטקט אמר - תוכל להגדיר את הערך ההתחלתי גדול במיוחד ואז תהיה בטוח בקידומת (בהנחה שגידול השורות לא רציני).
פורסם במקור בפורום CODE613 ב21/05/2014 11:13 (+03:00)
הנושא הזה נקרא DataBase Migration.
אני גם סבור כמו ארכיטקט שבמקרים פשוטים הכי קל זה לעשות לבד.
יש כל מיני כלים לכך, אבל השימוש בהם לא נראה לי פשוט. חפש בגוגל C# DB Auto migration.
אגב, בCodeFirst הבעיה הרבה יותר רצינית, כי זה מיועד בשביל כאלה שלא רוצים בכלל ליגוע במסד, ובאמת בגירסאות האחרונות יש כלי לזה, אני לא התנסיתי בו.
פורסם במקור בפורום CODE613 ב21/05/2014 11:12 (+03:00)
תודה רבה רבה!
נשמח לעדכונים וטיפים בנושא.
פורסם במקור בפורום CODE613 ב20/05/2014 13:32 (+03:00)
נו, מתגברים...
http://stackoverflow.com/a/11404731/1271037
http://stackoverflow.com/a/12652259/1271037
פורסם במקור בפורום CODE613 ב29/05/2014 16:18 (+03:00)
אי תלות בגורמים חיצוניים זה אלף בית של לכידות תוכנה, ומה שקשור להכנסת נתונים לדטה בייס, אילוצים, בדיקות, צריך להתבצע בדטה בייס.
אתה מדבר מהבחינה העקרונית, ואני מדבר על האמצעי הפרקטי ששמו טריגרים, שהוא אמצעי עם שימושיות נמוכה ב'שטח'.
יש עניין לעשות כמה שיותר עם הטריגרים וכו' בחברות הגדולות זו העבודה של הDBA.
זהו, שיש לי תחושה שונה לגמרי לגבי ה"טריגרים" (לאפוקי ה"וכו'") כשבאתי במגע כל שהוא עם DBA ברשת.
פורסם במקור בפורום CODE613 ב19/05/2014 15:33 (+03:00)
אני לא קונה את האילוץ שלך לעשות הכל ברמת הDB.
כל הקטע של הטריגרים, נדמה לי שהוא אמור להיות משהו שולי בDB, לא משהו שהמערכת נשענת עליו כמו המשקל ששמת עליהם.
אולי אני טועה, אבל ככה נראה לי.
פורסם במקור בפורום CODE613 ב19/05/2014 13:12 (+03:00)
הליסט שעשית היא מקור נתונים, ואנו מדברים על התנהגות של הפקד הויזואלי.
ללא קשר למה ואיך מקור הנתונים.
אכן טעיתי ובדוקמנטציה מופיע שזה משפיע גם על לחיצת מקש.
מופיע שם גם שכאשר מגדירים את המאפיין לחיובי יש להגדיר את הSelectionmode כשלילי.
בקשר להתנהגות גם במקרה שלא עשית שום מאפיין מסויים רק שמקור הנתונים זה ליסט אישית, נסה לעשות דמו קטן ולהעלות קוד + XAML רלוונטי.
פורסם במקור בפורום CODE613 ב19/05/2014 15:40 (+03:00)
מה זה נקרא שעשית ליסט לבד? טמפלט? כתבת בעצמך את מחלקה יורשת מListView?
העובדה שרווח בוחר ממש לא קשורה. אין סיבה שהוא לא יבחר כל עוד הSelectionMode לא מוגד כNone. המאפיין מדבר רק על קליק עכבר.
בנוסף תרחיב מה אתה רוצה (כלומר, שורה תחתונה) כך שאבין אותך יותר.
פורסם במקור בפורום CODE613 ב19/05/2014 14:18 (+03:00)
פשוט מאוד, כשאתה לוחץ על אייטם, בברירת מחדל מופעלת לוגיקה של הפקד לבחור את האייטם.
המאפיין הנ"ל אומר: "אל תבחר. תלחץ! תעורר אירוע לחיצה וזהו. אני כבר אסתדר עם הבחירה".
פורסם במקור בפורום CODE613 ב19/05/2014 13:21 (+03:00)
הרעיון היחיד שאני שומע כאן זה להשתמש בתוכנה נפרדת לשליחה, והיא עצמה תפעל ללא טרידים כלל (קצת חבל כי זה ייקח לה הרבה זמן).
לא כ"כ הבנתי את הנקודה של המופעים.
הנקודה האם התוכנה תהיה סרביס או תוכנה רגילה בלתי נראית, היא חסרת משמעות לענייננו.
סרביס, זה "של וינדוס" בדיוק כמו כל תוכנה אחרת שלך. ההבדל בין סרביס לתוכנה רגילה זה סה"כ העדר משתמש גרפי וריצה פר מכונה ולא פר USER. יש עוד פיצרים כמו אתחול מחדש בכישלון וכו' וזה באמת רלוונטי למקרה שלך קצת, אבל זה לא מוריד ממך שום דאגה מהסוג שהעלית פה באשכול.
פורסם במקור בפורום CODE613 ב15/05/2014 17:30 (+03:00)
בעיית התאריך והשעה מצריכה אותך לדאוג שיהיה במסד אינדקס מוצלח לכך (לדעתי אינדקס על התאריך שעה מפולטר כלומר עם where שלא נשלח, אבל ייתכן שיותר זול אינדקס שמורכב משתי העמודות. בכל מקרה שהאינדקס "יכסה" את כל העמודות הנדרשות לתשובה) ואז המהירות תהיה דומה.
ההבדל בין paralel לtask שהצעתי זה בגלל שרציתי ל"שגר ולשכוח" ואילו Paralel עושה במקביל אבל ממשיכה רק אחרי שכולם גמרו.
פונקציית הטעינה נגמרת מייד ע"י סיום יצירת הTask פר שורה (מיידית). הTask ממתינים לריצה עד שהפונקציה תיגמר ואז הם מתחילים כולם בו זמנית - אבל בצורה מבוקרת - אחרי XXX שהתחילו המנהל חוסם את היתר, עד שאחד יפנה מקומו וכו'.
לא חשבתי שאתה מכיר לעומק את הבו זמניות בדוט נט, אבל ביקשת שניתן לך כיוון. בשביל ללמוד את הTask תתחיל להשתמש בזה בפרוייקט קטן, ותדמה מהירות נמוכה ע"י Sleep.
פורסם במקור בפורום CODE613 ב15/05/2014 15:41 (+03:00)
זה מאוד מאתגר הנושא.
אני לא בטוח הבנתי הכל:
אז אני מדמיין מחלקה כזאת:
שדה מספרי (להלן LastId), מייצג את מזהה הרשומה האחרונה שנכנסה.
מנהל Task - משהו שנקרא TaskScheduler. אפשר ליצור ממנו כמו טרידים עם שליטה על המספר הבו זמני של הביצוע.
פונקציית טעינה: שאילתה מהDB לשורות אשר לא נשלחו והID שלהם גדול מLastId - יצירה פר שורה של Task ע"י המנהל.
טיימר לפונקציית הטעינה אפי' כל דקה.
המושג Task הוא טריד ידידותי מאוד למפתחים. הוא מכיל בו הוראות מה לעשות בעת פעולה והוראת ריצה אסינכרונית (בברירת מחדל). כל עוד הוא לא מורץ הוא רק תופס את הזיכון של מס' שדותיו, וזה כמו מחלקה רגילה. אם הסקבילריות דורשת לדמיין שיהיו מליון רשומות שנטענות בו זמנית (ונקודת זמן אחת), אז יש מקום למנוע טעינת כל השורות ישירות לTask אלא לעשות תור FIFO - בדוט נט זה: Queue<T> ובסיום מאה Task לדוגמה, לטעון חזרה חדשים עד סיום התור.
פורסם במקור בפורום CODE613 ב15/05/2014 15:05 (+03:00)
שלא כמו בSqLite או Comact Sql ואקסס, שם התוכנה ניידת לגמרי כי היא/הפימוורק כוללים את מנוע המסד,
LoaclDb זה מסד של ממש, אחיו הקטן של SQL SERVER EXPERSS, והוא מחייב התקנה (אם כי קטנה וקלה לאין ערוך ביחס לאחיו הגדול).
ההתקנה נמצאת כאן: http://www.microsoft.com/en-us/download/details.aspx?id=29062
הקובץ הנצרך זה ENU\x86\SqlLocaLDB.MSI ל32 ביט, או ENU\x64\SqlLocaLDB.MSI ל64 ביט.
פורסם במקור בפורום CODE613 ב15/05/2014 16:51 (+03:00)
כשמוחקים את כל השורות במקום לעשות שאילתת מחיקה יותר מהר לעשות Truncate table XXX.
פורסם במקור בפורום CODE613 ב15/05/2014 18:46 (+03:00)
שים לב שלמיילים אתה יכול לעשות עמודה מסוג varchar ולא nvarchar מכיון שממילא התוים שאין בראשון הם לא חוקיים במייל.
אפרופו אימות מיילים, הצרה היא שגם מיילים לא חוקיים יכולים להיות קיימים ועובדים, בהתאם לספק מדינה ועוד.
יעויין פה:
http://stackoverflow.com/a/201378/1271037
ובקישורים של ההודעה, וגם פה: http://www.regular-expressions.info/email.html
מהקישור האחרון של Stackoverflow גיליתי משהו חדש - אתר לregex שנראה מעניין: https://www.debuggex.com (הרשמה קלה באמצעות חשבון gmail פעיל ודומיו) יש לו מציג ביטויים ויזואלי ועוד דברים.
פורסם במקור בפורום CODE613 ב15/05/2014 12:14 (+03:00)
אפשר יותר, כעת ראיתי פה במסמך צריך להעמיק בו http://www.moc.gov.il/sip_storage/FILES/7/167.pdf
פורסם במקור בפורום CODE613 ב14/05/2014 15:25 (+03:00)