thảo luận 2022 rồi, đừng dùng store procedure nữa

1. Tự nhiên business logic bị đẩy xuống 2 chỗ, 1 trên code và 1 ở store
2. cực kì khó maintain, debug
3. Tốc độ ef core 6 ~ 95% store
4. Khó tối ưu, phải hiểu sâu
 
Anh lead nào của thanh niên này chắc hàng ngày phát điên mất nhỉ
qZV215Z.png
 
Xử lý batch và không cần kết quả ngay lập tức thì dùng orm làm gì?
Lôi cả triệu row lên ram tính toán kiểu gì?

Ngược lại, với 1 số business khác thì dùng code ở application tiện lợi hơn SP
 
Cty bên mình thì bắt buộc viết store hết, ko đc phép query thẳng. User cho service
xài phân quyền chỉ đc phép gọi store, ko đc thực thi query cũng như ko view đc cấu trúc db. Các store khi gọi phải truyền vào 1 id đã bị mã hoá (sinh ra từ store authen với tham số là username và pass của người dùng), nếu id không hợp lệ thì store ko trả dữ liệu. Đó là cách chống crawl dữ liệu của tổng cty bên US.
 
Tôi cũng prefer stored procedure hơn, ngoài chuyện batch data là chắc chắn phải xài stored procedure rồi thì dùng stored procedure có cái lợi là query execution plan sẽ được cache ở database ko phải build lại execution plan chứ còn truyền thẳng từ Entity Framework xuống thì chậm hơn nhiều.

Mà thật ra tôi lại có thiên hướng dẹp bỏ luôn cả Entity Framework, xài mấy cái như Dapper để map query result thôi. :ah:
 
Last edited:
Cty bên mình thì bắt buộc viết store hết, ko đc phép query thẳng. User cho service
xài phân quyền chỉ đc phép gọi store, ko đc thực thi query cũng như ko view đc cấu trúc db. Các store khi gọi phải truyền vào 1 id đã bị mã hoá (sinh ra từ store authen với tham số là username và pass của người dùng), nếu id không hợp lệ thì store ko trả dữ liệu. Đó là cách chống crawl dữ liệu của tổng cty bên US.

Crawl ở tầng db ntn v bác

Gửi từ Samsung SM-A507FN bằng vozFApp
 
vì lý do nào đó layer service bị thủng, kẻ xấu lấy đc cấu hình -> có thông tin để tương tác đc với DB, dùng thông tin đó để query full data.

Vd ngay cả mình trong team, khi dev, dùng acc/pass của mình gọi store getitems() trên server test thì cũng chỉ thấy đc tập data test của mình thôi chứ ko thể thấy đc hết dữ liệu như cách truyền thống. Còn khi dùng acc/pass của mình để gọi store adduser() thì bị denie ngay. Nói chung có thông tin để connect đc tới db cũng ko làm đc gì nhiều.

Theo CTO bên US nói thì để lấy đc full thì cần các điều kiện:
  • Chạy công cụ trên lớp mạng access đc tới cluster DB.
  • User/pass db để truy cập đc vào DB.
  • Hiểu đc logic của hệ thống do acc db trên khi dùng tool quản trị để connect vô db thì sẽ ko thấy đc cấu trúc của db (table, store, function, ...), ko chạy trực tiếp đc sql query.
  • User/pass người dùng để authen với store authen.
  • User/pass người dùng này phải có quyền cao để có thể thấy đc mọi items.
 
Last edited:
Nói chung là tuỳ vào hệ thống, mức độ bảo mật... thì mới quyết định được nên dùng sp hay business logic ở service. Mỗi cái có ưu điểm vs khuyết điểm riêng. Thường mấy hệ thống liên quan đến tiền là đều sp hết. Nhưng mình cũng ghét debug những cái sp cả mấy k dòng, maintain vs deploy khổ. 😅

via theNEXTvoz for iPhone
 
Nói chung là tuỳ vào hệ thống, mức độ bảo mật... thì mới quyết định được nên dùng sp hay business logic ở service. Mỗi cái có ưu điểm vs khuyết điểm riêng. Thường mấy hệ thống liên quan đến tiền là đều sp hết. Nhưng mình cũng ghét debug những cái sp cả mấy k dòng, maintain vs deploy khổ. 😅

via theNEXTvoz for iPhone
cty mình bên tài chính 😁 có 1 team chuyên viết sp luôn, nghe đâu cũng chục nhân sự, bên tổng cty ở US. Team dev ở VN ko biết đc cấu trúc db thế nào luôn, toàn gọi sp theo doc thôi 😅
 
vì lý do nào đó layer service bị thủng, kẻ xấu lấy đc cấu hình -> có thông tin để tương tác đc với DB, dùng thông tin đó để query full data.

Vd ngay cả mình trong team, khi dev, dùng acc/pass của mình gọi store getitems() trên server test thì cũng chỉ thấy đc tập data test của mình thôi chứ ko thể thấy đc hết dữ liệu như cách truyền thống. Còn khi dùng acc/pass của mình để gọi store adduser() thì bị denie ngay. Nói chung có thông tin để connect đc tới db cũng ko làm đc gì nhiều.

Theo CTO bên US nói thì để lấy đc full thì cần các điều kiện:
  • Chạy công cụ trên lớp mạng access đc tới cluster DB.
  • User/pass db để truy cập đc vào DB.
  • Hiểu đc logic của hệ thống do acc db trên khi dùng tool quản trị để connect vô db thì sẽ ko thấy đc cấu trúc của db (table, store, function, ...), ko chạy trực tiếp đc sql query.
  • User/pass người dùng để authen với store authen.
  • User/pass người dùng này phải có quyền cao để có thể thấy đc mọi items.
User/ pass do admin phân quyền, thiếu yếu tố này coi như mù rồi còn đâu.
Còn nếu hack được cả admin rồi thì những cái trên dư ah?
Có cái số 1 là phần network thì ko liên quan admin DB.
Hiểu vậy ko biết có đúng ko?
 
User/ pass do admin phân quyền, thiếu yếu tố này coi như mù rồi còn đâu.
Còn nếu hack được cả admin rồi thì những cái trên dư ah?
Có cái số 1 là phần network thì ko liên quan admin DB.
Hiểu vậy ko biết có đúng ko?
2 bộ phận khác nhau, dba và Dev

Dba bị hack thì ko liên quan tới dev. Kệ cụ nhà nó.
 
1. Tự nhiên business logic bị đẩy xuống 2 chỗ, 1 trên code và 1 ở store
2. cực kì khó maintain, debug
3. Tốc độ ef core 6 ~ 95% store
4. Khó tối ưu, phải hiểu sâu

0. Không khi được log, không có request/thread context...

Sent from Samsung SM-G973F using vozFApp
 
Back
Top