Cập nhật cơ sở dữ liệu (LINQ to SQL phần 4)

Từ vài tuần trước, tôi đã bắt đầu một loạt bài nói về LINQ to SQL. LINQ to SQL là một O/RM có sẵn trong bản .NET Framework 3.5, và nó cho phép bạn dễ dàng mô hình hóa các CSDL cùng các lớp .NET. Bạn có thể dùng các biểu thức LINQ để truy vấn CSDL, cũng như để thêm/xóa/sửa dữ liệu.

Dưới đây là 3 bài đầu tiên trong loạt bài này:

• Sử dụng LINQ to SQL (phần 1)
• Định nghĩa các lớp mô hình dữ liệu (phần 2)
• Truy vấn Cơ sở dữ liệu (phần 3)

Trong bài hôm nay, tôi sẽ nói rõ hơn về cách chúng ta dùng CSDL đã được mô hình hóa trước đây, và dùng nó để cập nhật, chỉnh sửa và xóa dữ liệu. Tôi cũng sẽ cho các bạn thấy các chúng ta có thể thêm các quy tắc (business rule – sau này trở đi tôi sẽ để nguyên từ business rule, vì từ này rõ nghĩa hơn) và tùy biến cách xác thực tính hợp lệ của dữ liệu.

CSDL Northwind được mô hình hóa dùng LINQ to SQL

Trong phần 2 của loạt bài này, tôi đã đi qua các bước để tạo nên mô hình các lớp LINQ to SQL dùng LINQ to SQL designer có trong VS 2008. Dưới đây là sơ đồ lớp đã được tạo cho CSDL mẫu Northwind và cũng sẽ là mô hình được dùng trong bài viết này:

Khi chúng ta định nghĩa mô hình dữ liệu dùng LINQ to SQL designer như trên, chúng ta đã định nghĩa ra 5 lớp mô hình: Product, Category, Customer, Order and OrderDetail. Các thuộc tính của mỗi lớp ánh xạ vào các cột tương ứng trong bảng dữ liệu. Mỗi đối tượng thuộc lớp thực thể sẽ biểu diễn một dòng trong bảng CSDL.

Khi định nghĩa mô hình dữ liệu, LINQ to SQL designer cũng tạo ra một lớp DataContext cung cấp các cách thức để truy vấn và cập nhật lại dữ liệu. Trong mô hình mẫu chúng ta đã định nghĩa ở trên, lớp này được đặt tên là “NorthwindDataContext”. Lớp NorthwindDataContext có các thuộc tính biểu diễn các bảng chúng ta đã định nghĩa trong CSDL (Products, Categories, Customers, Orders, OrderDetails).

Như chúng ta đã xem trong phần 3, chúng ta cũng dễ dàng dùng các biểu thức LINQ để truy vấn và lấy dữ liệu từ CSDL bằng cách dùng lớp NorthwindDataContext. LINQ to SQL sau đó sẽ tự động diễn dịch các biểu thức đó thành các câu lệnh SQL thích hợp để thực thi.

Ví dụ, chúng ta có thể viết biểu thức LINQ như dưới đây để lấy về một đối tượng Product đơn bằng cách tìm dựa trên tên sản phẩm:

Tôi cũng có thể viết thêm một câu truy vấn LINQ dưới đây để lấy về tất cả các sản phẩm từ CSDL mà hiện tại chưa có đơn đạt hàng, và giá tiền nhiều hơn $100:

Chú ý cách tôi đang dùng “OrderDetails” kết hợp với mỗi sản phẩm như một phần của câu truy vấn để chỉ lấy về các sản phẩm không có đơn đặt hàng.

Change Tracking và DataContext.SubmitChanges()

When we perform queries and retrieve objects like the product instances above, LINQ to SQL will by default keep track of any changes or updates we later make to these objects.  We can make any number of queries and changes we want using a LINQ to SQL DataContext, and these changes will all be tracked together.

Khi chúng ta thực hiện các câu truy vấn và lấy về các đối tượng như đối tượng product ở trên, LINQ to SQL sẽ mặc nhiên lưu lại vết của các thao tác thay đổi hay cập nhật mà chúng ta thực hiện trên các đối tượng đó (gọi là change tracking). Chúng ta có thể thực hiện bao nhiêu câu truy vấn và thay đổi mà chúng ta muốn bằng cách dùng LINQ to SQL DataContext, và tất cả các thay đổi đó sẽ được lưu vết lại.

