كيف تتجنب إضافة حقول الطابع الزمني إلى جداولك؟[مغلق]

Question

لدي سؤال بخصوص العمودين الإضافيين (timeCreated، timeLastUpdated) لكل سجل نراه في العديد من الحلول.سؤالي:هل هناك بديل أفضل؟

سيناريو:لديك قاعدة بيانات ضخمة (من حيث الجداول وليس السجلات)، ثم يأتي العميل ويطلب منك إضافة "الطابع الزمني" إلى 80% من جداولك.

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

لتصوير هذا، افترض هذا السيناريو الأساسي.سيكون لدينا جدولين:

الدفع :- (سجلاتك المعتادة)
الطابع الزمني: - {الطابع الزمني الحالي} + {TABLE_UPDATED, id_of_entry_updated, timestamp_type}

لاحظ أنك في هذا التصميم لا تحتاج إلى هذين العمودين "الإضافيين" في كائن الدفع الأصلي الخاص بك (والذي، بالمناسبة، قد يتم ذلك من خلال حل ORM الخاص بك) لأنك تقوم الآن بالفهرسة بواسطة TABLE_UPDATED و id_of_entry_updated.فضلاً عن ذلك، timestamp_type سيخبرك ما إذا كان الإدخال مخصصًا للإدراج (على سبيل المثال "1") أو التحديث (على سبيل المثال "2") وأي شيء آخر قد ترغب في إضافته، مثل "الحذف".

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

هتافات ، إدواردو

Answer 1

وبينما كنت في ذلك، أيضا تسجيل المستخدم الذي أجرى التغيير.

والخلل في تصميم جدول منفصل (بالإضافة إلى الأداء انضمام أبرز من قبل الآخرين) هو أنه يجعل افتراض أن <م> كل الجدول على عمود هوية المفتاح. هذا ليس صحيحا دائما.

إذا كنت تستخدم SQL Server و الجديد نسخة 2008 يدعم شيء يسمونه Change Data Capture التي يجب أن يسلب الكثير من الألم الذي نتحدث عنه. وأعتقد أن أوراكل قد يكون شيئا من هذا القبيل أيضا.

---

تحديث: يبدو أوراكل تطلق عليه نفس الشيء SQL خادم. أو بالأحرى، SQL خادم يسميها نفس الشيء مثل أوراكل، منذ جاء تنفيذ أوراكل أول؛)
http://www.oracle.com/technology/oramag/ أوراكل / 03-نوفمبر / o63tech_bi.html

Answer 2

ولقد استخدمت التصميم حيث كل طاولة ليتم تدقيقها كان جدولين:

create table NAME (
  name_id int,
  first_name varchar
  last_name varchar
  -- any other table/column constraints
)

create table NAME_AUDIT (
  name_audit_id int
  name_id int
  first_name varchar
  last_name varchar
  update_type char(1) -- 'U', 'D', 'C'
  update_date datetime
  -- no table constraints really, outside of name_audit_id as PK
)

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

وكان يعمل بشكل جيد إلى حد معقول ولا يتطلب أية تغييرات على رمز التطبيق لتنفيذها.

Answer 3

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

وأيضا، والكثير من الوقت عندما كنت تبحث في الطوابع، هو عندما كنت تصحيح المشكلة في التطبيق الخاص بك وأنت تريد البيانات هناك حق، بدلا من الاضطرار دائما للانضمام ضد الجدول الآخر.

Answer 4

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

وتسجيل التغييرات تسجيل في ملف منفصل يعني أنك يمكن أن تظهر عدة تغييرات إلى مستوى قياسي، مثل:

وشهر / يوم / ح ح ص ص: MM: SS أضيف بواسطة XXX يوم / شهر / سنة HH: MM: SS PRICE الميدان تغيير كتبها XXX، يوم / شهر / سنة HH: MM: SS سجل حذفها من قبل XXX

