mysql - شرح - ماهو timestamp




هل يجب علي استخدام نوع بيانات التاريخ والوقت في MySQL؟ (20)

هل تنصح باستخدام datetime أو حقل datetime ، ولماذا (باستخدام MySQL)؟

أنا أعمل مع PHP على جانب الخادم.


2016 + : ما أنصحك به هو تعيين المنطقة الزمنية لـ Mysql على UTC واستخدام DATETIME:

يمكن لأي إطار أمامي حديث (Angular 1/2، react، Vue، ...) بسهولة وتحويل تلقائي لوقتك UTC إلى التوقيت المحلي.

بالإضافة إلى:

(ما لم يكن من المحتمل تغيير المنطقة الزمنية لخوادمك)

مثال مع AngularJs

// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...

// font-end Output the localised time
{{item.my_datetime | date :'medium' }}

يتوفر كل تنسيق الوقت المحلي هنا: https://docs.angularjs.org/api/ng/filter/date


  1. TIMESTAMP هو أربعة بايت مقابل ثمانية بايت لـ DATETIME.

  2. الطوابع الزمنية هي أيضا أخف وزنا على قاعدة البيانات وفهرستها بشكل أسرع.

  3. يتم استخدام نوع DATETIME عندما تحتاج إلى القيم التي تحتوي على معلومات التاريخ والوقت. يسترد MySQL ويعرض قيم DATETIME بتنسيق 'YYYY-MM-DD HH: MM: SS'. النطاق المدعم هو "1000-01-01 00:00:00 ′ to" 9999-12-31 23:59:59 ′.

يحتوي نوع البيانات TIMESTAMP على نطاق من "1970-01-01 00:00:01 ′ UTC إلى" 2038-01-09 03:14:07 ′ UTC. لديه خصائص متفاوتة ، اعتمادا على إصدار MySQL ووضع SQL الخادم قيد التشغيل.

  1. DATETIME ثابت بينما يتم تنفيذ TIMESTAMP بواسطة إعداد time_zone.


أستخدم دائمًا طابعًا يونكسًا ، ببساطة للحفاظ على العقلانية عند التعامل مع الكثير من معلومات التاريخ والوقت ، خاصة عند إجراء تعديلات على المناطق الزمنية ، وإضافة / طرح التواريخ ، وما شابه ذلك. عند مقارنة الطوابع الزمنية ، يستثني ذلك العوامل المعقدة للمنطقة الزمنية ويسمح لك بتجنيب الموارد في معالجة جانب الخادم الخاص بك (سواء كان رمز التطبيق أو استعلامات قاعدة البيانات) من حيث استخدامك للوزن الخفيف بدلاً من ذلك ثم إضافة / طرح وقت / وقت أثقل أثقل المهام.

شيء آخر يستحق النظر:

إذا كنت تقوم بإنشاء تطبيق ، فأنت لا تعرف أبدًا كيف يمكن استخدام بياناتك أسفل الخط. إذا انتهى الأمر عليك ، على سبيل المثال ، قارن مجموعة من السجلات في مجموعة البيانات ، مع ، على سبيل المثال ، مجموعة من العناصر من واجهة برمجة التطبيقات لجهة خارجية ، وقول ، ضعها بترتيب زمني ، فستكون سعيدًا بوجود الطوابع الزمنية يونكس لصفوفك. حتى إذا قررت استخدام الطوابع الزمنية لـ MySQL ، فقم بتخزين طابع يونكس كتأمين.


