Mô hình dữ liệu đăng ký SaaS

SaaS (Software as a Service) là một trong ba thành phần chính của Điện toán đám mây. Thông thường, các ứng dụng SaaS dựa trên web và có thể xử lý nhiều người dùng khác nhau cùng một lúc. Các giải pháp dựa trên đăng ký là dịch vụ SaaS rất phổ biến. Một số sản phẩm SaaS nổi tiếng bao gồm Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe và (tất nhiên) Vertabelo! Hôm nay, chúng ta sẽ xem xét một mô hình dữ liệu cho phép chúng tôi quản lý các đăng ký SaaS.

Ý tưởng

Các sản phẩm của SaaS có thể rất khác biệt. Một số tính phí cho các dịch vụ của họ một cách thường xuyên, ví dụ:hàng tháng hoặc hàng năm; những người khác chỉ tính phí cho lượng thời gian hoặc tài nguyên được sử dụng (hoặc kết hợp cả hai). Để đơn giản hóa mọi thứ trong bài viết này, tôi sẽ chỉ tập trung vào đăng ký trả phí hàng tháng.

Giả sử rằng chúng tôi có một số giải pháp SaaS khác nhau và chúng tôi cần theo dõi tất cả người đăng ký của mình trong một cơ sở dữ liệu. Đây có thể là trường hợp chúng tôi cung cấp các giải pháp cơ sở dữ liệu (ví dụ:Amazon DynamoDB), các công cụ phân tích (ví dụ:Amazon Athena) hoặc các ứng dụng rô bốt (ví dụ:AWS RoboMaker). Trên thực tế, nếu chúng ta nhìn vào Amazon, chúng ta có thể thấy có rất nhiều ứng dụng khác nhau có sẵn. Chúng tôi sẽ chỉ chọn những thứ chúng tôi thực sự cần.

Mô hình dữ liệu

Mô hình bao gồm ba lĩnh vực chủ đề:

Users & groups
Software & plans
Subscriptions, plans & payments.

Chúng tôi sẽ mô tả từng lĩnh vực chủ đề này theo thứ tự chúng được liệt kê.

Phần 1:Người dùng và Nhóm

Users & groups khu vực chủ đề lưu trữ thông tin về tất cả người dùng ứng dụng của chúng tôi. Chúng tôi sẽ giả định rằng người dùng có thể được nhóm lại, ví dụ:khi một công ty muốn mua giấy phép cho một số nhân viên. Chúng tôi sẽ tạo một nhóm ngay cả khi chỉ có một người dùng thuộc về nhóm đó. Điều này sẽ giúp chúng tôi linh hoạt trong việc thêm các thành viên mới vào nhóm đó sau này.

Bảng quan trọng nhất ở đây là user_account bàn. Chúng tôi sẽ sử dụng nó để lưu trữ tất cả thông tin chi tiết liên quan đến tài khoản người dùng. Đây là:

first_name & last_name - Họ và tên của người dùng. Xin lưu ý rằng mỗi người dùng được lưu trữ ở đây là một cá nhân riêng tư.
user_name - Tên người dùng (do người dùng chọn).
password - Giá trị băm của mật khẩu của người dùng. (Người dùng đặt mật khẩu của riêng họ.)
email - Địa chỉ email của người dùng, được đặt trong quá trình đăng ký.
confirmation_code - Mã được sử dụng trong quá trình xác nhận email.
confirmation_time - Khi đăng ký / xác nhận hoàn tất.
insert_ts - Dấu thời gian khi bản ghi này được chèn lần đầu.

Người dùng có thể tạo nhóm; nhóm có các loại được xác định trước. Danh sách tất cả các loại nhóm có thể có được lưu trữ trong user_group_type bàn. Mỗi loại được định nghĩa BẤT NGỜ bởi type_name của nó . Chúng tôi cũng sẽ xác định số lượng thành viên nhóm tối thiểu và tối đa được phép cho mỗi loại nhóm. Phạm vi đó được xác định bằng hai giá trị - members_min (ranh giới dưới) và members_max (ranh giới trên).

Trong khi tạo tài khoản mới, người dùng cũng sẽ chọn nhóm người dùng của họ. Thao tác này sẽ tạo bản ghi mới trong user_group bảng tham chiếu đến loại nhóm đã chọn và lưu trữ dấu thời gian (insert_ts ) khi bản ghi này được chèn. customer_invoice_data thuộc tính là mô tả bằng văn bản về những gì chúng tôi sẽ in trên hóa đơn cho nhóm người dùng đó.

