Tại sao truy vấn vị trí lại xấu?

Question

Tôi đang đọc CJ Ngày của SQL and Relational Theory: How to Write Accurate SQL Code, và ông làm cho các trường hợp đó truy vấn vị trí là xấu — ví dụ, INSERT này:

INSERT INTO t VALUES (1, 2, 3) 

Thay vào đó, bạn nên sử dụng các truy vấn thuộc tính dựa trên như thế này:

INSERT INTO t (one, two, three) VALUES (1, 2, 3) 

Bây giờ, tôi hiểu rằng truy vấn đầu tiên không phù hợp với mô hình quan hệ vì các bộ (hàng) là các tập hợp thuộc tính (cột) không theo thứ tự. Tôi đang gặp khó khăn khi hiểu nơi có hại trong truy vấn đầu tiên. Ai đó có thể giải thích điều này với tôi?

Answer 1

Truy vấn đầu tiên ngắt bất kỳ lúc nào lược đồ bảng thay đổi. Truy vấn thứ hai chứa bất kỳ thay đổi lược đồ nào để lại các cột của nó nguyên vẹn và không thêm các cột mặc định.

Những người làm SELECT * truy vấn và sau đó dựa vào ký hiệu vị trí để trích xuất các giá trị mà chúng quan tâm là software maintenance supervillains vì cùng một lý do.

Answer 2

Tôi không thực sự quan tâm đến các khái niệm lý thuyết trong vấn đề này (như trong thực tế, một bảng không có thứ tự cột được xác định). Lý do chính tôi muốn thứ hai là thứ nhất là thêm lớp trừu tượng. Bạn có thể sửa đổi các cột trong một bảng mà không làm hỏng các truy vấn của mình.

Answer 3

Trong khi thứ tự các cột là được xác định trong giản đồ, thường không được coi là quan trọng vì nó không phải là khái niệm quan trọng.

Ngoài ra, điều đó có nghĩa là bất kỳ ai đọc phiên bản đầu tiên đều phải tham khảo lược đồ để tìm hiểu ý nghĩa của các giá trị đó. Phải thừa nhận rằng điều này giống như sử dụng các đối số vị trí trong hầu hết các ngôn ngữ lập trình, nhưng bằng cách nào đó SQL cảm thấy hơi khác biệt về mặt này - tôi chắc chắn sẽ hiểu phiên bản thứ hai dễ dàng hơn nhiều (giả sử các tên cột là hợp lý).

Answer 4

Bạn nên cố gắng thực hiện truy vấn SQL phụ thuộc vào bố cục chính xác của bảng càng ít càng tốt.

Truy vấn đầu tiên dựa trên bảng chỉ có ba trường và theo thứ tự chính xác đó. Bất kỳ thay đổi nào đối với bảng sẽ làm hỏng truy vấn.

Truy vấn thứ hai chỉ dựa vào đó là ba feld trong bảng và thứ tự của các trường không liên quan. Bạn có thể thay đổi thứ tự các trường trong bảng mà không vi phạm truy vấn và thậm chí bạn có thể thêm trường miễn là chúng cho phép giá trị null hoặc có giá trị mặc định.

Mặc dù bạn không sắp xếp lại bố cục bảng rất thường xuyên, việc thêm nhiều trường vào bảng là khá phổ biến.

Ngoài ra, truy vấn thứ hai dễ đọc hơn. Bạn có thể nói từ chính truy vấn những gì các giá trị được đặt trong bản ghi có nghĩa là gì.

Answer 5

SQL cung cấp cho bạn cú pháp để chỉ định tên của cột cho cả câu lệnh INSERT và SELECT. Bạn nên sử dụng điều này vì:

• Truy vấn của bạn ổn định với các thay đổi trong thứ tự cột, để bảo trì không hoạt động.
• Cột sắp xếp bản đồ tốt hơn với cách mọi người nghĩ, vì vậy nó dễ đọc hơn. Rõ ràng hơn khi nghĩ cột là cột "Tên" thay vì cột thứ 2.

Answer 6

Tôi thích sử dụng cú pháp CẬP NHẬT như:

INSERT t SET one = 1 , two = 2 , three = 3 

Đó là xa dễ dàng hơn để đọc và duy trì hơn cả các ví dụ.

Answer 7

Dài hạn, nếu bạn thêm một cột nữa vào bảng của mình, INSERT của bạn sẽ không hoạt động trừ khi bạn chỉ định rõ danh sách các cột. Nếu ai đó thay đổi thứ tự các cột, INSERT của bạn có thể âm thầm chèn thành công các giá trị vào các cột sai.

Answer 8

Điều chưa được đề cập đến là bạn sẽ thường xuyên có chìa khóa thay thế làm PK của mình, với auto_increment (hoặc một cái gì đó tương tự) để gán giá trị. Với cái đầu tiên, bạn phải chỉ định một cái gì đó ở đó — nhưng bạn có thể chỉ định giá trị nào nếu nó không được sử dụng? NULL có thể là một tùy chọn, nhưng điều đó không thực sự phù hợp khi xem xét PK sẽ được đặt thành NOT NULL.

Nhưng ngoài việc đó, toàn bộ "bị khóa vào một lược đồ cụ thể" là một lý do quan trọng hơn nhiều, IMO.

Answer 9

Tôi sẽ thêm một điều nữa, truy vấn thứ hai ít bị lỗi hoặc thậm chí trước khi bảng được thay đổi. Tại sao tôi lại nói vậy? Trở thành dạng seocnd bạn có thể (và nên khi bạn viết truy vấn) kiểm tra trực quan để xem các cột trong bảng chèn và dữ liệu trong mệnh đề values ​​hoặc select clause có đúng theo thứ tự bắt đầu không. Nếu không, bạn có thể kết thúc việc đưa số an sinh xã hội vào trường Honoraria một cách ngẫu nhiên và trả tiền cho SSN của họ thay vì số tiền họ cần cho một bài phát biểu (ví dụ không được chọn ngẫu nhiên, ngoại trừ chúng tôi đã nắm bắt nó trước khi nó thực sự xảy ra nhờ đó kiểm tra trực quan!).