أوصي باستخدام لا DATETIME أو حقل TIMESTAMP. إذا كنت تريد أن تمثل يومًا معينًا ككل (مثل تاريخ الميلاد) ، فاستخدم نوع DATE ، ولكن إذا كنت أكثر تحديدًا من ذلك ، فمن المحتمل أنك مهتم بتسجيل لحظة فعلية بدلاً من وحدة الوقت (اليوم ، الأسبوع ، الشهر ، السنة). بدلاً من استخدام DATETIME أو TIMESTAMP ، استخدم BIGINT ، وقم ببساطة بتخزين عدد المللي ثانية منذ عهد (System.currentTimeMillis () إذا كنت تستخدم Java). هذا له العديد من المزايا:

  1. يمكنك تجنب قفل البائع. إلى حد كبير كل قاعدة بيانات تدعم الأعداد الصحيحة بطريقة مشابهة نسبيا. افترض أنك تريد الانتقال إلى قاعدة بيانات أخرى. هل تريد القلق بشأن الاختلافات بين قيم DATETIME الخاصة بـ MySQL وكيف يحددها Oracle؟ حتى بين الإصدارات المختلفة من MySQL ، تتميز TIMESTAMPS بمستوى مختلف من الدقة. لقد تم مؤخرًا فقط دعم MySQL ميلي ثانية في الطوابع الزمنية.
  2. لا توجد مشاكل في المنطقة الزمنية. كانت هناك بعض التعليقات المتعمقة هنا حول ما يحدث في المناطق الزمنية مع أنواع البيانات المختلفة. ولكن هل هذه المعرفة مشتركة ، وهل سيأخذ زملاؤك في العمل وقتًا لتعلمها؟ من ناحية أخرى ، من الصعب جدًا تغيير وضع BigINT إلى java.util.Date. يؤدي استخدام BIGINT إلى حدوث الكثير من المشكلات مع المناطق الزمنية للتغلب على جانب الطريق.
  3. لا تقلق بشأن النطاقات أو الدقة. لا داعي للقلق بشأن ما يتم قطعه حسب النطاقات الزمنية المستقبلية (TIMESTAMP ينتقل فقط إلى 2038).
  4. تكامل أداة الطرف الثالث. باستخدام عدد صحيح ، من المستحيل استخدام أدوات طرف ثالث (مثل EclipseLink) للتعامل مع قاعدة البيانات. ليس كل أداة طرف ثالث سيكون لها نفس الفهم "للوقت والتاريخ" كما يفعل MySQL. هل ترغب في تجربة ما إذا كنت تريد استخدام java.sql.TimeStamp أو java.util.Date الكائن إذا كنت تستخدم أنواع البيانات المخصصة هذه؟ استخدام أنواع البيانات الأساسية الخاصة بك يجعل استخدامها مع أدوات الطرف الثالث تافهة.

ترتبط هذه المشكلة ارتباطًا وثيقًا بكيفية تخزين قيمة مالية (أي 1.99 دولارًا) في قاعدة بيانات. يجب استخدام عشري أو نوع Money في قاعدة البيانات أو أسوأ من الكل Double؟ كل هذه الخيارات الثلاثة رهيبة ، لكثير من نفس الأسباب المذكورة أعلاه. الحل هو تخزين قيمة المال في السنت باستخدام BIGINT ، ثم تحويل السنت إلى دولار عند عرض القيمة للمستخدم. مهمة قاعدة البيانات هي تخزين البيانات ، وليس لتفسير تلك البيانات. كل هذه الأنواع من البيانات المخيفة التي تراها في قواعد البيانات (خاصةً أوراكل) تضيف القليل ، وتبدأ في الطريق إلى قفل البائع.



توضح الأمثلة أدناه كيف قام نوع تاريخ TIMESTAMP بتغيير القيم بعد تغيير time-zone to 'america/new_york' حيث لم يتغير DATETIME .

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

لقد حولت إجابتي إلى المقالة حتى يتمكن الكثير من الناس من العثور على هذا ، MySQL: Datetime Versus Timestamp Data Types .


حذار من تغيير الطابع الزمني عند القيام عبارة UPDATE على جدول. إذا كان لديك جدول بأعمدة 'Name' (varchar) و 'Age' (int) و 'Date_Added' (الطابع الزمني) وقمت بتشغيل عبارة DML التالية

UPDATE table
SET age = 30

عندئذٍ ، سيتم تغيير كل قيمة مفردة في عمود "Date_Added" إلى الطابع الزمني الحالي.


دائمًا ما أستخدم حقول DATETIME لأي شيء بخلاف البيانات الوصفية للصف (تاريخ الإنشاء أو التعديل).

كما dev.mysql.com/doc/refman/5.1/en/datetime.html في وثائق MySQL:

يتم استخدام نوع DATETIME عندما تحتاج إلى القيم التي تحتوي على معلومات التاريخ والوقت. يسترد MySQL ويعرض قيم DATETIME بتنسيق 'YYYY-MM-DD HH: MM: SS'. النطاق المدعم هو "1000-01-01 00:00:00" إلى "9999-12-31 23:59:59".

...

