Cevap.

SQL'de toplu değişikliklerde genellikle “her şey veya hiçbir şey” senaryosunu uygulamak gerekir - ya tüm değişiklikler geçer ya da herhangi bir hata durumunda geri alınır. Bu yaklaşım, işlemler kullanılarak gerçekleştirilir. Saklanan prosedür açıkça bir işlem başlatmalıdır (BEGIN TRANSACTION), ilgili işlemleri kapsamalı, hataları işlemeli ve bir hata durumunda ROLLBACK gerçekleştirmeli, aksi takdirde COMMIT yapmalıdır.

Hataların uygun bir şekilde işlenmesini TRY...CATCH (SQL Server) veya EXCEPTION (PostgreSQL) gibi yapılarla unutmayın.

SQL Server için örnek:

CREATE PROCEDURE MassUpdate
AS
BEGIN
    BEGIN TRY
        BEGIN TRANSACTION;

        UPDATE Orders SET Status = 'Processed' WHERE Status = 'Pending';
        UPDATE Inventory SET Stock = Stock - 1 WHERE ProductID IN (SELECT ProductID FROM Orders WHERE Status = 'Processed');

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        ROLLBACK TRANSACTION;
        -- Hata günlüğü kaydı
        THROW;
    END CATCH
END

Yanıltıcı soru.

Soru: Sadece BEGIN TRANSACTION ve COMMIT kullanmak, tüm desteklenen DBMS'lerde değişikliklerin doğru bir şekilde geri alınmasını garanti etmek için yeterli midir?

Cevap: Hayır, işlem başlı başına istisnaları yakalamaz. Hatanın yakalanması ve açıkça ROLLBACK çağrılması için işleyiciler (TRY...CATCH veya benzerleri) kullanmak gerekir. Bazı DBMS'lerde (örneğin, MySQL'de autocommit ile) ek yapılandırma da gerekebilir.

Yanlış kod örneği (SQL Server):

BEGIN TRANSACTION;
UPDATE Users SET Name = 'Ivan' WHERE ID = 1;
UPDATE Orders SET Amount = Amount/0 WHERE UserID = 1; -- Sıfıra bölme hatası
COMMIT TRANSACTION;

Bu durumda, bir hata durumunda işlem açık kalır ve ilk tablodaki değişiklikler kaydedilebilir.

Hikaye

Bir e-ticaret projesinde, işlemlerde hata yönetimi unutuldu ve ilgili verilerin kısmi kaybına neden oldu: siparişi güncellerken stok güncellemelerinde bir sorun ortaya çıktığında, yalnızca bazı değişiklikler geri alınıyor ve bilginin bütünlüğü bozuluyordu.

Hikaye

BI analitik projesinde, işlemlere açık bir kontrol ve hata yakalama olmadan toplu rapor hesaplaması yapıldı. Sonuç: bazı raporlar güncellendi, diğerleri güncellenmedi. Nihai veriler tutarsız hale geldi, çünkü acil durumlar atomik geri alınmaya neden oluyordu.

Hikaye

Bir şirkette, büyük işlemler için işlem modunu ayarlamadan MySQL'de autocommit'e güvenildi. Sunucu arızasında, bazı veriler zaten kaydedilmişti, bazıları ise kaydedilmemişti, bu da uzun süreli kurtarma çalışmaları ve bazı siparişlerin kaybına neden oldu.

Hata işleme ve geri alma yaklaşımlarını, saklanan prosedürler aracılığıyla toplu veri değişiklikleri yaparken açıklayın. Birden fazla tabloyu etkileyen işlemler söz konusu olduğunda, 'her şey veya hiçbir şey' mantığını nasıl doğru bir şekilde uygulamalısınız?

Cevap.

Yanıltıcı soru.