Bảng cuối cùng trong chủ đề này là in_group bàn. Đối với mỗi nhóm, chúng tôi sẽ lưu trữ danh sách tất cả các thành viên của nhóm đó. Bên cạnh các tham chiếu đến nhóm người dùng (user_group_id ) và tài khoản người dùng (user_account_id ), chúng tôi cũng sẽ lưu trữ dấu thời gian khi người dùng được thêm vào nhóm (time_added ) hoặc bị xóa khỏi nhóm (time_removed , sẽ chỉ chứa một giá trị nếu người dùng đã bị xóa). Chúng tôi cũng sẽ có cờ để biểu thị người dùng có phải là group_admin hay không hay không. Quản trị viên nhóm có thể cập nhật thành viên nhóm và thêm thành viên mới.

Phần 2:Phần mềm và Kế hoạch

Tiếp theo, chúng ta cần xác định mọi thứ chúng ta sẽ cung cấp cho khách hàng (tiềm năng) của mình. Chúng tôi có thể chỉ cung cấp một loại phần mềm, nhưng rất có thể chúng tôi sẽ có một số ưu đãi khác nhau. Một ví dụ phổ biến của trường hợp này là có một công cụ SaaS tách biệt với ứng dụng phân tích của nó, ví dụ:Sọc và Sọc Sigma. Chúng tôi sẽ đề cập đến những trường hợp như vậy trong mô hình dữ liệu của mình.

Chúng ta sẽ bắt đầu với software bàn. Trong từ điển này, chúng tôi sẽ lưu trữ danh sách tất cả các dịch vụ SaaS của chúng tôi. Đối với mỗi cái, chúng tôi sẽ lưu trữ:

software_name - Tên phần mềm DUY NHẤT.
details - Tất cả các chi tiết mô tả phần mềm đó.
access_link - Vị trí hoặc liên kết nơi chúng tôi có thể truy cập phần mềm đó.

Chúng tôi có thể cung cấp các giải pháp SaaS của mình trong một hoặc nhiều kế hoạch khác nhau. Mỗi kế hoạch có các tùy chọn khác nhau. Ví dụ:chúng tôi có thể có một gói cao cấp bao gồm tất cả các tùy chọn mà chúng tôi cung cấp và một gói cơ bản chỉ bao gồm những thứ cần thiết. Chúng tôi sẽ lưu trữ tất cả các gói riêng biệt trong plan bàn. Đối với mỗi gói, chúng tôi sẽ xác định:

plan_name - Tên chúng tôi đã chọn cho kế hoạch này. Cùng với việc tham khảo phần mềm (software_id ), điều này tạo thành khóa thay thế / DUY NHẤT của bảng này.
user_group_type_id - Tham chiếu biểu thị loại nhóm có thể sử dụng kế hoạch này. Đây có thể là một nhóm người dùng đơn lẻ hoặc một nhóm tiêu chuẩn. Tham chiếu này cũng xác định số lượng thành viên nhóm tối đa cho kế hoạch đó - ví dụ:nếu gói của chúng tôi cho phép năm tài khoản khác nhau trên một đăng ký, chúng tôi nên tham chiếu user_group_type thích hợp .
current_price - Giá hiện tại cho gói này.
insert_ts - Dấu thời gian khi bản ghi này được chèn.
active - Một lá cờ cho biết kế hoạch này có đang hoạt động hay không.

Chúng tôi đã đề cập rằng các kế hoạch cho cùng một phần mềm sẽ có các tùy chọn khác nhau. Danh sách tất cả các tùy chọn riêng biệt được lưu trữ trong option từ điển. Mỗi tùy chọn được xác định BẤT NGỜ bởi option_name của nó .

Để chỉ định các tùy chọn cho các gói khác nhau, chúng tôi sẽ sử dụng option_included bàn. Nó lưu trữ các tham chiếu đến gói liên quan (plan_id ) và tùy chọn (option_id ). Cặp này, cùng với date_added , tạo thành khóa DUY NHẤT của bảng này. date_removed thuộc tính sẽ chỉ chứa một giá trị nếu chúng tôi quyết định xóa một tùy chọn nhất định khỏi một kế hoạch. Điều này có thể xảy ra khi chúng tôi tạo một tùy chọn mới để thay thế tùy chọn cũ hoặc chúng tôi quyết định không có tùy chọn nhất định nữa vì ít người sử dụng nó.

Phần cuối cùng của chủ đề này liên quan đến các ưu đãi đặc biệt hoặc khuyến mại. Nhìn chung, những ưu đãi như vậy mang lại cho khách hàng nhiều dịch vụ hơn với ít tiền hơn và kéo dài trong một khoảng thời gian nhất định. Chúng có thể nhằm mục đích thu hút khách hàng mới hoặc bán các bản nâng cấp của gói (hoặc nhiều loại dịch vụ hơn) cho khách hàng hiện tại.

