Tóm lại, tôi sẽ đồng ý với CTO của bạn. Bạn có thể đã đạt được một số hiệu suất với chi phí khả năng mở rộng (nếu các điều khoản đó gây nhầm lẫn, tôi sẽ làm rõ bên dưới). Hai lo lắng lớn nhất của tôi sẽ là khả năng duy trì và thiếu các tùy chọn để mở rộng theo chiều ngang (giả sử bạn sẽ cần điều đó).
Sự gần gũi với dữ liệu: Hãy lùi lại một bước. Có một số lý do tốt để đẩy mã vào DB. Tôi sẽ lập luận rằng cái lớn nhất sẽ là sự gần gũi với dữ liệu - ví dụ: nếu bạn đang mong đợi một phép tính trả về một số giá trị, nhưng đây là tổng hợp của hàng triệu bản ghi, gửi hàng triệu bản ghi (theo yêu cầu) mạng được tổng hợp ở nơi khác rất lãng phí và có thể dễ dàng giết chết hệ thống của bạn. Đã nói điều này, bạn có thể đạt được sự gần gũi của dữ liệu này theo những cách khác, về cơ bản là sử dụng bộ nhớ cache hoặc phân tích DB trong đó một số tổng hợp được thực hiện trước.
Hiệu suất của mã trong DB:Các hiệu ứng hiệu suất thứ cấp, chẳng hạn như "lưu trữ các kế hoạch thực hiện" khó tranh luận hơn. Đôi khi, các kế hoạch thực hiện được lưu trữ có thể là một điều rất tiêu cực, nếu kế hoạch thực hiện sai được lưu trữ. Tùy thuộc vào RDBMS của bạn, bạn có thể tận dụng tối đa những thứ này, nhưng bạn sẽ không nhận được nhiều hơn SQL, trong hầu hết các trường hợp (các gói đó cũng thường được lưu vào bộ đệm). Tôi cũng sẽ lập luận rằng hầu hết các ngôn ngữ được biên dịch hoặc JIT'ed thường hoạt động tốt hơn các ngôn ngữ tương đương SQL của chúng (như T-SQL hoặc PL / SQL) cho các hoạt động cơ bản và lập trình không liên quan (thao tác chuỗi, vòng lặp, v.v.), vì vậy bạn sẽ Sẽ không mất bất cứ thứ gì ở đó, nếu bạn đã sử dụng một cái gì đó như Java hoặc C # để thực hiện việc bẻ số. Tối ưu hóa chi tiết cũng khá khó khăn - trên DB, bạn ' thường bị mắc kẹt với một cây B (chỉ mục) chung làm cấu trúc dữ liệu duy nhất của bạn. Công bằng mà nói, một phân tích đầy đủ, bao gồm những thứ như có các giao dịch chạy dài hơn, khóa leo thang, v.v., có thể lấp đầy sách.
Khả năng bảo trì: SQL là một ngôn ngữ tuyệt vời cho những gì nó được thiết kế để làm. Tôi không chắc nó phù hợp với logic ứng dụng. Hầu hết các công cụ và thực hành làm cho cuộc sống của chúng ta có thể chịu được (TDD, tái cấu trúc, v.v.) rất khó áp dụng cho lập trình cơ sở dữ liệu.
Hiệu suất so với khả năng mở rộng:Để làm rõ các điều khoản này, ý tôi là: hiệu suất là mức độ nhanh chóng mà bạn mong đợi một yêu cầu sẽ đi qua hệ thống của bạn (và quay lại với người dùng), trong thời điểm này giả sử tải thấp. Điều này thường sẽ bị giới hạn bởi những thứ như số lớp vật lý mà nó trải qua, mức độ tối ưu của các lớp đó, v.v. Khả năng mở rộng là cách hiệu suất thay đổi khi tăng số lượng người dùng / tải. Bạn có thể có hiệu suất trung bình / thấp (giả sử, 5 giây + cho một yêu cầu), nhưng khả năng mở rộng tuyệt vời (có thể hỗ trợ hàng triệu người dùng). Trong trường hợp của bạn, bạn có thể sẽ trải nghiệm hiệu năng tốt, nhưng khả năng mở rộng của bạn sẽ bị giới hạn bởi mức độ lớn của một máy chủ mà bạn có thể xây dựng. Tại một số điểm, bạn sẽ đạt đến giới hạn đó và buộc phải chuyển sang những thứ như shending, điều này có thể không khả thi tùy thuộc vào bản chất của ứng dụng.
Tối ưu hóa sớm: Cuối cùng, tôi nghĩ bạn đã phạm sai lầm khi tối ưu hóa sớm. Như những người khác đã chỉ ra, bạn không thực sự có các phép đo cho thấy các phương pháp khác sẽ hoạt động như thế nào. Chà, chúng ta không thể luôn xây dựng các nguyên mẫu toàn diện để chứng minh hoặc bác bỏ một lý thuyết ... Nhưng nói chung, tôi luôn do dự khi chọn một phương pháp tiếp cận khả năng duy trì (có thể là chất lượng quan trọng nhất của ứng dụng) để thực hiện .
EDIT: Trên một lưu ý tích cực, tỷ lệ dọc có thể kéo dài khá xa trong một số trường hợp. Theo tôi biết, SO đã chạy trên một máy chủ trong một thời gian khá dài. Tôi không chắc nó phù hợp với tối đa 10.000 người dùng của bạn như thế nào (tôi đoán nó sẽ phụ thuộc vào bản chất của những gì họ đang làm trong hệ thống của bạn), nhưng nó cho bạn ý tưởng về những gì có thể được thực hiện (thực tế, có rất nhiều ví dụ ấn tượng hơn, điều này chỉ là một người phổ biến có thể dễ dàng hiểu được).
EDIT 2: Để làm rõ và nhận xét về một số điều nêu ra ở nơi khác:
- Re: Tính nhất quán nguyên tử - Tính nhất quán ACID cũng có thể là một yêu cầu của hệ thống. Ở trên không thực sự tranh luận về điều đó và bạn nên nhận ra rằng tính nhất quán của ACID không yêu cầu bạn phải chạy tất cả logic kinh doanh của mình bên trong DB. Bằng cách di chuyển mã không cần có trong DB, bạn buộc nó phải chạy trong môi trường vật lý của phần còn lại của DB - nó cạnh tranh cho cùng một tài nguyên phần cứng như phần quản lý dữ liệu thực tế của DB. Đối với việc chỉ mở rộng mã ra các máy chủ DB khác (chứ không phải dữ liệu thực tế) - chắc chắn, điều này có thể là có thể , nhưng chính xác thì bạn đạt được gì ở đây, ngoài chi phí cấp phép bổ sung trong hầu hết các trường hợp? Giữ những thứ không cần phải có trên DB, tắt DB.
- Re: hiệu năng SQL / C # - vì đây có vẻ là một chủ đề được quan tâm, chúng ta hãy thêm một chút vào cuộc thảo luận. Bạn chắc chắn có thể chạy mã gốc / Java / C # bên trong DB, nhưng theo tôi biết, đó không phải là điều đang được thảo luận ở đây - chúng tôi đang so sánh việc triển khai mã ứng dụng điển hình trong một cái gì đó như T-SQL so với C #. Trước đây, có một số vấn đề khó giải quyết với mã quan hệ - ví dụ: hãy xem xét vấn đề "đăng nhập đồng thời tối đa", trong đó bạn có các bản ghi chỉ ra đăng nhập hoặc đăng xuất và thời gian, và bạn cần tìm ra cái gì số lượng người dùng tối đa đăng nhập bất cứ lúc nào là. Giải pháp đơn giản nhất có thể là lặp qua các bản ghi và tiếp tục tăng / giảm bộ đếm khi bạn gặp thông tin đăng nhập / đăng xuất và theo dõi tối đa giá trị này.có thể, Tôi không biết), điều tốt nhất bạn có thể làm là HIỆN TẠI (các giải pháp quan hệ thuần túy hoàn toàn theo các mức độ phức tạp khác nhau và cố gắng giải quyết bằng cách sử dụng vòng lặp while dẫn đến hiệu suất kém hơn). Trong trường hợp này, vâng, giải pháp C # thực sự nhanh hơn những gì bạn có thể đạt được trong T-SQL, giai đoạn. Điều đó có vẻ xa vời, nhưng vấn đề này có thể dễ dàng xuất hiện trong các hệ thống tài chính, nếu bạn đang làm việc với các hàng biểu thị các thay đổi tương đối và cần tính toán các tổng hợp cửa sổ trên các hệ thống đó. Các yêu cầu của Proc được lưu trữ cũng có xu hướng đắt hơn - gọi một SP tầm thường một triệu lần và xem cách so sánh với việc gọi hàm C #. Tôi đã gợi ý một vài ví dụ khác ở trên - Tôi chưa gặp ai thực hiện bảng băm thích hợp trong T-SQL (một ví dụ thực sự mang lại một số lợi ích), trong khi điều này khá dễ thực hiện trong C #. Một lần nữa, có những thứ mà DB tuyệt vời và những thứ mà chúng không tuyệt vời lắm. Giống như tôi sẽ không muốn thực hiện THAM GIA, SUM và NHÓM NHÓM trong C #, tôi không muốn viết bất cứ điều gì đặc biệt về CPU trong T-SQL.