Chủ Nhật, 17 tháng 4, 2011

Tại sao tôi lại được khuyến cáo không sử dụng TRIGGER và PROCEDURE của MySQL?

Chào các bác,

Em mới vào Sài Gòn chưa được ít lâu. Hiện đang đi phỏng vấn xin việc. Được mấy công ty rồi, ở trong này cách họ truy vấn lúc phỏng vấn khá là khác biệt so với các công ty em đã làm ở ngoài Hà Nội. Đại khái em thấy họ tập chung vào các kinh nghiệm làm việc thực tế, hơn là lý thuyết chung chung. Đặc biệt là họ chỉ focus vào các yêu cầu của công việc, chẳng đoái hoài gì đến giá trị gia tăng gì sất (cũng hơi là lạ lúc đầu nhưng sau 3 lần phỏng vấn em cũng thấy quen rồi và cũng cho thế là hợp lý, tuyển PHP, MySQL thì sức đâu mà lo đến Java, Python... khác). Khi xin tuyển công ty khác thì em cũng sửa sửa, xóa xóa tùy theo yêu cầu tuyển dụng :D.
À quay lại chủ đề chính. Có một công ty em tuyển có trao đổi một đoạn như sau (với anh xếp Việt Kiều Úc, công ty KiSS Concept):

...

- Em đã  bao giờ sử dụng tính năng như TRIGGER, PROCEDURE trên các dự án của mình chưa?

- Chưa. Em được khuyến cáo là không sử dụng những tính năng đó của MySQL. Thay vì thế, dùng mã PHP.

- Tại sao vậy? Không phải việc của CSDL thì để cho CSDL làm chẳng phải sẽ nhanh hơn rất nhiều sao?

- Việc đó thì em nghĩ là đúng. Em cũng chưa từng tự hỏi vì sao họ lại khuyến cáo như vậy. Về phần em, cũng không thấy phiền hà lắm với việc xử lý tất cả trên PHP. Đôi khi còn rất hữu dụng nữa...

...

Về nhà em cũng suy nghĩ lại đoạn đó, vả cũng cố nghĩ ra một cách giải thích, các bác xem có hợp lý không nhé:

- Tất nhiên, khai thác triệt để các tính năng do CSDL mang lại là tốt nhất.

- Tuy nhiên khi phát triển các ứng dụng trên PHP và MySQL, các bác nhà ta thường chuẩn bị tư thế sẵn sàng cho việc ... vì lý do nào đó, thay đổi cơ sở dữ liệu sử dụng (từ MySQL sang Oracle chẳng hạn). Code tất cả các tính năng trong PHP giảm được sự phức tạp cho việc chuyển đổi này. Vì thế, MySQL chỉ được coi là thùng chứa dữ liệu, chứ các tính năng xử lý dựng sẵn không được coi trọng.

- Xử lý bằng PHP, về sau hệ thống cần phải chịu tải lớn, cần phải tối ưu hóa một số đoạn, việc refactor lại code sẽ dễ sàng hơn.

Có ai có thích giải thích khác không ạ? Các dự án mà các bác làm thì thế nào, có hay dùng TRIGGER & PROCEDURE của MySQL không? Trường hợp nào thì nên sử dụng TRIGGER & PROC?

7 nhận xét:

  1. Thanks all.

    Em có thêm vốn gió để chém rồi.

    TRIGGER & PROC có bao gồm việc xử lý các query một cách tuần tự chưa. Hay là nếu có vấn đề gì cần xử lý tuần tự (để tránh kết quả sai), em vẫn phải LOCK TABLES lại. LOCK TABLES có xài được với MyISAM không?

    Để nói rõ hơn, giả sử em có bảng Emails và bảng Domains. Em INSERT một email mới thì em phải đồng thời cập nhật số lượng DomainCounter trong bảng Domains lên 1. Tất nhiên là em có thể dùng truy vấn UPDATE SET DomainCounter = DomainCounter+1 hoặc dùng AUTOINCREMENT cho DomaniCounter (liên quan đến cái này em sẽ có một bài viết sau, khá là hay). Tuy nhiên nếu em dùng PROC & TRIGGER để làm việc này em có tránh được lỗi do concurrent requests không?

    Trả lờiXóa
  2. > TRIGGER & PROC có bao gồm việc xử lý các query một cách tuần tự chưa
    Chưa

    LOCK TABLES có xài được với MyISAM không?
    Myisam chỉ có lock table

    Trả lờiXóa
  3. [...] http://i-php.net/2011/04/tai-sao-toi-lai-duoc-khuyen-cao-khong-su-dung-trigger-va-procedure-cua-mysq... [...]

    Trả lờiXóa
  4. Bạn mới vào xem blog nên chắc không biết . Blog này là blog cộng đồng , ai cũng có thể join vào để viết . Người viết bài sự tàn lụi của php , công bằng mà nói thì nó không biết code php . :D

    Trả lờiXóa
  5. @TMQuang: Mình đồng ý, mọi thứ ra đời đều có lý do của nó, PROC thì rõ ràng là tối ưu hơn rồi.

    Tuy nhiên các dự án PHP thường có mặt trái của nó, ví dụ như ít dự án lớn có business với tính toán phức tạp mà thường là các dự án nhỏ (làm sao cũng được) hoặc lớn theo kiểu lấy thịt đè người (nhiều server, nhiều máy móc, nhiều công nghệ kết hợp). Theo mình với trường hợp dự án lớn như vậy, xài PROC có vẻ không hợp lý lắm. Nếu PROC của bạn chỉ là ... select thì không nói làm gì. Nhưng nếu có kèm theo business, đó chính là vấn đề. (xem lại các comments trước).

    Uhm, có ai đã so sánh tốc độ giữa PROC và SQL cho các trường hợp đọc/ghi chưa ấy nhỉ? Mình sẽ google thử xem sao.

    Trả lờiXóa
  6. á, bà chị này dìm hàng :((

    Trả lờiXóa
  7. Trần Ngọc Nhật17:21 8 tháng 9, 2011

    Cái vấn đề này là do một số người phát triển có quan điểm riêng của họ thôi các bạn ạ !
    Một ứng dụng thường có phân giao tiếp người dùng, phần xử lý và phần thao tác dữ liệu.
    Vì vậy chúng ta không nên cứ bắt một anh làm mệt nhọc còn anh thì không làm gì cả vì thế theo mình nghĩ đó chỉ là quan điểm của người phát triển thôi chúng ta có thể theo hoặc không theo họ quan trọng là mình phải biết nên vận dụng lúc nào là đúng và hợp lệ với ứng dụng của mình

    Trả lờiXóa