Ghi chú: Việc lưu vết LINQ to SQL xảy ra bên phía chương trình gọi, và không liên quan gì đến CSDL. Có nghĩa là bạn không hề dùng tài nguyên trên CSDL, hoặc bạn không cần cài đặt thêm hay thay đổi bất kỳ thứ gì trên CSDL để cho phép làm điều này.

Sau khi đã cập nhật các đối tượng chúng ta lấy từ LINQ to SQL, chúng ta có thể gọi phương thức ”SubmitChanges()” trên lớp DataContext để cập nhật lại các  thay đổi lên CSDL. Việc gọi phương thức này sẽ làm cho LINQ to SQL để tính toán động và thực thi các câu lệnh SQL phù hợp để cập nhật CSDL.

Lấy ví dụ, bạn có thể viết câu lệnh dưới đây để cập nhật lại giá tiền và số lượng đơn vị còn lại của sản phẩm “Chai”:

Khi tôi gọi northwind.SubmitChanges() như ở trên, LINQ to SQL sẽ xây dựng và thực thi một câu lệnh SQL “UPDATE” mà nó sẽ cập nhật lại hai thuộc tính của sản phẩm mà chúng ta đã sửa lại như ở trên.

Tôi có thể viết đoạn lệnh dưới đây để duyệt qua danh sách các sản phẩm ít phổ biến và giá cao, sau đó đặt lại thuộc tính “ReorderLevel” = 0:

Khi tôi gọi northwind.SubmitChanges() như trên, LINQ to SQL sẽ tính toán và thực thi một tập thích hợp các phát biểu UPDATE để cập nhật các sản phẩm có thuộc tính ReorderLevel đã bị thay đổi.

Hãy nhớ là nếu giá trị của các thuộc tính của đối tượng Product không bị thay đổi bởi câu lệnh trên, có nghĩa là bản thân đối tượng không bị thay đổi, thì LINQ to SQL cũng sẽ không thực thi bất kỳ câu lệnh UPDATE nào trên đối tượng đó. Ví dụ, nếu đơn giá của đối tượng “Chai” đã là 2 và số san phẩm còn lại là 4, thì việc gọi SubmitChanges() sẽ chẳng làm thực thi bất kỳ câu SQL nào. Cũng vây, chỉ các sản phẩm trong ví dụ thứ hai có ReorderLevel không bằng 0 mới được cập nhật khi gọi SubmitChanges().

Các ví dụ Insert và Delete

Ngoài việc cập nhật các dòng đã có trong CSDL, LINQ to SQL còn cho phép bạn thêm và xóa dữ liệu. Bạn có thể làm được điều này bằng việc thêm/bớt các đối tượng dữ liệu từ các tập hợp bảng trong lớp DataContext, và sau đó gọi SubmitChanges(). LINQ to SQL sẽ lưu vết lại các thao tác này, và tự động thực thi câu lệnh SQL INSERT hay DELETE phù hợp khi phương thức SubmitChanges() được gọi.

Thêm một sản phẩm

Bạn có thể thêm một sản phẩm mới vào CSDL bằng việc tạo ra một đối tượng thuộc lớp “Product”, gán các giá trị thuộc tính, và sau đó thêm nó vào tập hợp “Products” của DataContext:

Khi gọi “SubmitChanges” như trên, một dòng mới sẽ được thêm vào bảng Product.

Xóa các sản phẩm

Cũng như tôi đã nói về việc thêm một sản phẩm mới bằng cách đổi tượng Product vào tập hợp Products của DataContext, tôi cũng có thể làm một cách ngược lại khi muốn xóa một sản phẩm từ CSDL bằng cách xóa nó khỏi tập hợp này:

(RemoveAll đã được thay đổi bằng DeleteOnSubmit trong phiên bản hiện tại)

Chú ý cách tôi lấy một tập hợp các sản phẩm không còn được sản xuất và cũng không có đơn đặt hàng nào bằng cách dùng một câu truy vấn LINQ, rồi sau đó truyền nó cho phương thức RemoveAll của tập hợp Products trong DataContext. Khi gọi SubmitChanges(), tất cả các sản phẩm đó sẽ bị xóa khỏi CSDL.

Cập nhật thông qua các quan hệ