يحتوي نوع البيانات TIMESTAMP على نطاق من "1970/01/01 00:00:01" UTC إلى "2038-01-09 03:14:07" UTC. لديه خصائص متفاوتة ، اعتمادا على إصدار MySQL ووضع SQL الخادم قيد التشغيل.

من المحتمل جدًا أن تصل إلى الحد الأدنى في TIMESTAMP في الاستخدام العام - على سبيل المثال تخزين تاريخ الميلاد.


سأستخدم دائمًا طابعًا زمنيًا يونكسًا عند العمل مع MySQL و PHP. السبب الرئيسي وراء كون هذه هي طريقة date الافتراضية في PHP تستخدم طابع زمني مثل المعلمة ، لذلك لن يكون هناك حاجة إلى تحليل.

للحصول على الطابع الزمني الحالي لـ Unix في PHP ، فقط قم time();
وفي MySQL do SELECT UNIX_TIMESTAMP(); .


مقارنة بين DATETIME و TIMESTAMP و DATE

ما هذا [.fraction]؟

  • يمكن أن تتضمن قيمة DATETIME أو TIMESTAMP جزءًا كسريًا ثانويًا جزءًا من الدقة حتى ميكروثانية (6 أرقام). على وجه الخصوص ، يتم تخزين أي جزء كسري في قيمة إدراجها في عمود DATETIME أو TIMESTAMP بدلاً من تجاهلها. هذا بالطبع اختياري.

مصادر:


من الجدير بالملاحظة في MySQL يمكنك استخدام شيء ما على غرار الخطوط التالية عند إنشاء أعمدة الجدول:

on update CURRENT_TIMESTAMP

سيؤدي هذا إلى تحديث الوقت في كل مرة تقوم فيها بتعديل صف ، ويكون مفيدًا في بعض الأحيان بالنسبة لمعلومات التحرير الأخيرة المخزنة. هذا يعمل فقط مع الطابع الزمني ، ولكن ليس مع التاريخ والوقت.


هناك اختلاف آخر بين Timestamp و Datetime في Timestamp لا يمكنك تعيين القيمة الافتراضية لـ NULL.


والفرق الرئيسي هو أن DATETIME ثابت بينما يتأثر TIMESTAMP بإعداد time_zone .

لذا ، لا يهم ذلك إلا عندما يكون لديك - أو قد يكون لديك - مجموعات متزامنة عبر المناطق الزمنية.

بكلمات أبسط: إذا كان لديّ قاعدة بيانات في أستراليا ، وأخذ تفريغ قاعدة البيانات هذه لمزامنة / تعبئة قاعدة بيانات في أمريكا ، فسيتم تحديث TIMESTAMP لتعكس الوقت الفعلي للحدث في المنطقة الزمنية الجديدة ، في حين أن DATETIME سوف لا تزال تعكس وقت الحدث في منطقة التوقيت au .

من الأمثلة الرائعة على استخدام DATETIME حيث كان يجب استخدام TIMESTAMP في Facebook ، حيث لا تكون خوادمها متأكدة تمامًا مما حدث في الوقت عبر المناطق الزمنية. بمجرد أن أكون محادثة حيث قال الوقت كنت الرد على الرسائل قبل أن يتم إرسال الرسالة في الواقع. (هذا ، بالطبع ، يمكن أن يكون سببه أيضًا ترجمة المنطقة الزمنية السيئة في برنامج المراسلة إذا كان يتم نشر الأوقات بدلاً من التزامن).


يعتمد على التطبيق ، حقا.

ضع في اعتبارك تعيين طابع زمني من قبل مستخدم إلى خادم في نيويورك ، للحصول على موعد في Sanghai. الآن عندما يتصل المستخدم في Sanghai ، يصل إلى نفس الطابع الزمني التعيين من خادم معكوسة في طوكيو. وسيرى التعيين في وقت طوكيو ، يقابله وقت نيويورك الأصلي.

لذلك بالنسبة للقيم التي تمثل وقت المستخدم مثل موعد أو جدول زمني ، يكون التاريخ والوقت أفضل. يسمح للمستخدم بالتحكم في التاريخ والوقت المطلوب ، بغض النظر عن إعدادات الخادم. الوقت المحدد هو الوقت المحدد ، لا يتأثر بالمنطقة الزمنية للخادم ، أو المنطقة الزمنية للمستخدم ، أو بالتغييرات في طريقة حساب التوقيت الصيفي (نعم إنه يتغير).

