Bạn có một số bảng khác nhau với tên cột và kiểu dữ liệu giống hệt nhau? Có mùi giống như một thiết kế tinh ranh.
Dù sao, chúng ta không thể sử dụng các biến làm đối tượng cơ sở dữ liệu trong SQL đơn giản như vậy. Chúng ta phải sử dụng SQL động.
PROCEDURE P_CUSTOMER_UPDATE
(
pADSLTable IN USER_TABLES.table_name%type,
pAccountname IN NVARCHAR2,
pStatus IN NUMBER,
pNote IN NVARCHAR2,
pEmail IN NVARCHAR2,
pMobi IN NVARCHAR2,
pServiceTypeID IN NUMBER,
pDate IN DATE
)
IS
BEGIN
execute immediate
'UPDATE '||pADSLTable
||' SET STATUS = :1, NOTE = :2, EMAIL = :3, MOBI = :4, SERVICETYPE_ID = :5, ACTIVATION_DATE = :6'
||' WHERE ACCOUNT_NAME = :7'
using pStatus, pNote, pEmail, pMobi, pServiceTypeID, pDate, pAccountname;
END;
Một lý do để tránh sử dụng SQL động là nó dễ bị lạm dụng. Những kẻ độc hại có thể sử dụng các tham số để cố gắng vượt qua bảo mật của chúng tôi. Đây được gọi là SQL injection. Tôi nghĩ rằng mọi người đã đánh giá quá mức tầm quan trọng của SQL injection. Nó không tự động là một mối đe dọa. Ví dụ:nếu thủ tục là một thủ tục riêng tư trong một gói (nghĩa là không được khai báo trong đặc tả) thì không có khả năng ai đó sẽ chiếm đoạt nó.
Nhưng nó là hợp lý để đề phòng. DBMS_ASSERT là một gói được giới thiệu trong Oracle 10g để bẫy các cuộc tấn công chèn SQL đã cố gắng. Trong trường hợp này, nó sẽ đáng sử dụng nó để xác thực tên bảng đã chuyển
....
'UPDATE '|| DBMS_ASSERT.simple_sql_name(pADSLTable)
....
Điều này sẽ ngăn không cho bất kỳ ai vượt qua 'pay_table set salary = salary * 10 where id = 1234 --'
làm tham số tên bảng.
Một lý do khác để tránh SQL động là nó khó đúng hơn và khó gỡ lỗi hơn. Cú pháp của câu lệnh thực tế chỉ được kiểm tra tại thời điểm chạy. Tốt nhất là có một bộ kiểm tra đơn vị hoàn chỉnh để xác nhận tất cả các đầu vào được thông qua, để đảm bảo rằng quy trình không có ngoại lệ cú pháp.
Cuối cùng, SQL động như vậy không hiển thị trong các dạng xem như ALL_DEPENDENCIES. Điều này làm cho việc phân tích tác động và định vị tất cả các chương trình sử dụng một bảng hoặc cột nhất định trở nên khó khăn hơn.