Điều làm cho các trình ORM như LINQ to SQL cực kỳ mềm dẻ là nó cho phép chúng ta dễ dàng mô hình hóa mối quan hệ giữa các bảng trong mô hình dữ liệu. Ví dụ, tôi có thể mô hình hóa mỗi Product trong một Category, mỗi Order để chứa các OrderDetails cho từng mục, kết hợp các OrderDetail với một Product, và làm cho mỗi Customer kết hợp với một tập các Order. Tôi đã biểu diễn cách xây dựng và mô hình hóa các mối quan hệ trong phần 2 của loạt bài này.

LINQ to SQL cho phép tôi tận dụng được ưu điểm của các mối quan hệ trong việc truy vấn và cập nhật dữ liệu. Ví dụ, tôi có thể viết đoạn lệnh dưới đây để tạo một Product mới và kết hợp nó với một category “Beverages” trong CSDL như dưới đây:

(Add đã được thay đổi bằng InsertOnSubmit trong phiên bản hiện tại)

Hãy chú ý cách tôi thêm một đối tượng Product vào tập hợp Products của một Category. Nó sẽ chỉ ra rằng có một mối quan hệ giữa hai đối tượng, và làm cho LINQ to SQL tự động duy trì mối quan hệ foreign-key/primary key giữa cả hai khi tôi gọi SubmitChanges.

Một ví dụ khác cho thấy LINQ to SQL có thể giúp quản lý quan hệ giữa các bảng như thế nào và giúp cho việc lập trình sáng sủa hơn, hãy xem một ví dụ dưới đây khi tôi tạo một Order mới cho một khách hàng đã có. Sau khi đặt giá trị cho ngày chuyển hàng và chi phí cho việc đặt hàng, tôi sẽ tạo tiếp 2 mục chi tiết trong đơn đặt hàng để chỉ đến các sản phẩm mà khách hàng đang muốn mua. Sau đó, tôi sẽ kết hợp đơn đặt hàng với khách hàng, và cập nhật các thay đổi vào CSDL.

(Add đã được thay đổi bằng InsertOnSubmit trong phiên bản hiện tại)

Như bạn thấy, mô hình lập trình trên cho phép thực hiện tất cả các công việc này một cách cực kỳ sáng sủa theo phong cách hướng đối tượng.

Transactions

Một transaction (giao dịch) là một dịch vụ được cung cấp bởi một CSDL (hoặc một trình quản lý tài nguyên khác) để đảm bảo rằng một tập các thao tác độc lập sẽ được thực thi như một đơn vị duy nhất – có nghĩa là hoặc tất cả cùng thành công, hoặc cùng thất bại. Và trong trường hợp thất bại, tất cả các thao tác đã là làm sẽ bị hoàn tác trước khi bất kỳ thao tác nào khác được cho phép thực hiện.

Khi gọi SubmitChanges() trên lớp DataContext, các lệnh cập nhật sẽ luôn được thực thi trong cùng một transaction. Có nghĩa là CSDL của bạn sẽ không bao giờ ở trong một trạng thái không toàn vẹn nếu bạn thực thi nhiều câu lệnh – hoặc tất cả các thao tác bạn làm sẽ được lưu lại, hoặc không có bất kỳ thay đổi nào.

Nếu không có một transaction đang diễn ra, DataContext của LINQ to SQL sẽ tự động bắt đầu một transaction để bảo vệ các thao tác cập nhật khi gọi SubmitChanges(). Thêm vào đó, LINQ to SQL còn cho phép bạn tự định nghĩa và dùng đối tượng TransactionScope của riêng bạn. Điều này làm cho việc tích hợp các lệnh LINQ to SQL vào các đoạn mã truy cập dữ liệu đã có dễ dàng hơn. Nó cũng có nghĩa là bạn có thể đưa cả các tài nguyên không phải của CSDL vào trong cùng transaction. Ví dụ: bạn có thể gửi đi một thông điệp MSMQ, cập nhật hệ thống file (sử dụng khả năng hỗ trợ transaction cho hệ thống file),… và nhóm tất cả các thao tác đó vào trong cùng một transaction mà bạn dùng để cập nhật CSDL dùng LINQ to SQL.

Kiểm tra dữ liệu và Business Logic

Một trong những điều quan trọng mà các nhà phát triển cần nghĩ đến khi làm việc với dữ liệu là làm sao để kết hợp được các phép xác thực dữ liệu và các quy tắc chương trình (business logic). LINQ to SQL cũng hỗ trợ nhiều cách để các nhà phát triển có thể dễ dàng tích hợp chúng vào với các mô hình dữ liệu của họ.

