Hơn cả một cơ sở dữ liệu

🌐 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)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 1 trong 10 của chương Kiến trúc dữ liệu Salesforce, chương 3 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Tiếp theo: Hãy nhìn về phi thuyền mẹ: các mô hình dữ liệu chuẩn

Câu hỏi mô-đun này trả lời: Điều gì làm Salesforce khác một cơ sở dữ liệu truyền thống?

Nếu bạn đã làm quản trị viên Salesforce một thời gian, bạn đã biết cách tạo một đối tượng. Thiết lập, Trình quản lý đối tượng, Đối tượng tùy chỉnh mới. Đặt tên, thêm vài trường, dựng một bố cục trang, và mười phút sau người dùng đã có thể làm việc với nó.

Nhưng điều gì thực sự đã xảy ra khi bạn nhấp Lưu?

Nếu bạn xuất thân từ cơ sở dữ liệu, có lẽ bạn hình dung Salesforce đã đi tạo một bảng mới. Không phải vậy. Và hiểu vì sao là một trong những chỗ bạn bắt đầu chuyển từ tư duy của quản trị viên hay lập trình viên sang tư duy của kiến trúc sư.

Tất nhiên Salesforce lưu dữ liệu; có các cơ sở dữ liệu bên dưới. Nhưng Salesforce không phải là một cơ sở dữ liệu có cái màn hình đẹp bên trên. Nó là một nền tảng ứng dụng hướng siêu dữ liệu, và sự phân biệt đó định hình gần như mọi quyết định trong khóa học này.

Nền tảng có hình dạng của nó

Ở chương 2 chúng ta xây mô hình mà hoàn toàn không bận tâm đến Salesforce. Đó là cố ý: chúng ta lắng nghe các danh từ, xây mô hình khái niệm, thêm thuộc tính, khóa và quan hệ, và chỉ sau đó mới hỏi Salesforce nên triển khai nó thế nào. Giờ chúng ta phải hiểu thứ mà chúng ta triển khai nó lên trên.

Tôi dùng một câu đơn giản cho điều này: nền tảng có hình dạng của nó. Salesforce cho chúng ta đối tượng, trường, quan hệ, bảo mật, tự động hóa, API, giao dịch, báo cáo và tìm kiếm, và tất cả đều kết nối với nhau. Khi tôi tạo một đối tượng, tôi không chỉ tạo một chỗ để đặt các dòng. Tôi đang tạo một thứ tham gia vào mô hình bảo mật, mà tự động hóa có thể tác động lên, mà các API công bố ra ngoài, mà báo cáo có thể dùng, mà các đối tượng khác có thể liên kết tới, và mà người dùng, tích hợp và ngày càng nhiều tác tử sẽ phụ thuộc vào. Như vậy là nhiều hơn một cái bảng rất nhiều.

Siêu dữ liệu là bản thiết kế

Hãy nghĩ về một tòa nhà. Có bản thân tòa nhà, và có bản thiết kế mô tả nó: tường ở đâu, cửa đặt chỗ nào, các phòng nối với nhau ra sao. Salesforce hoạt động theo cùng cách. Một định nghĩa đối tượng là siêu dữ liệu. Một định nghĩa trường là siêu dữ liệu. Một quan hệ là siêu dữ liệu. Phần lớn những gì chúng ta cấu hình trong Thiết lập là siêu dữ liệu, và nền tảng đọc nó lúc chạy để mang lại cho org của chúng ta cấu trúc và hành vi.

Salesforce mô tả trái tim của nền tảng vừa là đa thuê bao (multitenant) vừa là hướng siêu dữ liệu: khi chúng ta định nghĩa một đối tượng hay một trường, định nghĩa đó được lưu dưới dạng siêu dữ liệu, chứ không phải là một bảng hay cột vật lý mới cho org của chúng ta (Platform Multitenant Architecture (opens in a new tab), tiếng Anh).

Khi dạy điều này, tôi mở nắp capô ra. Salesforce không tạo một cơ sở dữ liệu mới cho bạn mỗi khi bạn thêm một đối tượng. Nó thêm một bản ghi vào các bảng của chính nó: một bảng đối tượng, một bảng trường, một bảng dữ liệu, và các bảng xoay cho chỉ mục và quan hệ, tất cả được khóa theo một mã định danh org giữ dữ liệu của org bạn tách biệt với mọi người khác. Vì vậy thêm một trường chỉ là thêm một mục. Đó là lý do bạn có thể tạo một trường ngay lập tức, vào giờ nghỉ trưa, trên môi trường production.

Nó cũng giải thích một điều người ta hay vấp phải. Khi bạn viết SELECT Id, Name, Special__c FROM Account, nó trông như một bảng. Bên dưới, bạn đang đọc đối tượng chuẩn và trường tùy chỉnh của nó từ những cấu trúc khác nhau, nên nền tảng đang thực hiện một phép nối (join) mà bạn chưa bao giờ viết. Chỉ mục có tồn tại, nhưng chúng không hoạt động như chỉ mục của một cơ sở dữ liệu truyền thống. Bạn không cần biết cấu trúc bên trong cho kỳ thi. Bạn cần biết rằng những gì bạn thấy trong Trình quản lý đối tượng không phải là hình ảnh một-một của các bảng vật lý, và lớp trừu tượng đó vừa là sức mạnh của nền tảng vừa là lý do nó hoạt động như vậy.

