Mỗi cấu trúc là một cam kết
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Chương 3 của Data Architect, Phần 1: Trở thành kiến trúc sư dữ liệu. Trước: Mô hình hóa dữ liệu vì ý nghĩa.
Đây là câu hỏi tôi đặt ra ở mọi lớp học. Nếu ai đó nói “Tôi làm việc với Salesforce”, thì tên API của đối tượng sản phẩm là gì?
Đó là Product2. Đó là phép thử đầu tiên của tôi. Ở một thời điểm nào đó, Salesforce đã xây đối tượng sản phẩm, nhận ra nó không ổn và phải bỏ nó lại phía sau. Họ không thể cứ thế gỡ nó đi, nên họ thêm Product2. Ngay cả Salesforce cũng phải sống với những cấu trúc cũ của mình.
Salesforce cũng chừa cho mình chỗ để phát triển. Các đối tượng chuẩn của họ không mang tiền tố hay hậu tố nào, và chúng ta, những người tùy chỉnh org, không bao giờ chiếm được khoảng không gian đó. Vì vậy Salesforce có thể tiếp tục thêm đối tượng mà không bao giờ xung đột với bất cứ thứ gì chúng ta xây.
Bài học ở đây là: tạo một đối tượng mất mười phút. Sống với nó mất nhiều năm. Mỗi đối tượng và mỗi trường bạn thêm vào là một cam kết. Nó chiếm dung lượng lưu trữ. Nó dính vào các giới hạn. Nó có một mô hình chia sẻ, dù bạn có thiết kế hay không. Nó cần một giấy phép cho mỗi người chạm vào nó. Và giờ AI cũng đọc nó, nên cách bạn đặt tên và mô tả nó quyết định một tác tử hiểu gì về dữ liệu của bạn. Thêm vào thì dễ. Bỏ đi thì khó.
Chương này biến các khối xây dựng của Salesforce thành những quyết định.
Hình ảnh được tạo bằng AI.
Các cấu trúc trong nháy mắt
Phần tiêu đề “Các cấu trúc trong nháy mắt ”Salesforce cho bạn sáu nơi để chứa dữ liệu. Tôi đặt chúng trên một slide, vì việc đầu tiên là biết tất cả chúng đều tồn tại:
| Cấu trúc | Dùng để làm gì | Điểm cần lưu ý |
|---|---|---|
| Đối tượng chuẩn | Mô hình của chính Salesforce: Tài khoản, Liên hệ, Cơ hội, Trường hợp, Tài sản và các đối tượng khác | Hãy dùng chúng đúng mục đích, nếu không chúng sẽ chống lại bạn |
| Đối tượng tùy chỉnh | Dữ liệu nghiệp vụ của riêng bạn | Dễ tạo, khó cho nghỉ hưu |
| Đối tượng bên ngoài | Dữ liệu nằm trong một hệ thống khác, được hiển thị trong Salesforce | Mỗi lần chạm vào là một lời gọi ra ngoài (callout) |
| Đối tượng lớn | Khối lượng khổng lồ bạn phải giữ nhưng hiếm khi mở ra | Không có giao diện hay báo cáo chuẩn; bạn truy vấn qua chỉ mục |
| Tệp | Tài liệu, ảnh và nội dung khác | Dung lượng lưu trữ tệp tăng nhanh |
| Tệp đính kèm | Cách lưu tệp kiểu cũ | Kế thừa: hãy dùng Tệp |
Chọn một cấu trúc chỉ là một phần. Trước cấu trúc là câu hỏi dữ liệu nên nằm ở đâu: trên lõi, được tham chiếu ở nơi nó đang nằm, hay được lưu trữ.
Lộ trình qua chương này
Phần tiêu đề “Lộ trình qua chương này ”Chương này lớn, nên được chia làm mười phần. Mỗi phần có thể đọc độc lập. Ở chương 2 chúng ta quyết định mô hình nên là gì; ở đây chúng ta quyết định nó nên sống trên Salesforce thế nào.
- Nền tảng dữ liệu Salesforce: hơn cả một cơ sở dữ liệu. Điều gì làm Salesforce khác biệt, và vì sao nền tảng có hình dạng của nó.
- Hãy nhìn về phi thuyền mẹ: các mô hình dữ liệu chuẩn. Các mô hình Sales và Service mà Salesforce đã xây sẵn, tệp, dung lượng lưu trữ và tài khoản cá nhân.
- Tự xây dựng: các đối tượng tùy chỉnh. Màn hình tạo đối tượng tùy chỉnh mới quyết định những gì, những trường bạn không tạo ra, và cách đọc bất kỳ tên API nào: chuẩn, tùy chỉnh hay gói được quản lý.
- Dữ liệu này nằm ở đâu? Trên lõi, tham chiếu hay lưu trữ, được quyết định trước khi tạo bất kỳ đối tượng nào.
- Chọn đúng đối tượng. Phép thử phù hợp trọn vẹn, những gánh nặng mà đối tượng chuẩn mang theo, tài khoản cá nhân, và các giấy phép quyết định người dùng được dùng gì.
- Trường cũng là kiến trúc. Từng loại trường một, những hành vi khiến người ta bất ngờ, và vì sao mọi trường đều cần một mô tả.
- Quan hệ có hệ quả. Tra cứu hay chính-chi tiết, sâu ba cấp và rộng hai cha, đối tượng nối logic và đối tượng nối của Salesforce (Salesforce Junction Object), và những giới hạn gây hậu quả.
- Quyền sở hữu và vòng đời. Ai sở hữu một bản ghi, bảng chia sẻ nơi quyền sở hữu trở thành quyền truy cập, và điều gì xảy ra với một bản ghi trong suốt vòng đời.
- Giữ dữ liệu nhất quán. Bậc thang nhất quán: mỗi lớp đều có giá, và bạn không bao giờ “sửa” lịch sử để thỏa mãn một quy tắc mới.
- Thiết kế mô hình vật lý Salesforce. Một lát cắt của Steve Trucking, từ mô hình logic đến Salesforce, được xây dần từng bước, kèm lập luận.
Khi học xong, hãy tự kiểm tra với hướng dẫn ôn tập của chương: một danh sách kiểm tra cho kỳ thi, những thói quen vượt ra ngoài kỳ thi, các thuật ngữ cần biết và vài câu hỏi.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Những gì Salesforce đã mô hình hóa sẵn, trước khi phát minh bất cứ thứ gì: hãy nhìn về phi thuyền mẹ.
- Mỗi loại dữ liệu nằm ở đâu, trên lõi, tham chiếu hay lưu trữ, trước khi chọn một cấu trúc.
- Cấu trúc nào chứa nó, biết rõ mỗi cấu trúc từ bỏ điều gì.
- Các đối tượng liên quan với nhau thế nào, ai sở hữu các bản ghi, và điều đó có ý nghĩa gì với quyền truy cập và quy mô.
- Mô hình phụ thuộc vào những giấy phép nào, được kiểm tra trước khi thiết kế đối tượng, không phải sau.
- Dữ liệu được giữ nhất quán thế nào, và mỗi lớp nhất quán tốn kém ra sao.
Ngoài kỳ thi: việc xây dựng có AI hỗ trợ có thể tạo đối tượng và trường trong vài phút. Khi việc thêm vào gần như miễn phí, “mỗi cấu trúc là một cam kết” càng quan trọng hơn, chứ không kém đi. Mỗi mô-đun kết thúc bằng điều AI thay đổi cho quyết định đó.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (tiếng Anh)
- Standard User Licenses (opens in a new tab), Salesforce Help (tiếng Anh)
Tiếp theo: Hiểu dữ liệu doanh nghiệp