LINQ to SQL cho phép bạn thêm khả năng xác thực dữ liệu mà không phụ thuộc vào cách bạn tạo ra mô hình dữ liệu cũng như nguồn dữ liệu. Điều này cho phép bạn có thể lặp lại các phép kiểm tra ở nhiều chỗ khác nhau, và làm cho mã lệnh sáng sủa và dễ bảo trì hơn rất nhiều.

Hỗ trợ kiểm tra các giá trị thuộc tính dựa trên schema của CSDL

Khi định nghĩa các lớp mô hình dữ liệu dùng LINQ to SQL designer trong VS 2008, chúng sẽ mặc nhiên được gán các quy tắc xác thực dựa trên cấu trúc định nghĩa trong CSDL.

Kiểu dữ liệu của thuộc tính trong các lớp mô hình dữ liệu sẽ khớp với các kiểu dữ liệu tương ứng trong CSDL. Điều này có nghĩa là bạn sẽ gặp lỗi biên dịch nếu cố gắng gán một giá trị kiểu boolean và cho một thuộc tính decimal, hoặc nếu thử ép kiểu dữ liệu một cách không hợp lệ.

Nếu một cột trong CSDL được đánh dấu cho phép mang giá trị NULL, khi đó thuộc tính tương ứng trong mô hình dữ liệu được tạo bởi LINQ to SQL designer cũng cho phép NULL. Các cột không cho phép NULL sẽ tự động đưa ra các exception nếu bạn cố gắng lưu một đối tượng có thuộc tính đó mang giá trị NULL. LINQ to SQL sẽ đảm bảo các cột định danh/duy nhất không bị trùng lắp trong CSDL.

Bạn có thể dùng LINQ to SQL designer để ghi đè lên các quy tắc xác thực dựa trên schema nếu muốn, nhưng các quy tắc này sẽ được tạo ra tự động và bạn không cần làm bất kỳ điều gì để cho phép chúng. LINQ to SQL cũng tự động xử lý các chuỗi escape, do vậy bạn không cần lo lắng về lỗi SQL injection.

Hỗ trợ tùy biến việc kiểm tra giá trị các thuộc tính

Việc kiểm tra dữ liệu dựa trên cấu trúc định nghĩa trong CSDL rất hữu ích, nhưng chỉ được coi như ở mức cơ bản, trong thực tế có thể bạn sẽ gặp phải những yêu cầu kiểm tra phức tạp hơn nhiều.

Hãy xem một ví dụ trong CSDL Northwind, khi tôi định nghĩa thuộc tính Phone thuộc lớp Customer có kiểu dữ liệu là nvarchar. Các nhà phát triển dùng LINQ to SQL có thể viết code giống như dưới đây để cập nhật nó với một số phone hợp lệ:

Vấn đề là đoạn code trên được coi là hợp lệ đứng từ góc độ kiểu dữ liệu SQL, vì chuỗi trên vẫn là một chuỗi nvarchar mặc dù có thể nó không phải là một số phone hợp lệ:

Để tránh việc thêm các số phone kiểu như trên vào CSDL, chúng ta có thể thêm một quy tắc kiểm tra tính hợp lệ vào lớp Customer. Thêm một quy tắc để kiểm tra thực sự đơn giản. Tất cả những gì chúng ta cần làm là thêm một partial class vào và định nghĩa phương thức như dưới đây:

Đoạn code trên tận dụng ưu điểm của 2 đặc tính trong LINQ to SQL:

1) Tất cả các lớp được tạo ra đều là partial – có nghĩa là nhà phát triển có thể dễ dàng thêm vào các phương thức, thuộc tính và thậm chí cả các sự kiện (và đặt chúng trong một file riêng biệt). Điều này làm cho việc thêm các quy tắc xác thực và các hàm phụ trợ vào mô hình dữ liệu và lớp DataContext rất dễ dàng. Bạn không cần cấu hình hay viết thêm các code nào khác để làm được điều này.

