2013-07-27 27 views
10

Tôi đã sử dụng Symfony gần 2 năm nay, cho đến nay, mỗi dự án tôi xây dựng được triển khai cụ thể cho từng khách hàng (ví dụ một khách hàng, một cơ sở dữ liệu, một db).SAAS và Đa thuê trong Symfony2?

Cho phép nói rằng tôi có ứng dụng Quản lý dự án mà tôi muốn triển khai cho nhiều khách hàng. Giả sử khách hàng sẽ đi với bất cứ điều gì tính năng mà tôi xây dựng vào hệ thống, nếu tôi triển khai một codebase khác nhau (do đó, một db khác nhau) cho mỗi khách hàng, sau đây là những vấn đề tôi thấy trước:

  1. Đẩy sửa lỗi và nâng cấp sẽ rất đau đớn. Tôi cần phải đẩy nó vào mọi kho lưu trữ mà tôi đã triển khai. Nó sẽ không mở rộng nếu tôi có 50 khách hàng sử dụng cùng một ứng dụng đó.

  2. Quản lý rất đau đớn. Làm thế nào để xây dựng một hệ thống quản trị cho bản thân mình, nơi tôi có thể kéo TẤT CẢ các dự án vào một bảng HTML? Sau khi tất cả, mỗi khách hàng có cơ sở dữ liệu riêng của họ, phải không? Đối với tôi để làm bất cứ điều gì có ý nghĩa với tất cả các hồ sơ của tất cả các khách hàng của tôi, tôi cần một cách để xem xét thông qua tất cả các cơ sở dữ liệu của họ tại một đi, mà .. Tôi không nghĩ rằng Symfony cho phép. (Tôi không chắc chắn)

  3. Sự cố tài khoản người dùng. Nếu người dùng tình cờ làm việc cho nhiều công ty, tất cả họ đều sử dụng ứng dụng Quản lý dự án của tôi, người dùng đó phải đăng ký nhiều lần. (Tôi biết điều này có thể bị phá vỡ nếu tôi sử dụng oauth, nhưng tôi đang cố gắng không đến đó nếu tôi có thể)

Đây là các giải pháp mà tôi đã suy nghĩ và cố gắng ở một mức độ nhất định.


Giải pháp 1

Một cơ sở dữ liệu và một codebase cho TẤT CẢ các khách hàng của tôi. Các dự án sẽ đi theo một bảng, Hóa đơn đi dưới một bảng, tất cả được đánh dấu bởi client_id của riêng họ. Người dùng có thể được chỉ định cho các Dự án nên không cần phải đăng ký nhiều lần.

Điều này không khó để tạo. Nhưng, điều gì xảy ra nếu các khách hàng khác nhau cần các cột khác nhau cho Hóa đơn của họ? Bảng hóa đơn của tôi sẽ tiếp tục mở rộng (với các trường khác nhau mà các máy khách khác nhau muốn) và mỗi hàng có thể chứa nhiều trường rỗng. Chưa kể, thực thể hóa đơn của tôi sẽ phát triển trong kích thước tập tin, và tôi sẽ phải cập nhật database schema mỗi khi một tùy biến mới đến.


Giải pháp 2

Một cơ sở dữ liệu trong đó mỗi khách hàng có tiền tố bảng riêng của họ. Vì vậy, đối với khách hàng A, tôi có thể sử dụng clientA_projects, clientA_invoices, clientA_configuration, vv

Điều này là lý tưởng nếu mỗi khách hàng muốn tùy chỉnh các trường của họ. Nhưng, điều này có nghĩa là tôi cần phải tạo ra các thực thể mới và các lớp biểu mẫu cho mỗi khách hàng mới đi vào hệ thống? Dường như với giải pháp này, tôi cần cập nhật lược đồ cơ sở dữ liệu với mọi ứng dụng khách mới mà tôi nhận được.


Hiện tại, tôi đang thử nghiệm với cơ sở dữ liệu ít lược đồ (mongo và đi văng), mà không cần phải xác định trước lược đồ bảng, tôi có thể triển khai Giải pháp 1 mà không gặp rắc rối. Nhưng tôi vẫn đang thử nghiệm, và có nhiều cách để đi trước khi tôi dám triển khai một ứng dụng sản xuất sẵn sàng, không quen thuộc với các vấn đề của mongo và đi văng với Symfony.


Vì vậy, đây là nơi tôi bị kẹt. Là một lập trình viên tự đào tạo, tôi cảm thấy tôi có rất nhiều lỗ hổng trong kiến ​​thức của tôi rằng yêu cầu điền (trái ngược với một người nào đó từ một nền tảng CS). Không có nhiều nơi trên web nói về Symfony 2 và nhiều người thuê nhà (có thể tôi đang tìm kiếm điều sai). Nếu bất cứ ai có thể chỉ cho tôi một hướng rõ ràng hơn, có lẽ thực hành tốt nhất, dự án ví dụ, tôi sẽ thực sự đánh giá cao nó!

