Thiết kế cấu trúc cơ sở dữ liệu sản phẩm đa biến thể (SKU, Kích cỡ, Màu sắc, Số lô, Hạn sử dụng) cho website quy mô lớn
Thiết kế cấu trúc cơ sở dữ liệu sản phẩm đa biến thể cho website thương mại điện tử quy mô lớn đòi hỏi tách biệt rõ ràng giữa thực thể Sản phẩm gốc hiển thị (Parent SPU) và Mã định danh lưu kho vật lý (Child SKU), kết hợp lưu trữ thuộc tính động bằng bảng quan hệ lai JSONB được đánh chỉ mục. Kiến trúc này giúp website quản lý trơn tru hàng trăm nghìn mã biến thể theo màu sắc, kích cỡ, quy cách đóng gói, số lô sản xuất và hạn sử dụng mà vẫn giữ tốc độ truy vấn bộ lọc dưới 100 mili giây.
Nhiều website thương mại điện tử hoạt động rất mượt khi chỉ có vài trăm sản phẩm đơn giản, nhưng lập tức rơi vào tình trạng treo máy chủ và sai lệch tồn kho khi mở rộng lên 20.000 – 100.000 mã biến thể SKU thuộc các ngành thời trang, mỹ phẩm, dược phẩm, điện máy hay vật liệu xây dựng. Nguyên nhân sâu xa nằm ở việc thiết kế lược đồ cơ sở dữ liệu (Database Schema) gộp chung sản phẩm hiển thị với đơn vị quản lý tồn kho vật lý ngay từ đầu.
Mô hình phân tách SPU (Sản phẩm hiển thị) và SKU (Đơn vị lưu kho vật lý) trong cơ sở dữ liệu
Sai lầm kinh điển khi thiết kế cơ sở dữ liệu cho website bán hàng là tạo mỗi biến thể màu sắc hoặc kích cỡ thành một bài đăng sản phẩm rời rạc (khiến trang danh mục bị ngập tràn bởi 10 chiếc áo giống hệt nhau chỉ khác màu), hoặc ngược lại là nhồi nhét toàn bộ các tùy chọn màu sắc, kích cỡ vào một cột văn bản trong bảng sản phẩm duy nhất (khiến hệ thống không thể trừ tồn kho và định giá riêng cho từng biến thể).
Để giải quyết triệt để, kiến trúc dữ liệu chuẩn bắt buộc phải tách thành hai tầng thực thể liên kết chặt chẽ: tầng SPU (Standard Product Unit - Sản phẩm gốc) và tầng SKU (Stock Keeping Unit - Biến thể lưu kho). Bảng SPU lưu trữ các thông tin dùng chung cho mục đích hiển thị và tối ưu công cụ tìm kiếm (SEO) như: tên dòng sản phẩm, đường dẫn tĩnh (Slug URL), bài viết mô tả chi tiết, thương hiệu, danh mục ngành hàng và bộ thông số kỹ thuật chung.
Trong khi đó, bảng SKU liên kết khóa ngoại với SPU để lưu trữ các thông tin giao dịch và vận hành kho bãi cụ thể cho từng tổ hợp thuộc tính phân loại (ví dụ: Áo sơ mi nam mã SPU-01, nhưng biến thể Màu Trắng - Cỡ L là mã SKU-01-WHT-L). Mỗi bản ghi SKU sở hữu mã vạch (Barcode/EAN-13) riêng, giá bán riêng, giá vốn riêng, kích thước – trọng lượng đóng gói riêng và bộ sưu tập hình ảnh góc chụp đúng màu sắc của biến thể đó.
- Tránh trùng lặp nội dung SEO (Duplicate Content): công cụ tìm kiếm chỉ lập chỉ mục đường dẫn chuẩn (Canonical URL) của trang SPU, đồng thời vẫn cho phép người dùng chia sẻ đường dẫn có gắn tham số SKU (ví dụ: ?sku=SKU-01-WHT-L) để mở ra đúng màu sắc và kích cỡ đang chọn.
- Quản lý trạng thái vòng đời độc lập cho từng SKU: khi biến thể Màu Đen - Cỡ XL ngừng sản xuất, quản trị viên chỉ cần khóa trạng thái của SKU đó trên giao diện chọn mẫu mà không làm ảnh hưởng đến thứ hạng từ khóa của trang sản phẩm gốc.
- Hỗ trợ cấu trúc Sản phẩm gộp (Bundle/Combo SKU): một mã Combo khuyến mãi trên website được cấu thành từ nhiều mã SKU vật lý theo tỷ lệ định mức (BOM - Bill of Materials), khi khách đặt 1 Combo thì hệ thống tự động trừ tồn kho của từng SKU thành phần.
- Tách biệt bảng Giá sản phẩm (Product Prices) và bảng Tồn kho theo chi nhánh (Inventory Balances) ra khỏi bảng thông tin SKU để các giao dịch cập nhật tồn kho liên tục không gây khóa bảng (Table Lock) làm chậm luồng đọc dữ liệu của người mua.
So sánh các mô hình lưu trữ thuộc tính động: Cột cố định, EAV truyền thống và Quan hệ lai JSONB
Trên một website đa ngành hàng, mỗi nhóm sản phẩm lại sở hữu hàng chục thuộc tính kỹ thuật hoàn toàn khác nhau: máy tính xách tay có Dung lượng RAM, Thế hệ CPU, Tần số quét màn hình; mỹ phẩm có Loại da phù hợp, Độ chống nắng SPF, Thành phần hoạt chất; còn gạch ốp lát lại có Kích thước viên, Bề mặt men vàSố viên trên mỗi thùng. Nếu tạo hàng trăm cột dữ liệu trên cùng một bảng sản phẩm, hơn 90% số ô trong bảng sẽ mang giá trị rỗng (NULL), gây lãng phí bộ nhớ và khó mở rộng.
Trước đây, nhiều nền tảng thương mại điện tử mã nguồn mở sử dụng mô hình EAV (Entity - Attribute - Value) tách mỗi thuộc tính thành một dòng trên bảng riêng. Tuy nhiên, khi danh mục vượt mốc 50.000 SKU và người dùng tích chọn đồng thời 5 bộ lọc thuộc tính trên trang danh mục (Faceted Search), cơ sở dữ liệu phải thực hiện hàng loạt phép nối bảng (JOIN) chồng chéo khiến thời gian phản hồi tăng vọt lên vài giây.
Kiến trúc hiện đại kết hợp mô hình bảng quan hệ chuẩn hóa cho các thuộc tính cốt lõi (Thương hiệu, Danh mục, Khoảng giá, Trạng thái tồn kho) với cột dữ liệu cấu trúc JSONB có đánh chỉ mục đảo ngược (GIN Index trên PostgreSQL) hoặc đồng bộ sang công cụ tìm kiếm chuyên dụng (Elasticsearch / Meilisearch) cho các thuộc tính kỹ thuật đặc thù của từng ngành hàng.
| Tiêu chí kỹ thuật | Mô hình Bảng cột cố định (Flat Table) | Mô hình EAV thuần túy (Entity-Attribute-Value) | Mô hình Quan hệ lai JSONB + Search Index |
|---|---|---|---|
| Khả năng thêm thuộc tính ngành hàng mới | Rất kém, phải chạy lệnh sửa cấu trúc bảng (ALTER TABLE) mỗi khi thêm thuộc tính | Linh hoạt, quản trị viên tự tạo thêm thuộc tính mới trực tiếp trên CMS mà không sửa code | Linh hoạt toàn diện, vừa tự tạo thuộc tính động trên CMS vừa kiểm soát được lược đồ dữ liệu |
| Tốc độ lọc đa tiêu chí (Faceted Filtering) | Nhanh với số lượng cột ít, nhưng suy giảm khi bảng phình to hàng trăm cột rỗng | Rất chậm khi vượt 10.000 SKU do phải thực hiện từ 5 đến 10 phép JOIN bảng liên tiếp | Tốc độ phản hồi dưới 50 – 100ms ngay cả với hàng trăm nghìn SKU và đếm số lượng từng bộ lọc |
| Độ toàn vẹn kiểu dữ liệu (Data Integrity) | Cao, kiểm soát chặt kiểu số nguyên, chuỗi ký tự và khóa ngoại ở tầng cơ sở dữ liệu | Phức tạp, phải tách thành nhiều bảng giá trị theo kiểu chữ, kiểu số, kiểu ngày tháng | Cao nhờ kết hợp cột quan hệ cho dữ liệu giao dịch và bộ kiểm tra JSON Schema tại tầng ứng dụng |
| Quy mô danh mục sản phẩm khuyến nghị | Website chuyên biệt 1 ngành hàng duy nhất, dưới 2.000 mã SKU | Các hệ thống cũ quy mô nhỏ và vừa, ít thao tác lọc kết hợp nhiều điều kiện | Website thương mại điện tử đa ngành, chuỗi bán lẻ và cổng B2B từ 10.000 đến trên 500.000 SKU |
Quản lý chiều dữ liệu Số lô sản xuất (Batch/Lot), Hạn sử dụng (Expiry Date) và Mã Serial/IMEI
Đối với các doanh nghiệp dược phẩm, thực phẩm chức năng, mỹ phẩm, nông sản đóng gói hoặc thiết bị công nghệ, việc định danh đến cấp độ mã SKU vẫn chưa đủ để vận hành thực tế. Cùng một mã SKU là Sữa bột công thức hộp 800g nhưng trong kho hiện có 3 lô nhập hàng khác nhau: Lô A hết hạn vào tháng 12 năm nay, Lô B hết hạn vào tháng 6 năm sau và Lô C mới sản xuất hết hạn vào năm sau nữa.
Nếu cơ sở dữ liệu website chỉ lưu một con số tổng tồn kho duy nhất cho mã SKU đó, doanh nghiệp sẽ không thể thiết lập chương trình giảm giá xả kho riêng cho Lô A cận hạn sử dụng (Clearance Sale cho hàng cận Date) mà không làm giảm giá của Lô B và Lô C mới nhập. Do đó, dưới bảng SKU cần có thêm bảng Thực thể Lô hàng (Inventory Lots/Batches) lưu trữ: Mã lô sản xuất, Ngày sản xuất, Ngày hết hạn, Số lượng tồn theo lô và Ngưỡng dừng bán trước khi hết hạn (Shelf-life Quarantine Days).
Tương tự, với ngành hàng điện thoại, máy tính, đồng hồ cao cấp hoặc máy móc công nghiệp, mỗi đơn vị sản phẩm vật lý trong cùng một mã SKU lại có một mã định danh duy nhất là Số Serial hoặc IMEI. Cơ sở dữ liệu cần quản lý bảng Serial Numbers gắn với từng SKU và cập nhật trạng thái của từng mã Serial từ Lúc nhập kho -> Đã gán cho đơn hàng Website -> Đã kích hoạt bảo hành điện tử.
- Tự động trừ tồn kho ảo đối với các lô hàng đã chạm ngưỡng cận hạn sử dụng quy định (ví dụ: ngừng bán tự động trên kênh tiêu chuẩn khi thời hạn sử dụng còn dưới 60 ngày) và chuyển sang danh mục Hàng thanh lý cận hạn có cảnh báo rõ ràng cho người mua.
- Hiển thị minh bạch thông tin Hạn sử dụng dự kiến của lô hàng hiện hành ngay trên trang chi tiết sản phẩm của website để gia tăng niềm tin cho người tiêu dùng khi mua thực phẩm, mỹ phẩm trực tuyến.
- Ràng buộc quy trình xuất kho: nhân viên đóng gói bắt buộc phải quét mã Serial/IMEI của chiếc máy thực tế đưa vào hộp để hệ thống lưu vết vào chi tiết đơn hàng và kích hoạt phiếu bảo hành điện tử tự động.
- Hỗ trợ quy đổi đa đơn vị tính (Multi-UOM Conversion Table) ngay trên cùng một SKU gốc: liên kết tỷ lệ 1 Thùng = 24 Lon, 1 Lốc = 6 Lon để khi khách mua lẻ 1 Lốc hay đại lý mua 5 Thùng thì hệ thống đều quy về trừ trên cùng một bể tồn kho đơn vị cơ sở.
Tối ưu hóa giao diện chọn biến thể (Variant Selector UX) và ngăn chặn nghẽn truy vấn khi tải trang
Một cấu trúc cơ sở dữ liệu tốt phải đi đôi với cơ chế truyền tải dữ liệu lên giao diện người dùng (Frontend Payload) tinh gọn. Khi một dòng sản phẩm có 3 thuộc tính phân loại gồm 10 Màu sắc, 6 Kích cỡ và 3 Chất liệu (tạo thành 180 biến thể SKU con), nếu mỗi lần người dùng bấm đổi từ Màu Đỏ sang Màu Xanh mà trình duyệt lại phải gửi một yêu cầu mạng về máy chủ để hỏi xem những kích cỡ nào còn hàng thì trải nghiệm mua sắm sẽ trở nên giật cục.
Giải pháp kỹ thuật là biên dịch sẵn một Ma trận khả dụng biến thể (Variant Availability Matrix) gọn nhẹ dưới dạng đối tượng JSON và nhúng trực tiếp vào dữ liệu tải trang ban đầu (Server-Side Rendering) hoặc lưu trên bộ nhớ đệm biên (Edge CDN). Ngay khi người mua bấm chọn Màu Xanh, mã lệnh trên trình duyệt tra cứu tức thì trong ma trận để làm mờ (Disable) các nút Kích cỡ đã hết hàng trong 0 mili giây mà không cần gọi lại cơ sở dữ liệu gốc.
Đồng thời, mỗi khi có biến động tồn kho hoặc thay đổi giá từ hệ thống ERP/WMS đẩy sang, hệ thống chỉ thực hiện xóa bộ nhớ đệm có chọn lọc theo đúng thẻ định danh của sản phẩm đó (On-demand Cache Invalidation by Tag) thay vì xóa toàn bộ bộ nhớ đệm của cả website, giúp máy chủ luôn duy trì mức tải ổn định ngay cả trong các chiến dịch mở bán lớn.
- Tự động chuyển đổi thư viện ảnh sản phẩm (Image Gallery Switching) theo thuộc tính chính: khi người dùng bấm vào ô màu Xanh Navy, toàn bộ ảnh đại diện và ảnh chi tiết lập tức đổi sang bộ ảnh chụp thực tế của mẫu màu Xanh Navy.
- Cấu hình thông báo Khi có hàng trở lại (Back-in-Stock Notification) ở cấp độ từng biến thể SKU: khách hàng muốn mua Cỡ M nhưng đang tạm hết có thể để lại Zalo/Email cho riêng Cỡ M, hệ thống sẽ tự động nhắn tin ngay khi kho nhập thêm đúng cỡ đó.
- Hiển thị bộ lọc thông minh trên trang danh mục (Dynamic Facet Counts): nếu khách đang lọc tìm Giày chạy bộ Cỡ 42, hệ thống chỉ hiển thị những mẫu giày mà biến thể Cỡ 42 thực sự còn tồn kho lớn hơn 0, thay vì hiển thị những đôi giày còn hàng Cỡ 39 nhưng đã hết sạch Cỡ 42.
- Kiểm tra tính nhất quán dữ liệu định kỳ (Data Integrity Job): tự động phát hiện các sản phẩm gốc SPU không có biến thể SKU nào đang hoạt động hoặc các SKU bị thiếu thông tin trọng lượng, kích thước gây lỗi tính phí vận chuyển.
Câu hỏi thường gặp
Giải đáp nhanh những điểm thương hiệu bán lẻ D2C, chuỗi cửa hàng đa chi nhánh, doanh nghiệp sản xuất – phân phối B2B và đơn vị xây dựng sàn giao dịch thương mại điện tử hay hỏi về chủ đề này.
Một sản phẩm trên website nên có tối đa bao nhiêu chiều thuộc tính phân loại biến thể (Variant Axes) để người mua không bị rối?
Về mặt cơ sở dữ liệu, hệ thống có thể hỗ trợ không giới hạn số chiều thuộc tính. Tuy nhiên, xét về trải nghiệm người dùng trên màn hình điện thoại di động, mỗi sản phẩm SPU chỉ nên có từ 1 đến tối đa 3 chiều phân loại biến thể trực tiếp (ví dụ: Màu sắc, Kích cỡ và Quy cách đóng gói). Nếu có nhiều hơn 3 chiều thông số như các linh kiện công nghiệp, nên chuyển sang giao diện bảng chọn cấu hình kèm bộ lọc nhanh.
Làm thế nào để khi khách lọc sản phẩm theo Màu Đỏ trên trang danh mục thì ảnh đại diện của các sản phẩm hiện ra cũng tự động chuyển sang ảnh Màu Đỏ?
Nhờ việc gắn trực tiếp bộ ảnh đại diện riêng cho từng bản ghi SKU con và đánh chỉ mục thuộc tính màu sắc ở cấp độ SKU trong bộ máy tìm kiếm. Khi truy vấn lọc chứa điều kiện Màu Đỏ, API danh mục sẽ lấy ảnh đại diện của biến thể SKU Màu Đỏ đính kèm làm ảnh hiển thị trên thẻ sản phẩm (Product Card) thay vì dùng ảnh mặc định của sản phẩm gốc SPU.
Nếu doanh nghiệp vừa bán lẻ theo Hộp vừa bán theo Combo 3 Hộp tặng 1 Bình nước thì có phải chia tồn kho ra làm hai nơi không?
Không cần chia tách tồn kho vật lý. Hệ thống sử dụng cấu trúc Virtual Bundle SKU (SKU tổ hợp ảo): tồn kho của mã Combo được tính toán tự động theo thời gian thực dựa trên số lượng tồn khả dụng của Hộp sản phẩm chính và Bình nước quà tặng trong kho. Khi khách mua 1 Combo, hệ thống tự động xuất 3 Hộp và 1 Bình nước từ bể tồn kho chung.
Nhận tư vấn kiến trúc & Báo giá chi tiết hệ thống Website Thương mại điện tử
Hãy cho Uptech biết mô hình bán hàng của bạn (B2C, B2B hay Đa kho/Sàn), số lượng mã sản phẩm (SKU) dự kiến và các phần mềm cổng thanh toán, vận chuyển, ERP/POS cần kết nối. Kỹ sư giải pháp của Uptech sẽ phân tích và gửi bản đề xuất kiến trúc kèm dự toán chi phí minh bạch trong 24 giờ làm việc.
- Phản hồi kèm sơ đồ kiến trúc đề xuất trong vòng 24 giờ làm việc
- Tư vấn miễn phí lộ trình đồng bộ tồn kho ERP/POS và cấu trúc SEO danh mục lớn
- Hợp đồng pháp nhân rõ ràng, bàn giao mã nguồn, xuất hóa đơn GTGT (VAT) đầy đủ