2) LINQ to SQL đã tạo sẵn một loạt các điểm mở rộng trong mô hình dữ liệu và lớp DataContext mà bạn có thể dùng để thêm vào các phép kiểm tra dữ liệu trước và sau khi thực hiện các công việc. Nhiều trong số đó ứng dụng một đặc tính ngôn ngữ mới được gọi là “partial method” có trong VB và C# có trong VS 2008 beta 2. Wes Dyer trong nhóm C# có một bài nói về cách các partial method làm việc tại đây.

Trong ví dụ về việc kiểm tra tính hợp lệ dữ liệu ở trên, tôi dùng phương thức OnPhoneChanging, đây là một phương thức sẽ được thực thi bất kỳ lúc nào người dùng gán lại giá trị cho thuộc tính Phone trên một đối tượng Customer. Tôi có thể dùng phương thức này để xác thực giá trị đầu vào theo bất kỳ cách gì tôi muốn (trong ví dụ này, tôi dùng một biểu thức chính quy). Nếu giá trị đã hợp lệ, tôi chỉ đơn giản return và không làm gì cả, khi đó LINQ to SQL sẽ cho là các giá trị này là giá trị hợp lệ, ngược lại tôi có thể phát ra một Exception bên trong phương thức kiểm tra, và phép gán khi đó sẽ không được thực hiện.

Hỗ trợ tùy biến việc kiểm tra tính hợp lệ của thực thể

Việc kiểm tra trên từng thuộc tính như trong các ví dụ trên rất hữu dụng khi bạn muốn kiểm tra giá trị của từn thuộc tính riêng lẻ. Nhưng đôi khi, bạn sẽ cần phải kiểm tra dựa trên nhiều giá trị của các thuộc tính khác nhau.

Hãy xem ví dụ sau, tôi sẽ đặt giá trị cho 2 thuộc tính “OrderDate” và “RequiredDate”:

(Add đã được thay đổi bằng InsertOnSubmit trong phiên bản hiện tại)

Đoạn lệnh trên là hợp lệ nếu chỉ đơn thuần xét từ góc độ ngôn ngữ – nhưng sẽ là không có ý nghĩa khi bạn lại muốn đặt ngày khách hàng yêu cầu trước ngày đặt hàng.

Tin vui là từ bản LINQ to SQL beta 2, chúng ta có thể thêm vào các quy tắc kiểm tra cho từng thực thể để tránh các lỗi kiểu như trên bằng cách thêm một lớp partial cho lớp “Order” và hiện thực hóa hàm OnValidate(), hàm này sẽ được gọi trước khi dữ liệu được đưa vào CSDL. Bên trong phương thức này, chúng ta có thể truy cập và kiểm tra tất cả các thuộc tính của lớp trong mô hình dữ liệu.

Bên trong phương thức này, bạn có thể kiểm tra giá trị bất kỳ thuộc tính nào, và thậm chí có thể truy cập (chỉ đọc) vào các đối tượng liên quan, và có thể phát ra một exception nếu có tồn tại các giá trị không hợp lệ. Bất kỳ một exception nào được phát ra từ phương thức OnValidate() sẽ làm cho việc cập nhật bị hủy bỏ, và hủy bỏ các thay đổi trong transaction.

Tùy biến các phương thức kiểm tra việc thêm/xóa/sửa dữ liệu

Có nhiều lúc bạn muốn thêm các phép kiểm tra khi thêm/xóa/sửa dữ liệu. LINQ to SQL Beta2 cho phép làm điều này bằng cách cho phép bạn thêm vào một lớp partial để mở rộng lớp DataContext và sau đó hiện thực hóa các phương thức để tùy biến các thao tác thêm/xóa/sửa cho các thực thể. Các thức này sẽ được thực thi tự động khi bạn gọi SubmitChanges() trên lớp DataContext.

Bạn có thể thêm các phép kiểm tra thích hợp vào bên trong các phương thức đó – và nếu dữ liệu hợp lệ, LINQ to SQL sẽ tiếp tục lưu lại các thay đổi vào CSDL (bằng cách gọi phương thức “ExecuteDynamicXYZ” của DataContext).

Một trong những điều thú vị là các phương thức phù hợp sẽ được gọi tự động, không phụ thuộc vào ngữ cảnh mà đối tượng được tạo/xóa/sửa. Hãy xem ví dụ sau, ở đây tôi muốn tạo một Order mới và kết hợp nó với một Customer đã có:

(Add đã được thay đổi bằng InsertOnSubmit trong phiên bản hiện tại)

