سؤال

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

تحديث:أنا على دراية بـ ISO8601 واستخدمته بالفعل لتخزين التاريخ كسلسلة بتنسيق YYYY-MM-DD للنموذج الأولي.ولكن بالنسبة لمختلف العمليات الحسابية، لا بد لي من تحويلها إلى رقم ما داخليًا، لذلك أفضل تخزين رقم وتحويله فقط إلى سلسلة للعرض.ما هي الوحدات التي يجب أن يكون هذا الرقم، وبأي أصل، وإذا كانت الوحدات أكثر دقة من الأيام، في أي وقت من اليوم يجب استخدامه؟

هل كانت مفيدة؟

المحلول

إذا كنت تتوقع تسليم التاريخ إلى أداة أو مكتبة خارجية، فيجب عليك استخدام أي تنسيق تتوقعه.يبدو أن وقت Unix هو اللغة المشتركة لعلم صناعة الساعات الرقمية، لذلك يعد خيارًا افتراضيًا جيدًا إذا لم تحدد الظروف الخارجية الاختيار المناسب لك.

ايزو 8601 قد تكون ذات فائدة.

يحرر:

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

اه، هذا منطقي.إذا كانت بيئتك (.NET؟بايثون؟C++؟) لديها أدوات للتعامل مع الوقت، فمن الأفضل استخدام وحدتها الأصلية وعصرها.لا يوجد سبب لإعادة كتابة كل وظائف معالجة التاريخ تلك؛إنهم أصعب مما يبدون.بخلاف ذلك، سأستخدم الأيام في التقويم المحلي (الغريغوري؟) منذ فترة معقولة لتطبيقك.كن كريمًا، فأنت لا تريد حدوث خطأ عكسي في عام 2000 عندما تحتاج فجأة إلى التعامل مع تاريخ أبكر مما كنت تتوقعه.

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

نصائح أخرى

إذا كنت تريد تغطية قواعدك، فتأكد من تخزين التاريخ بالتوقيت العالمي المنسق واختيار معيار ISO.يتطلب هذا الأسلوب الحد الأدنى من الجهد وسيحمي التعليمات البرمجية الخاصة بك من مشكلات التشغيل المتداخل المستقبلية.وأنا أتفق معskymt ايزو 8601 هو اختيار جيد.

إذا كنت تستخدم C++، فإن Boost::date_time يستحق المشاهدة.

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

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

في محاولتي الثانية، استخدمت مخططًا مشابهًا ولكني قمت بتشفير التاريخ في رقم واحد، باستخدام البتات الخمس السفلية لليوم والبتات العلوية المتبقية للشهر (مرة أخرى، منذ يناير 2000).وظائف التحويل كانت:

Date = (Month << 5) | Day
Month = Date >> 5
Day = 0x1F & Date

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top