Tất cả các khuyến mại của chúng tôi được lưu trữ trong offer bàn. Đối với mỗi phiếu mua hàng, chúng tôi sẽ cần xác định:

offer_name - Tên DUY NHẤT mà chúng tôi đã chọn cho ưu đãi này.
offer_start_date và offer_end_date - Khoảng thời gian mà ưu đãi này khả dụng.
description - Mô tả chi tiết bằng văn bản về ưu đãi.
Giảm giá:Chúng tôi cần sự linh hoạt để có hai loại chiết khấu - chiết khấu dựa trên số tiền cố định (ví dụ:giảm giá $ 50) và chiết khấu theo phần trăm (ví dụ:tiết kiệm 25%). Nếu chúng tôi cung cấp một khoản chiết khấu cố định, chúng tôi sẽ chèn giá trị đó vào discount_amount thuộc tính; nếu chúng tôi cung cấp chiết khấu phần trăm, chúng tôi sẽ chèn phần trăm đó vào discount_percentage thuộc tính.
Thời lượng:Ở đây, chúng tôi sẽ sử dụng cùng một logic mà chúng tôi đã sử dụng để giảm giá. Trong một số trường hợp, ưu đãi sẽ kéo dài trong một số tháng xác định (ví dụ:trong 24 tháng sau khi khách hàng đăng ký); trong những trường hợp này, chúng tôi sẽ xác định duration_months giá trị. Các ưu đãi khác sẽ có hiệu lực cho đến một ngày cố định nhất định (ví dụ:đến ngày 31 tháng 12 năm 2019); đối với những điều này, chúng tôi sẽ xác định ngày và lưu trữ trong duration_end_date thuộc tính.

Chúng tôi sẽ sử dụng hai bảng còn lại trong chủ đề này để xác định những gì mỗi phiếu mua hàng có và những điều kiện tiên quyết mà nó có. Với mục đích này, chúng tôi sẽ sử dụng hai bảng:include và prerequisite . Chúng có cùng cấu trúc và chứa cùng một cặp offer_id DUY NHẤT - plan_id . Một số phiếu mua hàng có thể không có bất kỳ điều kiện tiên quyết nào, trong khi những phiếu mua hàng khác có thể - ví dụ:nếu chúng tôi đang giảm giá cho việc nâng cấp lên gói có nhiều người dùng hơn hoặc đăng ký phần mềm cho người dùng một số phần mềm khác.

Phiếu mua hàng có thể phức tạp, vì vậy tôi sẽ cung cấp một vài ví dụ.

Nếu chúng tôi hiện đang sử dụng Gói A và có đề nghị nâng cấp lên Gói B, thì việc này rất đơn giản.
Nếu chúng tôi có hai ưu đãi, "Kế hoạch A nâng cấp lên Kế hoạch B" và "Kế hoạch B nâng cấp lên Kế hoạch C", chúng tôi nên tạo thêm một đề nghị nữa:"Kế hoạch A nâng cấp trực tiếp lên Kế hoạch C". Điều này cho phép người dùng nâng cấp gói của họ trong một bước thay vì hai bước. Một ví dụ về việc nâng cấp như vậy là thay đổi gói đăng ký hiện cho phép năm người dùng trên mỗi nhóm thành một gói cho phép 20 người dùng mỗi nhóm mà không cần dừng lại ở gói trung gian, mười người dùng cho mỗi nhóm.
Nếu một nhóm sử dụng Sản phẩm A, chúng tôi có thể có ưu đãi đặc biệt để đăng ký Sản phẩm B và C với giá khuyến mãi. Chúng tôi cũng có thể có hai ưu đãi riêng biệt để chỉ đăng ký Sản phẩm B và chỉ đăng ký Sản phẩm C.

Nói chung, chúng ta nên có một phiếu mua hàng sẽ thay đổi gói hiện tại thành gói mong muốn mà không cần thực hiện bất kỳ bước nào giữa và chỉ một phiếu mua hàng đăng ký một hoặc nhiều sản phẩm mới.

Phần 3:Đăng ký, Gói và Thanh toán

Chủ đề cuối cùng kết nối hai lĩnh vực đã đề cập trước đó và là trung tâm thực sự của mô hình này.

Tất cả đăng ký được lưu trữ trong subscription bàn. Chúng tôi sẽ coi mỗi gói khác nhau là một gói đăng ký riêng biệt, ngay cả khi các gói / gói đăng ký này là kết quả của cùng một ưu đãi. Lý do cho điều này là vì vậy chúng tôi sẽ có thể quản lý các đăng ký một cách riêng biệt - ví dụ:hủy chúng một cách riêng biệt nếu chúng tôi muốn. Chúng tôi sẽ cần xác định một số chi tiết ở đây:

