هل كل أمر DDL SQL قابل للعكس؟[التحكم في إصدار قاعدة البيانات]

Question

أريد إعداد آلية لتتبع تغييرات مخطط قاعدة البيانات، مثل تلك الموضحة في هذه الإجابة:

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

سؤالي هو التالي:هل كل أمر DDL بطريقة "up" قابل للعكس؟بمعنى آخر، هل يمكننا دائمًا توفير طريقة "لأسفل"؟هل يمكنك تخيل أي أمر DDL لا يمكن "إيقافه"؟

من فضلك، لا تأخذ في الاعتبار مشكلة ترحيل البيانات النموذجية حيث نفقد البيانات أثناء الطريقة "up":على سبيل المثالتغيير نوع الحقل من datetime (DateOfBirth) ل int (YearOfBirth) نحن نفقد البيانات التي لا يمكن استعادتها.

Answer 1

في خادم SQL، كل أمر DDL أعرفه هو زوج لأعلى/لأسفل.

Answer 2

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

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

راجع وثائق API هنا.

Answer 3

نعم، لقد حددت الحالات التي تفقد فيها البيانات، إما عن طريق تحويلها أو ببساطة إسقاط العمود في الترحيل "لأعلى".

مثال آخر هو أنه يمكنك إسقاط كائن SEQUENCE، وبالتالي فقدان حالته.سيؤدي الترحيل "لأسفل" إلى إعادة إنشاء التسلسل، ولكنه سيبدأ من جديد عند 1.قد يتسبب هذا في إنشاء قيم مكررة بواسطة التسلسل.لا توجد مشكلة إذا كنت تقوم بإجراء ترحيل على قاعدة بيانات فارغة، وتريد أن يبدأ التسلسل عند 1 على أي حال، ولكن إذا كان لديك عدد معين من صفوف البيانات، فأنت تريد إعادة تعيين التسلسل إلى القيمة الأكبر قيد الاستخدام حاليًا، وهو أمر يصعب القيام به بشكل موثوق، إلا إذا كان لديك قفل حصري على تلك الطاولة.

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