Click to enlarge

Hãy nhìn về phi thuyền mẹ

Một trong những điều tôi nói với mọi người trong lớp là hãy nhìn về phi thuyền mẹ. Trước khi phát minh một cách phức tạp để làm điều gì đó trên Salesforce, hãy xem chính Salesforce làm điều đó thế nào.

Hãy lấy Tài khoản. Bạn không tạo ra nó; Salesforce tạo ra. Nhưng bạn có thể thêm trường vào nó, xây tự động hóa quanh nó, thay đổi bố cục của nó, công bố nó qua API và liên kết các đối tượng khác tới nó. Đối tượng tùy chỉnh chạy trên cùng bộ máy, đó là lý do đối tượng chuẩn và tùy chỉnh cảm giác rất giống nhau khi chúng ta xây trên chúng. Trong Apex, chúng thậm chí dùng chung một lớp cơ sở, sObject.

Đó là thói quen mà chương này xây dựng tiếp, và trong mô-đun tiếp theo chúng ta sẽ nhìn cho thật kỹ: vào các mô hình dữ liệu chuẩn mà Salesforce đã xây sẵn cho bạn.

Chúng ta không xây bên cạnh Salesforce. Chúng ta đang mở rộng nó.

API đến cùng với đối tượng

Tạo một bảng trong một cơ sở dữ liệu truyền thống và bạn có một cái bảng. Nếu một ứng dụng khác cần làm việc với nó, ai đó sẽ phải làm thêm việc. Tạo một đối tượng trên Salesforce, và nền tảng đã hiểu nó qua các lớp ứng dụng và tích hợp: nền tảng dùng chính siêu dữ liệu đó để cung cấp các API REST và SOAP, nên bản ghi của đối tượng có thể được tạo, đọc, cập nhật và xóa qua các API này ngay khi đối tượng tồn tại (Platform Multitenant Architecture (opens in a new tab), tiếng Anh).

Tôi không thiết kế một API chỉ vì tôi đã tạo một đối tượng. Nền tảng biết đối tượng, các trường, kiểu của chúng, các quan hệ và bảo mật của nó. Đó là một lý do phát triển trên Salesforce diễn ra nhanh như vậy. Đó cũng là lý do tạo một đối tượng là một quyết định lớn hơn vẻ ngoài của nó: bạn đang cắm một cấu trúc vào cả một nền tảng ứng dụng. Và điều này cũng đúng theo chiều ngược lại. Những người từ SQL Server hay Oracle đôi khi hỏi tôi làm sao tải dữ liệu thẳng vào cơ sở dữ liệu. Bạn không làm được. Mọi thứ đều đi qua các API.

Tòa chung cư

Giờ là từ bạn nghe suốt: đa thuê bao. Tôi nghĩ về nó như một tòa chung cư.

Bạn có căn hộ của mình. Đồ đạc là của bạn, và chìa khóa của bạn không nên mở được cửa nhà tôi. Nhưng chúng ta dùng chung tòa nhà: điện, nước, thang máy, sảnh. Org của bạn cảm giác như môi trường riêng của bạn, với dữ liệu, đối tượng và tự động hóa của bạn. Bên dưới, Salesforce mô tả mỗi org là một thuê bao, cô lập dữ liệu, siêu dữ liệu và logic của mỗi thuê bao trong khi hạ tầng và dịch vụ được dùng chung (Platform Multitenant Architecture (opens in a new tab), tiếng Anh). Đó là cách nó có thể cho mọi khách hàng một nền tảng tùy biến cao như vậy mà không phải chạy một hạ tầng riêng cho mỗi người.

Nhưng dùng chung tòa nhà có hệ quả. Nếu một thuê bao mua một chiếc điều hòa khổng lồ và chạy máy sấy tóc cùng lò nướng một lúc, họ làm nhảy cầu dao, và cả tầng tối om.

Bạn không thể chiếm thang máy

Hãy ở lại tòa nhà thêm một phút. Hãy tưởng tượng một cư dân tuyên bố: “Tôi cần thang máy từ tám giờ đến trưa. Không ai khác được dùng.” Điều đó không ổn trong một tòa nhà dùng chung, và cũng không ổn trên Salesforce. Không thể để một thuê bao tiêu thụ tài nguyên dùng chung không giới hạn và làm giảm chất lượng nền tảng cho mọi người khác.

Đó là nguồn gốc của giới hạn điều tiết (governor limits). Nếu bạn đã phát triển trên Salesforce, có lẽ bạn đã gặp chúng dưới dạng một danh sách con số phải học thuộc. Tôi không muốn bạn nghĩ về chúng như vậy. Salesforce áp dụng giới hạn ở cấp giao dịch và cấp org để khối lượng công việc của một thuê bao không độc chiếm năng lực tính toán dùng chung (Architecture Basics (opens in a new tab), tiếng Anh). Đó là kiến trúc; mỗi giới hạn riêng lẻ chỉ là cách triển khai nó. Ở phần sau của khóa học, chúng ta sẽ quan tâm đến những giới hạn cụ thể vì chúng thay đổi một thiết kế. Bây giờ, hãy nhớ tòa nhà: bạn có tự do rất lớn để sửa sang căn hộ của mình. Bạn không được chiếm thang máy.