من ناحية أخرى ، بالنسبة إلى القيم التي تمثل وقت النظام مثل معاملات الدفع أو تعديلات الجدول أو التسجيل ، استخدم دائمًا الطوابع الزمنية. لن يتأثر النظام بتحريك الخادم إلى منطقة زمنية أخرى ، أو عند المقارنة بين الخوادم في مناطق زمنية مختلفة.

الطوابع الزمنية هي أيضا أخف وزنا على قاعدة البيانات وفهرستها بشكل أسرع.


مرجع مأخوذ من هذه المادة:

الاختلافات الرئيسية:

تستخدم TIMESTAMP لتعقب التغييرات في السجلات ، وتحديث كل مرة عند تغيير السجل. DATETIME يستخدم لتخزين قيمة محددة وثابتة لا تتأثر بأي تغييرات في السجلات.

تأثر TIMESTAMP أيضًا بإعدادات TIME ZONE المختلفة ذات الصلة. DATETIME ثابت.

قام TIMESTAMP بتحويل المنطقة الزمنية الحالية داخليًا إلى UTC للتخزين ، وأثناء الاستعادة تم تحويلها إلى المنطقة الزمنية الحالية. DATETIME لا يمكن القيام بذلك.

TIMESTAMP مجموعة معتمدة: '1970-01-01 00:00:01 ′ UTC to' 2038-01-19 03:14:07 supported UTC DATETIME range range: '1000-01-01 00:00:00 ′ to' 9999 -12-31 23:59:59 ′


TIMESTAMP مفيد عندما يكون لديك زوار من دول مختلفة بمناطق زمنية مختلفة. يمكنك بسهولة تحويل TIMESTAMP إلى أي منطقة زمنية بالبلد


أفضّل استخدام الطابع الزمني للحفاظ على كل شيء في تنسيق أولي شائع واحد وتنسيق البيانات في شفرة PHP أو في استعلام SQL. هناك حالات يكون فيها مفيدًا في شفرتك للحفاظ على كل شيء في ثوانٍ بسيطة.


في حالتي ، أعددت UTC كمنطقة زمنية لكل شيء: النظام ، خادم قاعدة البيانات ، وما إلى ذلك في كل مرة أستطيع. إذا كان عميلي يتطلب منطقة زمنية أخرى ، عندئذ أقوم بتكوينه على التطبيق.

أفضّل دائمًا الطوابع الزمنية بدلاً من الحقول "تاريخ / وقت" ، لأن الطوابع الزمنية تتضمن المنطقة الزمنية ضمنيًا. لذلك ، منذ اللحظة التي يتم فيها الوصول إلى التطبيق من المستخدمين من مناطق زمنية مختلفة وتريدهم أن يروا التواريخ والأوقات في المنطقة الزمنية المحلية ، فإن هذا النوع من الحقول يجعل الأمر سهلاً جدًا إذا تم حفظ البيانات في حقول التاريخ والوقت .

كإضافة ، في حالة ترحيل قاعدة البيانات إلى نظام بمنطقة زمنية أخرى ، سأشعر بثقة أكبر باستخدام الطوابع الزمنية. عدم قول القضايا المحتملة عند حساب الاختلافات بين لحظتين مع تغير زمن السنين بينهما وبين الحاجة إلى دقة 1 ساعة أو أقل.

إذن ، للتلخيص ، أقدر مزايا الطوابع الزمنية هذه:

  • جاهز للاستخدام على التطبيقات الدولية (مناطق زمنية متعددة)
  • هجرات سهلة بين المناطق الزمنية
  • من السهل جدًا حساب الاختلافات (فقط طرح الطوابع الزمنية)
  • لا تقلق بشأن التواريخ في / خارج فترة الصيف

لكل هذه الأسباب ، أختار حقول UTC و timestamp حيث يمكن التوضيح. وأنا أتجنب الصداع ؛)


لقد وجدت فائدة غير مسبوقة في قدرة TIMESTAMP على التحديث التلقائي لنفسها استنادًا إلى الوقت الحالي دون استخدام المشغلات غير الضرورية. هذا مجرد لي على الرغم من أن TIMESTAMP هو UTC كما قيل.

يمكن أن تتعقب عبر مناطق زمنية مختلفة ، لذلك إذا كنت بحاجة إلى عرض وقت نسبي على سبيل المثال ، فإن UTC هو ما تريده.





sqldatatypes