SQLite, sayısal sütunlara sayısal olmayan değerlerin eklenmesini kabul etmeden daha az yararlı olur mu?

SQLite'de aşağıdaki ifade başarılı olur ve dize SALARY, türdeki sütuna eklenir / güncellenir INTEGER:

update employee set salary='TOO MUCH' where emp_id=1;

Sıfırın eklenmeyeceğini / güncellenmeyeceğini, ancak asıl "ÇOK ÇOK" dizesini ekleyeceğinizi unutmayın, bu nedenle bu, otomatik tür dönüştürme ile ilgili değildir.

SSS:

Bu bir özellik , bir hata değil. SQLite dinamik yazmayı kullanır. Veri türü kısıtlamalarını zorunlu kılmaz. Herhangi bir türdeki veriler (genellikle) herhangi bir sütuna eklenebilir. Tamsayı sütunlara, boolean sütunlardaki kayan nokta sayılarına veya karakter sütunlarındaki tarihleri ​​rastgele uzunluklu dizeler koyabilirsiniz. CREATE TABLE komutunda bir sütuna atadığınız veri türü, bu sütuna hangi verilerin yerleştirilebileceğini kısıtlamaz. Her sütun keyfi bir uzunluk dizesi tutabilir. (Bunun bir istisnası vardır: INTEGER PRIMARY KEY türündeki sütunlar yalnızca 64 bit işaretli tamsayı içerebilir. INTEGER PRIMARY KEY sütununa tamsayı dışında bir şey koymaya çalışırsanız hata oluşur.)

Bu davranış açıkça kasıtlı, yine de neden SQLite'ın bu davranışa sahip olduğunu merak ediyorum , bildiğim diğer SQL veritabanlarının çoğu farklı şekilde davrandığından, sayısal olmayan bir dize eklemeye çalışırken bir hatayı yükseltir veya 0 dizesini dönüştürür sayısal bir sütun.

• SQLite kitaplığı bu davranış olmadan daha az yararlı olur mu?

• Bu, kütüphaneyi küçük ve hızlı tutmak için tasarımla mı yapıldı?

• SQLite kitaplığı, sayısal bir sütuna bir dize eklemeyi denediğinde hataları artırmak için önemli ölçüde daha yavaş veya daha büyük olur mu?

Hayır, dinamik yazım hem daha fazla depolama alanı hem de daha fazla işlem süresi gerektirir, özellikle de tür yakınlığı eklediklerinden, programlayıcının yoksayması serbest olan tercih edilen bir türe sahip olduğu anlamına gelir. Gerçek takas maliyetleri ile gerçekten kasıtlı bir özelliktir. Bu maliyetler, SQLite hedeflerinin kullanım durumları için etkili bir şekilde ihmal edilebilir, ancak hala oradalar.

Bu özelliklerin kullanışlılığını görmek zordur, çünkü bu özelliği size sunmaya alışkın değilsiniz. Eksikliği için geçici çözüm artık size daha doğal geliyor. Önceki deneyimleriniz nedeniyle, bunu asla başka bir şey olmayacak bir INTEGER alanı olarak düşünüyorsunuz , ancak SQLite bunu daha çok herhangi bir tür alan olarak görüyor, ancak büyük olasılıkla tamsayılar içerecektir. Belki de çoğunlukla ABD'de iş yapan, ancak bir avuç Kanada müşterisi olan bir şirket için bir posta kodu. Kullanıcının bir tamsayı benzeşimi belirtmesine izin vermek, onu her satırda bir dize yapmaktan çok fazla yer tasarrufu sağlar, ancak yine de size bu seçeneği sunar.