ID Salesforce là một phần của lớp trừu tượng

Mỗi bản ghi Salesforce có một danh tính mà nền tảng hiểu, đó là ID bản ghi, và nó hoạt động xuyên suốt mọi khả năng: giao diện, API, báo cáo, tự động hóa.

Ở chương 2 chúng ta đã nói một khóa tốt là duy nhất, bất biến, không mang ý nghĩa và không bao giờ là dữ liệu cá nhân. ID Salesforce đáp ứng điều đó đối với Salesforce. Nhưng nó không giống một khóa nghiệp vụ. Công ty của bạn có thể vẫn có một số khách hàng ERP, một mã nhân viên hay số đơn hàng của một đối tác mang ý nghĩa xuyên các hệ thống. Đừng nhầm “Salesforce biết đây là bản ghi nào” với “doanh nghiệp biết đây là thứ nghiệp vụ nào”. Đó là hai vấn đề định danh khác nhau, và vấn đề thứ hai sẽ quay lại trong tích hợp và dữ liệu chủ.

Đối tượng còn hơn cả nơi lưu trữ

Đây là sự chuyển đổi tôi muốn bạn thực hiện trước phần còn lại của chương. Một đối tượng không chỉ là nơi lưu dữ liệu. Một trường không chỉ là một cột, và một quan hệ không chỉ là một khóa ngoại. Tôi dùng các so sánh với cơ sở dữ liệu khi dạy, vì chúng kết nối với những gì người ta đã biết. Nhưng nếu dừng ở đó, chúng ta bỏ lỡ kiến trúc.

Đối tượng chúng ta chọn quyết định những khả năng nào đi kèm với nó. Kiểu trường ảnh hưởng đến xác thực, tích hợp, tìm kiếm, báo cáo và cách các hệ thống khác đọc dữ liệu. Quan hệ quyết định vòng đời, quyền sở hữu, chia sẻ và việc xóa. Nơi chúng ta đặt dữ liệu ảnh hưởng đến lưu trữ, hiệu năng và quy mô. Và vì tất cả chạy trên một nền tảng dùng chung, một lựa chọn vô hại với một trăm bản ghi có thể hoạt động rất khác với một trăm triệu bản ghi. Chúng ta sẽ lần lượt đi qua những quyết định đó.

Ngoài kỳ thi: AI thay đổi điều gì. Nhiều năm qua, tên và mô tả tốt giúp quản trị viên hay lập trình viên tiếp theo hiểu những gì chúng ta đã xây. Giờ máy móc cũng đọc ngữ cảnh đó. Một hệ thống AI làm việc với một trường tên Flag2__c gặp đúng vấn đề của một lập trình viên mới: thứ này nghĩa là gì? Siêu dữ liệu không còn là đồ trang trí nữa; nó là một phần cách máy móc hiểu ứng dụng.

Kiến trúc sư quyết định gì ở đây

• Tôi đang thiết kế cho nền tảng mình thực sự đang dùng, hay đang đối xử với Salesforce như một cơ sở dữ liệu chung chung?
• Phần nào trong thiết kế của tôi là khái niệm nghiệp vụ, và phần nào là lựa chọn triển khai trên Salesforce?
• Hành vi nền tảng nào đi kèm với cấu trúc tôi sắp tạo?
• Giới hạn nào là biểu hiện của kiến trúc dùng chung, và giới hạn nào trong số đó sẽ định hình thiết kế này?
• Nếu cấu trúc này sẽ khó thay đổi về sau, tôi có đang đối xử với nó như một quyết định kiến trúc không?

Ở chương 2 chúng ta đã nói: đừng thiết kế từ Thiết lập. Giờ bạn biết thêm một lý do. Nhấp Đối tượng tùy chỉnh mới không chỉ cho bạn một cái bảng; nó nối thêm một phần kiến trúc của bạn vào một nền tảng hướng siêu dữ liệu, đa thuê bao. Nhưng trước khi quyết định tạo đối tượng nào, có một câu hỏi cơ bản hơn: dữ liệu này có nên nằm ở đây không? Đó là phần tiếp theo.

Tìm hiểu thêm

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02, kiểm tra lại ngày 2026-10-12: định nghĩa đối tượng và trường được lưu dưới dạng siêu dữ liệu, không phải bảng mới; các bảng dùng chung (MT_Objects, MT_Fields, MT_Data, MT_Indexes) được khóa theo OrgID; chính siêu dữ liệu đó cung cấp các API REST và SOAP.
• Salesforce Architects, Architecture Basics (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02, kiểm tra lại ngày 2026-10-12: giới hạn điều tiết và giới hạn thực thi để mã và giao dịch “không độc chiếm tài nguyên tính toán dùng chung”.