user_group_id - ID của nhóm đăng ký gói này. Điều này quan trọng vì người dùng sẽ không được đăng ký riêng lẻ; họ được đăng ký gián tiếp, như một phần của nhóm.
trial_period_start_date và trial_period_end_date - Giới hạn dưới và giới hạn trên của thời gian dùng thử (nếu có) cho gói đăng ký này.
subscribe_after_trial - Cờ cho biết đăng ký có được tự động gia hạn hay không sau khi thời gian dùng thử (nếu có) kết thúc.
current_plan_id - Gói hiện tại cho gói đăng ký đó. Nếu gói đăng ký không còn hoạt động, thuộc tính này sẽ chứa giá trị của gói hoạt động gần đây nhất.
offer_id - Tham chiếu đến ưu đãi mà đăng ký này có liên quan. Thuộc tính này sẽ chỉ chứa một giá trị nếu đăng ký này là kết quả của một ưu đãi nhất định.
offer_start_date và offer_end_date - Giới hạn dưới và giới hạn trên của khoảng thời gian ưu đãi này có hiệu lực. Các thuộc tính này sẽ chỉ được xác định nếu đăng ký này là kết quả của một ưu đãi nhất định.
date_subscribed - Khi nhóm này đăng ký gói đăng ký này.
valid_to - Ngày cuối cùng đăng ký này có hiệu lực. Trong trường hợp đăng ký hàng tháng, chúng tôi có thể mong đợi rằng valid_to sẽ được đặt vào cuối tháng hiện tại. Nếu khách hàng hủy đăng ký bất kỳ lúc nào trong tháng, họ vẫn có thể sử dụng phần mềm của mình cho đến cuối tháng đó.
date_unsubscribed - Ngày mà nhóm đó hủy đăng ký khỏi gói đăng ký này. Chúng tôi có thể mong đợi rằng ngày này sẽ được quản trị viên nhóm đặt theo cách thủ công khi nhóm quyết định không sử dụng dịch vụ nữa. Tuy nhiên, nó cũng có thể được đặt tự động, theo tiêu chí xác định trước - ví dụ:tự động hủy đăng ký một nhóm khỏi dịch vụ của họ nếu có hai hoặc nhiều hóa đơn chưa thanh toán.
insert_ts - Dấu thời gian khi bản ghi này được chèn.

Các gói đăng ký thường thay đổi theo thời gian. Để duy trì lịch sử đầy đủ về tất cả các gói của chúng tôi, chúng tôi sẽ lưu trữ tất cả các thay đổi của gói trong plan_history bàn. Đối với mỗi bản ghi ở đây, chúng tôi sẽ cần:

subscription_id - ID của đăng ký liên quan.
plan_id - ID của kế hoạch liên quan.
date_start và date_end - Khoảng thời gian khi kế hoạch này hoạt động.
insert_ts - Dấu thời gian khi bản ghi này được chèn.

Bảng cuối cùng trong mô hình của chúng tôi sẽ lưu trữ invoices . Đối với mỗi hóa đơn, chúng tôi sẽ giữ các chi tiết sau:

customer_invoice_data - Mô tả về khách hàng được lập hóa đơn này. Đây sẽ là dữ liệu từ u ser_group.customer_invoice_data tại thời điểm hóa đơn được tạo.
subscription_id - ID của đăng ký liên quan.
plan_history_id - ID của gói hoạt động trong khoảng thời gian lập hóa đơn này.
invoice_period_start_date và invoice_period_end_date - Khoảng thời gian (ví dụ:từ ngày 1 tháng 1 năm 2019 đến ngày 31 tháng 1 năm 2019) trong hóa đơn này.
invoice_description - Mô tả ngắn gọn bằng văn bản của hóa đơn.
invoice_amount - Số tiền đến hạn thanh toán cho hóa đơn này.
invoice_created_ts - Khi hóa đơn này được tạo và đưa vào bảng.
invoice_due_ts - Khi hóa đơn này đến hạn thanh toán.
invoice_paid_ts - Dấu thời gian khi hóa đơn này được thanh toán.

Hãy cho chúng tôi biết Bạn nghĩ gì về Mô hình Dữ liệu SaaS

Tôi đoán rằng hầu hết các bạn đã gặp SaaS, với tư cách là nhà phát triển hoặc người dùng. Tôi rất mong được bạn thực hiện và trên mô hình dữ liệu này. Vui lòng chia sẻ kinh nghiệm và đề xuất của bạn trong phần bình luận bên dưới.