Btw, tôi dự định thực hiện điều này trong phiên bản mới nhất của Symfony (2.3.2 tại thời điểm này).

Cảm ơn bạn trước.

+0

@ Lu0-dezhang là có bất kỳ khả năng nào để bạn có thể chia sẻ kết quả của mình? Tôi đang bắt đầu một ứng dụng SaaS mới bằng cách sử dụng Symfony3 nhưng không có ý tưởng gì về cơ sở dữ liệu và tổ chức dự án Symfony3 cũng như vậy .... khó khăn? – ReynierPM

Trả lời

6

Tôi cũng đang sử dụng Symfony2 cho khoảng thời gian tương tự (vì một trong BETA) và tôi khuyên bạn nên đi với giải pháp # 1. Nếu bạn đang đi SaaS bạn không thể đưa ra mã cho khách hàng vì những lý do bạn đã viết (vấn đề với cập nhật/nâng cấp chủ yếu). Toàn bộ rắc rối sẽ là về quản lý người dùng - người dùng nào có quyền truy cập vào dữ liệu nào, thuộc về nhóm, công ty nào, v.v. Tất cả những thứ khác nếu được thực hiện đúng cách sẽ được mã hóa theo cách tương tự như người dùng. Bạn nên làm gì với các yêu cầu khác nhau cho các công ty khác nhau? Tạo các tính năng như vậy configurable. Bạn có thể thực hiện điều này trên mức độ khác nhau:

  • thực thể đơn giản thuộc tính: có một trường attributes trong mỗi bảng và lưu tất cả mọi thứ như JSON, YAML hoặc nội dung động-structurable khác,
  • cấu hình chung: có một nơi tổ chức cấu hình cơ bản được lưu trữ (trong phương tiện tôi đã viết ở trên) và cho phép người dùng quản lý các tính năng mới từ đó, tất cả các thay đổi được truyền cho các thực thể đơn giản,
  • thực hiện điều gì đó mà tôi gọi là Entity Parameters Pattern - bảng cơ sở dữ liệu thiết kế. các giá trị và mối quan hệ với các thực thể khác ở các mức khác nhau và sau đó thực hiện tham số có thể cấu hình chung các loại có thể được áp dụng cho bất kỳ nơi nào có ý nghĩa xác định trước. Ví dụ: "prefer_season" là thông số của loại "choice_string" chứa cấu hình "mùa xuân, mùa hè, mùa thu, mùa đông" và khi được gắn với thực thể nhất định sẽ luôn hiển thị trường <select> với các lựa chọn và lưu giá trị đã chọn có liên quan đến cả thực thể và loại thông số .

Ngoài ra giải pháp # 1 có một lợi thế cạnh tranh nhất - nó có thể xử lý nhiều hơn một công ty ngay cả khi bạn muốn đưa ra mã ở cuối. Bạn chỉ cần che dấu khả năng thêm nhiều hơn nữa. :)

Câu hỏi này được gắn thẻ Symfony2 nhưng thực sự không nên. Không quan trọng bạn đang sử dụng khung làm việc nào, bạn nên trừu tượng thiết kế ứng dụng của mình từ mã và sau đó sử dụng các khung làm công cụ đơn thuần để thực hiện công việc một cách suôn sẻ. Tôi muốn nói rằng ngay cả khi đưa câu trước vào tài khoản, tôi hoàn toàn trong tình yêu với Symfony2. :)

1

Tôi biết đây là câu hỏi cũ nhưng có thể hữu ích cho người khác.

Tôi đồng ý với @Tomasz và giải pháp # 1 với one database - tất cả người thuê trong một cơ sở dữ liệu. Vấn đề lớn nhất ở đây là thiết kế cơ sở dữ liệu thích hợp để giải quyết vấn đề an ninh hơn nữa: quyền truy cập tài nguyên phải được kiểm soát bởi ứng dụng để ngăn chặn truy cập trái phép giữa người thuê. Mặt khác, chúng tôi đã thực hiện dễ dàng vì chúng tôi đang triển khai một ứng dụng duy nhất chỉ với một cơ sở dữ liệu.

Nice bài viết về Symfony2 và chuyển sang SaaS mô hình: http://www.browserlondon.com/blog/2015/01/moving-to-a-saas-model-with-symfony2/

Cũng "phải đọc" bài viết về thiết kế cơ sở dữ liệu nền tảng SaaS - mẫu mà là nền tảng độc lập: http://labs.octivi.com/database-design-in-saas-platforms/

Các vấn đề liên quan