SQLite sẽ ít hữu ích hơn nếu không chấp nhận chèn các giá trị không phải là số vào các cột số?


10

Trong SQLite, câu lệnh sau sẽ thành công và chuỗi sẽ được chèn / cập nhật vào SALARYcột có kiểu INTEGER:

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

Lưu ý rằng số 0 sẽ không được chèn / cập nhật mà là chuỗi "QUÁ NHIỀU" thực tế , vì vậy đây không phải là về chuyển đổi loại tự động.

Câu hỏi thường gặp nêu rõ:

Đây là một tính năng , không phải là một lỗi. SQLite sử dụng kiểu gõ động. Nó không thực thi các ràng buộc kiểu dữ liệu. Dữ liệu thuộc bất kỳ loại nào có thể (thường) được chèn vào bất kỳ cột nào. Bạn có thể đặt các chuỗi có độ dài tùy ý vào các cột số nguyên, số dấu phẩy động trong các cột boolean hoặc ngày trong các cột ký tự. Kiểu dữ liệu bạn gán cho một cột trong lệnh CREATE TABLE không hạn chế dữ liệu nào có thể được đưa vào cột đó. Mỗi cột có thể giữ một chuỗi độ dài tùy ý. .

Vì vậy, hành vi này rõ ràng là có chủ ý, tuy nhiên tôi tự hỏi tại sao SQLite có hành vi này, vì hầu hết các cơ sở dữ liệu SQL khác mà tôi biết có hành vi hoàn toàn khác, chúng sẽ phát sinh lỗi hoặc chuyển đổi chuỗi 0, khi cố gắng chèn một chuỗi không phải là số vào một cột số.

  • Thư viện SQLite sẽ ít hữu ích hơn nếu không có hành vi này?

  • Điều này được thực hiện bởi thiết kế để giữ cho thư viện nhỏ và nhanh?

  • Thư viện SQLite sẽ chậm hơn hoặc lớn hơn đáng kể để phát sinh lỗi khi triying chèn một chuỗi vào một cột số?


9
Ai đó đã từng nói rằng "một tính năng là một lỗi như được mô tả bởi bộ phận tiếp thị".
Dan Pichelman

3
Tôi nghi ngờ nó tốt cho hiệu năng và mật độ dữ liệu, mặc dù nó có thể có lợi cho kích thước mã. Nói chung, tôi sẽ gọi nó là một tính năng sai cố ý (hoặc ít nhất là thông qua).
Ded repeatator

3
"Dường như với tôi một giới hạn được áp đặt để duy trì một thư viện tài nguyên thấp, kích thước nhỏ thường được sử dụng cho hệ thống nhúng yêu cầu hiệu năng thời gian thực ..." Tôi không thể tưởng tượng một loại kiểm tra là bất cứ thứ gì nhiều hơn một giọt trong nhóm hiệu suất thời gian / không gian cho các hoạt động thực hiện bất kỳ số lượng IO đĩa nào. Ngoài ra, họ phải có các kiểm tra bổ sung trong mã vì họ không thể đơn giản cho rằng dữ liệu sẽ có kích thước cố định, do đó, có thể cho rằng việc gõ động khiến bạn phải trả giá.
Doval

1
@DocBrown Không phải vì tôi nói vậy mà vì đó là sui tướng .
Tulains Córdova

2
@ user61852 Tôi khuyên bạn nên viết lại câu hỏi hoàn toàn và tập trung vào việc gõ động của SQLite có mang lại lợi ích hiệu suất hay không và bỏ qua bất kỳ đề cập nào về tính năng / phân biệt lỗi hoặc tính hữu dụng / vô dụng chung của việc gõ động trong ngữ cảnh X hoặc Y.
Doval

Câu trả lời:


8

Không, gõ động đòi hỏi cả không gian lưu trữ và thời gian xử lý nhiều hơn, đặc biệt là vì chúng cũng thêm ái lực kiểu, nghĩa là nó có kiểu ưa thích mà lập trình viên có thể bỏ qua. Nó thực sự là một tính năng có chủ ý với chi phí đánh đổi thực sự. Các chi phí đó không đáng kể cho các trường hợp sử dụng các mục tiêu SQLite, nhưng chúng vẫn còn đó.

Sự hữu ích của các tính năng như vậy rất khó thấy vì bạn không quen với việc có sẵn nó cho bạn. Cách giải quyết cho sự thiếu sót của nó cảm thấy tự nhiên hơn với bạn bây giờ. Do kinh nghiệm trước đây của bạn, bạn nghĩ về nó như một trường INTEGER sẽ không bao giờ là bất cứ điều gì khác, nhưng SQLite coi nó là một trường thuộc bất kỳ loại nào, nhưng có lẽ hầu hết sẽ chứa các số nguyên. Có lẽ đó là mã ZIP cho một công ty chủ yếu kinh doanh tại Mỹ, nhưng có một số ít khách hàng Canada. Cho phép người dùng chỉ định một mối quan hệ số nguyên sẽ tiết kiệm rất nhiều không gian so với việc biến nó thành một chuỗi trong mỗi hàng, nhưng vẫn cung cấp cho bạn tùy chọn đó.


3
Tôi đã viết một bản cập nhật cho câu hỏi của tôi về việc lưu trữ thành công chuỗi "QUÁ NHIỀU" vào một cột số. Chuyển đổi tự động sẽ chèn không. Ngoài ra đây là triển khai cơ sở dữ liệu quan hệ đầu tiên mà tôi biết sẽ cho phép điều đó. Tôi đã làm việc với MSSQLServer, Oracle, PostgreSQL, MySQL, MS Acces, DBase, Foxbase, COBOL và Sybase SQL ở mọi nơi.
Tulains Córdova

2
Tôi không hiểu bình luận của bạn. Không có gì về câu trả lời của tôi có liên quan đến chuyển đổi tự động.
Karl Bielefeldt

1
SQLite coi chúng là các lớp lưu trữ thay vì kiểu dữ liệu. sqlite.org/datatype3.html
JeffO

1
Được khuyến khích vì được viết rõ ràng, nhưng bạn đang bỏ qua các vấn đề mà nguyên nhân này gây ra trong việc chứng minh tính chính xác của dữ liệu. Bạn không thể rút một số số nguyên ra khỏi DB của mình và cho rằng chúng sẽ là số nguyên. ("Gõ động" cực kỳ mâu thuẫn với chính mô hình quan hệ thực tế .)
Wildcard

1
Chi phí bỏ qua việc gõ hoàn toàn cao hơn nhiều so với một ít không gian lưu trữ và thời gian xử lý.
DeadMG
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.