وعيب واحد هو رمز إضافي لسوف تؤدي تدرج في جدول الطوابع الزمنية الخاصة بك لتعكس التغيرات في الجداول الرئيسية.

Answer 5

إذا قمت بإعداد الاشياء طابع زمني لتشغيل الخروج من مشغلات، من أي عمل يمكن أن يفجر الزناد (يقرأ؟) يمكن تسجيل. أيضا قد يكون هناك بعض المزايا تأمين.

و(خذ كل ما مع حبة الملح، وأنا لا DBA أو SQL المعلم)

Answer 6

نعم، أنا أحب هذا التصميم، واستخدامه مع بعض الأنظمة. عادة، وبعض البديل من:

LogID  int
Action varchar(1)     -- ADDED (A)/UPDATED (U)/DELETED (D)
UserID varchar(20)    -- UserID of culprit :)
Timestamp datetime    -- Date/Time
TableName varchar(50) -- Table Name or Stored Procedure ran
UniqueID int          -- Unique ID of record acted upon
Notes varchar(1000)   -- Other notes Stored Procedure or Application may provide

Answer 7

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

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

Answer 8

وأعتقد أن اضافية ينضم سيكون لديك لأداء للحصول فإن الطوابع يكون ضربة أداء خفيف وألم في الرقبة. عدا ذلك لا أرى أي مشكلة.

Answer 9

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

وعيب واحد هو تقديم التقارير، و / أو يظهر الكثير من الطوابع differant على على الشاشة. إذا كنت تفعل ذلك بالطريقة فعلنا ذلك، فإنه تسبب في الكثير من الصلات. أيضا، كانت التغييرات إنهاء يعود الألم.

Answer 10

الحل الذي نقدمه هو الحفاظ على جدول "المعاملات"، بالإضافة إلى جدول "الجلسة".تتم إدارة جميع تعليمات التحديث والإدراج والحذف من خلال كائن "المعاملة" ويتم تخزين كل من تعليمات SQL هذه في جدول "المعاملة" بمجرد تنفيذها بنجاح في قاعدة البيانات.يحتوي جدول "المعاملة" هذا على حقول أخرى مثل نوع المعاملة (I لـ INSERT، وD لـ DELETE، وU لـ UPDATE)، وTransactionDateTime، وما إلى ذلك، ومفتاح خارجي "sessionId"، يخبرنا أخيرًا بمن أرسل التعليمات.بل إنه من الممكن، من خلال بعض التعليمات البرمجية، تحديد من فعل ماذا ومتى (أنشأ جوس السجل يوم الاثنين، وقام تيم بتغيير سعر الوحدة يوم الثلاثاء، وأضافت ليز خصمًا إضافيًا يوم الخميس، وما إلى ذلك).

إيجابيات هذا الحل هي:

1. أنت قادر على معرفة "ماذا ومن ومتى"، وإظهاره للمستخدمين!(ستحتاج إلى بعض التعليمات البرمجية لتحليل عبارات SQL)
2. إذا تم نسخ البيانات الخاصة بك، وفشل النسخ المتماثل، يمكنك إعادة بناء قاعدة البيانات الخاصة بك من خلال هذا الجدول

السلبيات هي

1. 100000 تحديث بيانات شهريًا يعني 100000 سجل في Tbl_Transaction
2. وأخيرًا، يمثل هذا الجدول 99% من حجم قاعدة بياناتك

اختيارنا:يتم حذف جميع السجلات الأقدم من 90 يومًا تلقائيًا كل صباح

Answer 11

وفيليب،

ولا ببساطة حذف تلك مضى عليها أكثر من 90 يوما، نقلها أولا إلى DB منفصل أو كتابتها إلى ملف نصي، أن تفعل شيئا للحفاظ عليها، مجرد نقلها من الإنتاج الرئيسية DB.

إذا يأتي من أي وقت مضى الامر لذلك، في معظم الأحيان بل هو حالة "انه مع معظم انتصارات وثائق"!