שלום.
תהיתי לעצמי מה הדרך הטובה ביותר לשמור תאריכים במסד נתונים מסוג mysql.
אני מתכנת בphp ומשתמש בפורמט UNIX timestamp.
באיזה סוג משתנה הכי טוב לשמור את התאריך?
int פשוט, או אולי באחד מסוגי הdate השונים שmysql מציע?

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

"לדבר תכלס" הכוונה "להציג" תכלס?
כי מבחינת חישוב תאריכים, בדיקה, קפיצת ימים וכו' unixtime הרבה יותר נוח..
קשה לי להחליט.. :Z

תלוי אם רוב החישובים שלך קורים במהלך השאילתה או הרבה בשפת השרת, כי אז INTERVAL הרבה יותר פשוט וברור לשימוש

אני באופן אישי מוצא את unixtime הרבה יותר נוח.

נמאס לכם לזכור סיסמאות? לחצו כאן!

DATETIME זאת הדרך הנכונה.

נימוקים?

(חוץ מה"יתרון" הבולט שטור DATETIME צורך פי 2 אחסון מטור INT ?)

נמאס לכם לזכור סיסמאות? לחצו כאן!

קודם כול אם ייצא לך לקרוא בנושא תראה מבחינת אופטימיזציה 2 השדות ייתנהגו בצורה זהה, חוץ מזה שהמון אתרים אומרים שפעולות כמו GROUP BY יעבדו יותר מהר על שדה מסוג DATETIME מאשר UNIXTIME, כי בUNIXTIME אתה צריך לבצע כול פעם פעולת היפוך כדי לבצע GROUP BY YEAR,MONTH,DAY בDATETIME כול מה שצריך זה להשתמש בפונקציות הבסיסיות YEAR,DAY,MONTH.

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

השאלה היא האם זה באמת מקל על שליפות

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

אגב, נשמע שאתה יוצא מנקודת הנחה שברקע ה RDBMS לא עושה תרגום של המידע למשהו שדומה ל unixtime - שזה כמובן אפשרי - אבל בוודאי נעשית שם המרה כלשהיא. אין אני יודע? כי המחרוזת 2010-05-09 13:46 פשוט לא נכנסת בשמונה בתים, גם אם נוריד את כל המקפים, הרווחים, והנקודותיים. מכאן שנעשות כאן המרות...

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

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציינת לבד שוב עוד משהו נוח מאוד בשימוש עם DATETIME העבודה עם איזורי זמן, יש לך פונקציה שנקראת CONVERTֹ_TZ שיכולה להפוך זמן לכול אזור זמן רצוי.

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

מעבר לזה ראיתי שיש במערכת לוח שנה, אתה בטוח שהוא גם מבוסס על UNIXTIME?

כעקרון כמעט כל דבר בעולם מבוסס unixtime...

לעניין ההמרה לאיזורי זמן, הנקודה שלי היא שהרבה יותר נוח לעשות את זה בצורה אחידה דרך האפליקציה שמדברת עם ה DB. במיוחד שאתה משחק עם הסטות בתאריכים. מה לעשות, פורמט התאריך המקורי הוא לא נוח לתצוגה למשתמשים, לרוב, ולכן בכל מקרה יומר. אז מה, תמיר את זה ל unixtime ואז משם למשהו אחר בקליינט? עדיף כבר לעבוד רק עם unixtime ואז בצד הקליינט להשתמש בפונקציה שמציגה תאריכים כראוי (למשל ב PHP יש את date() שאוטומטית תתחשב באיזור הזמן שבו הסקריפט מבקש להציג תאריכים, כולל התחשבות בשעון חורף וקיץ, על ידי date_default_timezone_set ...)

נמאס לכם לזכור סיסמאות? לחצו כאן!

את החישובים תמיד כדאי לעשות בDB.
אל תשכח בסוף הכל מומר לתווים לוכן דווקא שמירה כDATETIME יכולה להיות יותר יעילה.

יוצא דופן הוא בד"כ שדה TIMESTAMP בשימושים של OPTIMISTIC LOCK. אותו באמת כדאי לשמור כTIMESTAMP.

ועוד משהו: מה אם אתה צריך רזולוציה יותר עדינה משנייה?

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

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

בכל אופן, אני רואה שזה נהיה עוד אשכול כזה, אז אני אפסיק כאן

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

סעו לשלום, המפתחות בפנים

נמאס לכם לזכור סיסמאות? לחצו כאן!

אל תשכח לעשות
WHERE time = UNIX_TIMESTAMP() - 60*60*24*30

במקום
NOW() - INTERVAL 1 MONTH

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

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

סוג השדה TIME גם מאוד עזר לי שהייתי צריך לאחסן שעות ואחר כך לחשב הפרשים של שעות בין רשומות, סיכום של הפרשים בין רשומות וכו'