Ana içerik
Konu: Bilgisayar Programlama > Ünite 3
Ders 4: SQL ile Veritabanlarını DeğiştirmeSQL'nizi daha güvenli yapın
SQL güzel bir şey olduğu gibi, tehlikeli bir şey de olabilir. SQL kullanarak yüzlerce veya binlerce veya milyonlarca kullanıcının kullandığı bir uygulamaya erişmek istiyorsanız, dikkatli olmanız gerekir - çünkü tüm verilere yanlışlıkla zarar verebilirsiniz veya silebilirsiniz. Ancak, SQL'i daha güvenli yapmak için çeşitli yöntemler vardır.
Kötü güncellemelerden/silmelerden kaçınma
Bir
UPDATE yayınlamadan önce, doğru sütun ve satırı güncellediğinizden emin olmanız için aynı WHERE ile bir SELECT çalıştırın.Örneğin, çalıştırmadan önce:
UPDATE users SET deleted = true WHERE id = 1;Şunu çalıştırabilirsiniz:
SELECT id, deleted FROM users WHERE id = 1;Güncellemeyi çalıştırmaya karar verdikten sonra, yanlışlıkla çok fazla satır silmediğinizden emin olmak için LIMIT işlemcisini kullanabilirsiniz:
UPDATE users SET deleted = true WHERE id = 1 LIMIT 1;Veya siliyorsanız:
DELETE users WHERE id = 1 LIMIT 1;İşlem kullanma
Veri tabanını bir şekilde değiştiren bir SQL komutu verdiğimizde, bu ''işlem'' denilen bir şey başlatır. İşlem bir tek iş (banka işlemi gibi) düşünülen bir işlemler dizisidir ve veri tabanı dünyasında, bir işlem ''ACID'' prensiplerine uymalıdır ki güvenilir bir şekilde işlensin.
CREATE, UPDATE, INSERT veya DELETEgibi bir komut verdiğimizde, otomatik olarak bir işlem başlatıyoruz. Ancak, istersek, çoklu komutları daha büyük işlemin içinde sarabiliriz. Belki bir UPDATE'in sadece başka bir UPDATE oluşursa, oluşmasını istiyoruz, onun için ikisini de aynı işleme koymak isteriz.Bu durumda, komutları
BEGIN TRANSACTION ve COMMIT içinde sarabiliriz:BEGIN TRANSACTION;
UPDATE people SET husband = "Winston" WHERE user_id = 1;
UPDATE people SET wife = "Winnefer" WHERE user_id = 2;
COMMIT;Veri tabanı bu
UPDATE komutlarını bir nedenden dolayı yayımlayamazsa, işlemi geri alır ve veri tabanını başlamadan önceki şekilde bırakır.Tüm komutlarımızın verilerin aynı görünümünde işlem yaptığından emin olmak istediğimizde de işlemleri kullanırız - komut dizisi çalışırken aynı verilerde başka işlemlerin çalışmadığından emin olmak istediğimizde. Çalıştırmak istediğiniz bir dizi komuta baktığınızda, aynı anda başka bir kullanıcı komut verirse neler olacağını kendinize sorun. Verileriniz garip bir duruma gelebilir mi? Bu durumda, bir işlem çalıştırmalısınız.
Örneğin, aşağıdaki komutlar kullanıcının bir rozet kazandığını belirten bir satır oluşturur ve sonra kullanıcının son etkinliğini bunu tanımlayacak şekilde günceller:
INSERT INTO user_badges VALUES (1, "SQL Master", "4pm");
UPDATE user SET recent_activity = "Earned SQL Master badge" WHERE id = 1;Aynı anda, başka bir kullanıcı veya süreç kullanıcıyı ikinci bir rozetle ödüllendirebilir:
INSERT INTO user_badges VALUES (1, "Great Listener", "4:05pm");
UPDATE user SET recent_activity = "Earned Great Listener badge" WHERE id = 1;Bu komutlar şu sırayla da gönderilebilir:
INSERT INTO user_badges VALUES (1, "SQL Master");
INSERT INTO user_badges VALUES (1, "Great Listener");
UPDATE user SET recent_activity = "Earned Great Listener badge" WHERE id = 1;
UPDATE user SET recent_activity = "Earned SQL Master badge" WHERE id = 1;En son eklenen rozeti ''Harika dinleyici'' olsa da, son etkinliği şimdi ''SQL Uzmanı rozeti kazandı'' olur. Bu dünyanın sonu değil, ama aynı zamanda muhtemelen beklediğimiz şey de değildir.
Bunun yerine, ortada başka işlemin olmadığını garanti etmek için, bunları bir işlemde çalıştırabiliriz:
BEGIN TRANSACTION;
INSERT INTO user_badges VALUES (1, "SQL Master");
UPDATE user SET recent_activity = "Earned SQL Master badge" WHERE id = 1;
COMMIT;Yedekleme yapma
Bu ipuçlarını kesinlikle izlemelisiniz, ama bazen yine de hatalar olabilir. Bu nedenle, birçok şirket veri tabanlarına yedekleme yapar - veri tabanı ve mevcut yerin boyutuna göre, saatlik, günlük, veya haftalık yedekleme olabilir. Kötü bir şey olduğunda, zarar görmeyen veya kaybolmayan tablolar için eski veri tabanından veri alabilirler. Bu veriler biraz eski olabilir, ama eski veriler veri olmamasından iyidir.
Çoğaltma
Bunu benzer bir yaklaşım da çoğaltmadır - veri tabanlarının kopyalarını farklı yerlerde saklama. Herhangi bir nedenle, veritabanının belirli bir kopyası kullanılamıyorsa (içinde olduğu binaya yıldırım çarpması gibi, ki bunu bana gerçekten oldu!), o zaman sorgulama hala mevcut olduğunu umduğumuz veri tabanının başka bir kopyasına gönderilebilir. Veriler çok önemliyse, kullanılabilir olmasını sağlamak için muhtemelen çoğaltılmalıdır. Örneğin, bir doktor acil bir durumda bir hastayı tedavi etmek için kişinin alerjilerinin listesini bulmaya çalışıyorsa, mühendislerin yedeklemeden bu verileri çıkarmasını bekleyemez, bu liste onlara hemen gerekir.
Ancak, veritabanlarını çoğaltmak çok daha fazla çaba gerektiri ve işlemlerin hepsine uygulanması gerektiğinden, bu, performansın daha yavaş olacağı anlamına gelir, bu yüzden şirketlerin çoğaltmanın faydalarının maliyetlere değer olup olmadığına karar vermeleri, ve kendi ortamlarında en iyi kurma yollarını araştırmaları gerekir.
Ayrıcalık verme
Birçok veri tabanı sisteminde kurulu kullanıcılar ve ayrıcalıklar vardır, çünkü bunlar bir sunucuda saklanır ve birden çok kullanıcı tarafından erişimlenir. Khan Academy'de SQL komutlarında kullanıcı/ayrıcalık kavramı yoktur, çünkü SQLite genelde tek kullanıcı senaryoda kullanılır ve böylece saklandığı sürücüye erişiminiz olduğu sürece buna yazabilirsiniz.
Ancak bir gün paylaşılan bir sunucudaki bir veri tabanı sistemini kullanırsanız, kullanıcıları ve ayrıcalıkları baştan düzgün ayarladığınızdan emin olmalısınız. Genel bir kural olarak, veritabanına tam erişimi olan sadece birkaç kullanıcı (arka uç mühendisleri gibi) olmalıdır, çünkü bu çok tehlikeli olabilir.
Örneğin, burada belirli bir kullanıcıya tam erişimi böyle veriyoruz:
GRANT FULL ON TABLE users TO super_admin;Burada sadece farklı bir kullanıcıya SELECT erişimini böyle veriyoruz:
GRANT SELECT ON TABLE users TO analyzing_user;Büyük bir şirkette, çoğu kullanıcıya genelde
SELECT erişimi bile vermek istemezsiniz, çünkü bir tabloda, kullanıcının e-posta adresi veya ismi gibi özel veriler bulunabilir. Birçok şirkette veri tabanlarının anonim versiyonu vardır, böylece özel bilgiye erişim hakkında endişelenmeden sorgulamaya devam edebilirler.Bonus: Daha güvenli SQl ile ilgili bu ünlü XKCD karikatürü (artı bu açıklamayı) okuyun.
Tartışmaya katılmak ister misiniz?
Henüz gönderi yok.