Khi tôi gọi northwind.SubmitChanges() ở trên, LINQ to SQL sẽ xác định là nó cần lưu lại một đối tượng Order, và phương thức InsertOrder sẽ tự động được gọi.

Nâng cao: Xem danh sách thay đổi cho Transaction

Đôi khi bạn muốn thêm các quy tắc kiểm tra mà không thể chỉ dựa trên từng thao tác thêm/xóa/sửa riêng lẻ, thay vào đó bạn phải có thể duyệt qua toàn bộ các thao tác đã thực hiện trong transaction.

Bắt đầu từ bản Beta2 của .NET 3.5, LINQ to SQL cho phép bạn truy cập vào danh sách này bằng cách gọi phương thức DataContext.GetChangeList(). Nó sẽ trả về một đối tượng ChangeList chứa các tập hợp cho các thao tác thêm/xóa/sửa đã được thực hiện.

Một cách tiếp cận là bạn có thể tạo một lớp thừa kế từ lớp DataContext và override phương thức SubmitChanges(). Khi đó bạn có thể lấy ChangeList() cho thao tác cập nhật và thực hiện các phép kiểm tra cần thiết trước khi thực thi:

Xử lý các thay đổi đồng thời với Optimistic Concurrency:

Một trong những vấn đề mà các nhà phát triển phải nghĩ đến trong môi trường đa người dùng là làm thế nào có thể xử lý các thao tác cập nhật trên các cùng một tập dữ liệu. Ví dụ, cho là có hai người dùng đang cùng lấy về một đối tượng product bên trong một ứng dụng, và một người đặt lại giá trị cho ReorderLevel là 0, trong khi người kia đặt lại là 1. Nếu cả hai người dùng đều lưu lại các thay đổi đó vào CSDL, nhà phát triển cần cân nhắc việc xử lý tranh chấp dữ liệu.

Một cách tiếp cận đơn giản là “let the last writer win” (người cuối cùng là người chiến thắng) – có nghĩa là những thay đổi bởi người đầu tiên sẽ bị thay đổi mà không biết. Và điều này thường được coi là một trải nghiệm kém cỏi (và không đúng) – có nghĩa người dùng sẽ cảm thấy khó sử dụng.

Một cách tiếp cận khác mà LINQ to SQL hỗ trợ là dùng mô hình optimistic concurrency – khi đó LINQ to SQL sẽ tự động xác định xem giá trị gốc trong CSDL đã bị thay đổi bở người dùng khác hay chưa. LINQ to SQL sau đó sẽ cung cấp một danh sách các giá trị bị xung đột để người phát triển có thể chọn giải pháp xử lý hoặc có thể yêu cầu người dùng chọn một thao tác nào họ muốn.

Tôi sẽ nói về cách dùng optimistic concurrency với LINQ to SQL trong các bài viết khác.

Dùng SPROCs hoặc tùy biến logic các câu SQL:

Một trong những câu hỏi mà các nhà phát triển (và đặc biệt là các DBA – các nhà quản trị CSDL), những người đã từng viết các thủ tục (SPROC) với các câu SQL tùy biến thường hỏi khi nhìn thấy LINQ to SQL lần đầu tiên là: “làm sao tôi có thể kiểm soát hoàn toàn các câu lệnh SQL được thực thi bên dưới ?”

Một tin tốt là LINQ to SQL có một mô hình cực kỳ mềm dẻo, nó cho phép các nhà phát triển có thể thay thế các câu lệnh củaLINQ to SQL bằng các thủ tục insert, update, delete mà họ tự định nghĩa.

Điều thực sự thú vị là bạn có thể bắt đầu bằng cách định nghĩa mô hình dữ liệu của riêng bạn và để LINQ to SQL tự thực hiện các thao tác thêm/sửa/xóa. Rồi sau đó bạn có thể tùy biến lại mô hình dữ liệu để thực hiện các thao tác cập nhật với các thủ tục hoặc các câu SQL của bạn mà không phải thay đổi bất kỳ đoạn lệnh nào dùng mô hình dữ liệu đó, và cũng chẳng phải thay đổi bất kỳ quy tắc kiểm tra đã tạo trước đó. Điều này cung cấp khả năng tùy biến rất lớn cho bạn khi xây dựng ứng dụng.

Tôi cũng sẽ nói kỹ hơn về cách tùy biến mô hình dữ liệu dùng các thủ tục hay câu lệnh SQL trong một bài viết khác.