Chuyển dữ liệu sang osCMax đòi hỏi cách đọc mô hình dữ liệu theo nhiều lớp. Nền tảng kế thừa nhiều khái niệm quen thuộc từ osCommerce, nhưng bản cài đặt đích cụ thể còn có thể chứa các trường do gói mở rộng bổ sung, bảng tùy chỉnh, mã đã sửa, quy ước của template và mã tham chiếu từ hệ thống ngoài. Vì vậy, không thể quyết định đích đến của một giá trị chỉ vì tên trường trên nguồn và osCMax trông tương tự nhau.
Cần bắt đầu từ ý nghĩa mà mỗi giá trị phục vụ trong hoạt động kinh doanh, xác định cấu trúc nào trên đích sẽ sở hữu ý nghĩa đó và tách những hành vi phải được cấu hình riêng. Dữ liệu cốt lõi, dữ liệu do gói mở rộng sở hữu, tài nguyên hiển thị và mã định danh hệ thống ngoài có trách nhiệm di chuyển dữ liệu khác nhau, dù chúng cùng xuất hiện trong một quy trình trên storefront.
Ý nghĩa dữ liệu trên osCMax bắt đầu từ chính bản đích đã chọn
Mô hình dữ liệu của osCMax phải được xác định từ bản cài đặt thực tế sẽ nhận dữ liệu. Schema cơ sở dữ liệu, tập gói mở rộng, các trường tùy chỉnh, template, cấu trúc ngôn ngữ và kết nối hệ thống ngoài mới phản ánh đích đến chính xác hơn một nhãn nền tảng chung chung.
| Lớp dữ liệu trên đích | Ví dụ thường gặp | Ý nghĩa đối với di chuyển dữ liệu |
|---|---|---|
| Cấu trúc kế thừa từ osCommerce | Products, Categories, manufacturers, Customers, địa chỉ, Orders, Reviews | Quan hệ quen thuộc vẫn cần được diễn giải lại từ nguồn sang đích. |
| Phần mở rộng thuộc gói osCMax | Trường quản trị bổ sung, cấu trúc nội dung, cách xử lý giá hoặc Customers | Cần xác định giá trị là dữ liệu, cấu hình hay thành phần hiển thị. |
| Gói mở rộng được cài thêm | Bảng/trường bổ sung, quy tắc giảm giá, giá theo nhóm, tồn kho mở rộng, module nội dung | Chỉ đưa dữ liệu vào khi cấu trúc và quan hệ đó thực sự nằm trong thiết kế đích đã chấp nhận. |
| Phần tùy chỉnh | Cột bổ sung, bảng riêng, PHP đã chỉnh sửa, báo cáo/xuất dữ liệu riêng | Cần người phụ trách rõ và có thể vượt quá phạm vi xử lý di chuyển dữ liệu được hỗ trợ. |
| Hệ thống bên ngoài | ERP, CRM, kho, kế toán, marketplace, nhà cung cấp, hệ thống vận chuyển | Cần duy trì mã định danh ổn định và ranh giới hệ thống sở hữu dữ liệu. |
| Template và môi trường vận hành | Template, InfoBox, tệp ngôn ngữ, module thanh toán/vận chuyển, cấu hình server | Thuộc triển khai trên Nền tảng đích, không phải dữ liệu di chuyển dữ liệu thông thường. |
Cách phân lớp này ngăn hai sai lầm trái ngược: gom dữ liệu nguồn có ý nghĩa vào các trường chung chung, hoặc coi mọi thành phần kỹ thuật trên osCMax là dữ liệu mà di chuyển dữ liệu phải ghi vào.
Products, Categories, manufacturers và attributes tạo nên cấu trúc danh mục cốt lõi
Danh mục osCMax thường xoay quanh Products, Categories, manufacturers, mô tả, hình ảnh, tồn kho, giá, specials, Reviews và attributes. Các khái niệm này dễ nhận biết, nhưng quan hệ giữa chúng có thể khác Nền tảng nguồn.
Nguồn có thể quản lý mỗi variant như một bản ghi có thể bán độc lập, trong khi osCMax đích lại thể hiện lựa chọn mua hàng qua attributes và các giá trị tùy chọn. Nguồn khác có thể tách thuộc tính dùng để mô tả/khám phá sản phẩm khỏi tùy chọn dùng để mua. Vì vậy, di chuyển dữ liệu phải xác định mối quan hệ nguồn nào sẽ trở thành Products, attributes, giá trị tùy chọn, quan hệ Categories hoặc cấu trúc do gói mở rộng sở hữu trên đích.
Các trường hợp Products đại diện nên gồm:
- Products đơn giản với một mức giá và trạng thái tồn kho;
- Products có tùy chọn hoặc attributes để khách hàng lựa chọn;
- Products có lựa chọn làm thay đổi giá, trọng lượng, tồn kho, model hoặc hình ảnh;
- Products thuộc nhiều Categories;
- Products có quan hệ với manufacturer và Reviews;
- Products có trường thương mại do nhóm Customers hoặc gói mở rộng kiểm soát;
- Products có mã định danh ngoài mà hệ thống khác vẫn cần sử dụng.
Việc đưa dữ liệu sang đích chỉ đạt yêu cầu khi giữ được định danh mặt hàng có thể bán và ý nghĩa khám phá sản phẩm, chứ không chỉ sao chép tên trường.
Tổ hợp attributes, tồn kho, hình ảnh và giá có thể phụ thuộc vào gói mở rộng
Các bản osCMax legacy có thể mở rộng mô hình attributes cơ bản bằng tồn kho theo tổ hợp, cách xử lý hình ảnh nâng cao, model/SKU bổ sung, điều chỉnh giá hoặc cách Products hoạt động khác. Do đó, phải kiểm tra cấu trúc của bản đích trước khi chuyển cách biểu diễn từ nguồn sang.
Nếu đích chỉ dùng attributes cơ bản, một variant nguồn có tồn kho độc lập có thể không có quan hệ tương đương trực tiếp. Nếu đích cài gói mở rộng quản lý tồn kho theo tổ hợp, dự án phải xác nhận gói đó nhận diện từng tổ hợp như thế nào và những bản ghi đích nào nằm trong phạm vi di chuyển dữ liệu có thể ghi dữ liệu. Cùng nguyên tắc này áp dụng cho cấu trúc hình ảnh mở rộng, giá theo nhóm Customers, specials và dữ liệu danh mục do gói mở rộng sở hữu.
Quy tắc cần giữ là ý nghĩa nguồn sang đích trước, vị trí trong cơ sở dữ liệu sau. Một cột tùy chỉnh chỉ có giá trị khi mã hoặc quy trình nghiệp vụ trên đích sẽ tiếp tục đọc và sử dụng dữ liệu đó.
Customers, sổ địa chỉ, nhóm khách hàng và dữ liệu mở rộng phải được tách riêng
Khi chuyển Customers sang osCMax, cần phân biệt định danh tài khoản, thông tin liên hệ, địa chỉ, nhóm khách hàng, quyền truy cập và dữ liệu tài khoản do gói mở rộng sở hữu.
Customers ở nguồn có thể có nhiều địa chỉ, trạng thái thuế, phân loại wholesale, nhóm giá, trạng thái phê duyệt, đăng ký nhận tin, ID tài khoản ngoài hoặc các thuộc tính khác. Mỗi ý nghĩa cần có nơi sở hữu rõ trên đích. Chỉ sao chép tên nhóm là không đủ nếu nhóm đó thực sự thay đổi giá, mức độ hiển thị, thuế hoặc quyền truy cập.
Mô hình tài khoản cũng cần quyết định riêng về xác thực. Việc bản ghi Customers được chuyển sang không chứng minh rằng mật khẩu cũ có thể tiếp tục sử dụng. Cách xử lý mật khẩu phải tuân theo phạm vi di chuyển dữ liệu được hỗ trợ và mô hình xác thực của đích, thay vì suy ra từ việc địa chỉ email vẫn tồn tại.
Orders, các thành phần tổng tiền, trạng thái, thanh toán và vận chuyển là dữ liệu lịch sử
Lịch sử đơn hàng là bằng chứng về giao dịch đã xảy ra. Các bản ghi này phải tiếp tục dễ hiểu ngay cả khi osCMax đích sử dụng cấu hình thanh toán, vận chuyển, thuế hoặc khuyến mãi khác.
Dữ liệu lịch sử đơn hàng được chấp nhận có thể gồm:
- Products đã mua và tùy chọn được chọn;
- số lượng và đơn giá;
- subtotal, thuế, giảm giá, phí vận chuyển, surcharge, voucher và grand total;
- địa chỉ thanh toán và giao hàng;
- nhãn phương thức thanh toán và vận chuyển;
- trạng thái và lịch sử trạng thái;
- ghi chú và thời gian;
- mã tham chiếu hệ thống ngoài nếu vẫn còn giá trị vận hành.
Các thành phần tổng tiền cần được xem xét riêng vì những hệ thống kế thừa từ osCommerce thường lưu subtotal, thuế, vận chuyển, giảm giá, voucher và các điều chỉnh khác thành những bản ghi khác nhau. Chỉ dựng lại grand total có thể khiến nhân viên không còn giải thích được giao dịch lịch sử.
Những bản ghi này không thay thế cấu hình checkout hiện tại. Module thanh toán, module vận chuyển, thông tin xác thực, cấu hình thuế, cập nhật tồn kho, email, hoàn tiền và quy trình xuất dữ liệu thuộc phần triển khai Cửa hàng đích, trừ khi một phạm vi dữ liệu được chấp nhận quy định rõ khác đi.
Nội dung, InfoBox, template, tệp ngôn ngữ và hình ảnh có chủ sở hữu khác nhau
Thông tin hiển thị trên storefront osCMax có thể được sở hữu bởi nhiều cấu trúc. Một phần nội dung nằm trong bản ghi. Phần khác có thể thuộc cấu trúc kiểu Article Manager, module trang thông tin, tệp ngôn ngữ, template, banner, InfoBox hoặc mã tùy chỉnh.
Vì vậy, cần phân loại theo mục đích:
| Mục đích nội dung từ nguồn | Nơi có thể sở hữu trên osCMax đích |
|---|---|
| Trang thông tin hoặc chính sách | Bản ghi nội dung được hỗ trợ hoặc cấu trúc CMS/module phù hợp nếu bản đích có. |
| Tin tức/bài viết | Gói quản lý bài viết/nội dung nếu đây là thành phần đã được chấp nhận của bản đích. |
| Mô tả Products/Categories | Trường mô tả tương ứng của Products hoặc Categories. |
| Khối quảng bá | Cấu hình module nội dung hoặc template trên đích. |
| Nhãn giao diện | Tài nguyên ngôn ngữ/template, không mặc định là bản ghi CMS. |
| Metadata SEO | Trường Products, Categories, nội dung hoặc cấu trúc URL được hỗ trợ trên đích. |
Template và các tệp nút không nên bị biến thành dữ liệu di chuyển dữ liệu chỉ vì chúng chứa chữ hoặc hình ảnh. Cần xác định đúng nơi sở hữu trên đích.
Gói mở rộng và bảng tùy chỉnh có thể sở hữu dữ liệu quan trọng
Một Nền tảng đích Open Source legacy có thể cho phép tạo thêm cấu trúc cơ sở dữ liệu, nhưng việc có thể chỉnh sửa cơ sở dữ liệu không biến mọi cấu trúc nguồn thành đích di chuyển dữ liệu được hỗ trợ.
Với dữ liệu thuộc gói mở rộng hoặc bảng tùy chỉnh, hãy trả lời bốn câu hỏi:
- Dữ liệu nguồn mang ý nghĩa kinh doanh gì?
- Bản osCMax đã chọn có trường hoặc bảng đích thực sự được thiết kế để sở hữu ý nghĩa đó hay không?
- Cấu trúc đích có nằm trong phạm vi xử lý được hỗ trợ của lộ trình chuyển đổi đã chọn hay không?
- Module, mã tùy chỉnh, báo cáo hoặc hệ thống ngoài nào sẽ tiếp tục sử dụng dữ liệu sau di chuyển dữ liệu?
Nếu cấu trúc đích chỉ tồn tại vì sẽ có mã tùy chỉnh được phát triển sau này, phần nạp dữ liệu và phần triển khai ứng dụng phải được giữ thành hai phạm vi riêng. Nếu dữ liệu không còn cần thiết, chủ động loại bỏ thường tốt hơn việc sao chép thêm dữ liệu kỹ thuật không còn được sử dụng.
Quyết định chuyển đổi dữ liệu theo đúng ý nghĩa kinh doanh
Thiết kế quan hệ dữ liệu từ nguồn sang osCMax nên ghi nhận kết quả mong muốn, không chỉ đường đi của cột dữ liệu.
| Ý nghĩa ở nguồn | Quyết định trên đích | Câu hỏi xác thực |
|---|---|---|
| Định danh mặt hàng có thể bán | Products cùng cấu trúc attribute/tùy chọn được hỗ trợ hoặc phương án khác đã chấp nhận | Khách hàng có thể chọn và nhận diện đúng mặt hàng cần mua không? |
| Phân nhóm Customers theo thương mại | Nhóm Customers hoặc cấu trúc đích khác có chủ sở hữu rõ | Giá, quyền truy cập hoặc thuế có còn đúng không? |
| Giao dịch lịch sử | Orders, thành phần tổng tiền, trạng thái và các tham chiếu đã chấp nhận | Nhân viên có giải thích được khách đã mua gì và bị tính phí thế nào không? |
| Mục đích nội dung | Nội dung Products/Categories, bản ghi nội dung, module, template hoặc loại bỏ | Nội dung có còn phục vụ đúng nhu cầu khách hàng/tìm kiếm không? |
| Trường tùy chỉnh từ nguồn | Trường đích được hỗ trợ, trường/cột cơ sở dữ liệu đích phù hợp, giá trị được chuyển đổi, hệ thống ngoài, xử lý riêng hoặc loại bỏ | Ai dùng giá trị sau di chuyển dữ liệu và cách biểu diễn trên đích có được hỗ trợ không? |
| Mã định danh hệ thống ngoài | Trường hoặc quan hệ ổn định trên đích | Hệ thống ngoài có kết nối lại đúng bản ghi hay không? |
Những quyết định này làm rõ mô hình dữ liệu đủ để điều khiển các bước đánh giá rủi ro, chuẩn bị, chọn Dịch vụ chuyển đổi dữ liệu và xác thực sau đó.
Kết luận
Không nên xem osCMax như một schema osCommerce chung chung. Khi là Nền tảng đích, mô hình dữ liệu thực tế phụ thuộc vào bản build cụ thể và các gói mở rộng, cấu trúc tùy chỉnh, template, môi trường vận hành và hệ thống ngoài bao quanh dữ liệu cốt lõi.
di chuyển dữ liệu đạt yêu cầu khi duy trì được những mối quan hệ kinh doanh còn giá trị: định danh Products và lựa chọn mua hàng, ngữ cảnh Customers, ý nghĩa của lịch sử đơn hàng, nội dung hữu ích, quan hệ giá và mã tham chiếu bên ngoài. Đồng thời, các thành phần triển khai phải được giữ riêng khỏi dữ liệu di chuyển dữ liệu. Chính ranh giới này giúp một Nền tảng đích legacy có thể được đánh giá và xác thực một cách có cơ sở thay vì chỉ được nạp dữ liệu vào.
Câu hỏi thường gặp
Vì sao hai Cửa hàng đích osCMax có thể có mô hình dữ liệu khác nhau?
Các bản build, gói mở rộng, thay đổi cơ sở dữ liệu, template và phần tùy chỉnh khác nhau có thể mở rộng cùng một nền tảng osCommerce theo những cách khác nhau.
Attributes trên osCMax có giống variants độc lập không?
Attributes trên osCMax không nhất thiết tương đương với variants độc lập. Một variant từ nguồn có thể cần được biểu diễn bằng attributes, cấu trúc tổ hợp do gói mở rộng sở hữu, Products riêng hoặc phương án đích khác đã được chấp nhận.
Nên diễn giải nhóm Customers hoặc các trường dealer như thế nào?
Hãy bắt đầu từ chức năng kinh doanh. Xác định liệu chúng kiểm soát giá, thuế, khả năng hiển thị, quyền truy cập, trạng thái phê duyệt hay kết quả nào khác, rồi gán ý nghĩa đó cho cấu trúc đích có chủ sở hữu rõ.
Vì sao các thành phần tổng tiền trong Orders quan trọng?
Các thành phần này giải thích cách số tiền cuối cùng được hình thành từ subtotal, thuế, vận chuyển, giảm giá, voucher, surcharge và các khoản điều chỉnh khác. Chỉ giữ grand total có thể không giữ được ý nghĩa đó.
Có nên chuyển template, InfoBox, nút và tệp ngôn ngữ như nội dung không?
Không nên mặc định như vậy. Trước tiên cần phân loại mục đích; nhiều thành phần thuộc triển khai template, ngôn ngữ hoặc module trên đích thay vì một bản ghi nội dung di chuyển dữ liệu.
Dữ liệu thuộc gói mở rộng hoặc bảng tùy chỉnh nên được xử lý thế nào?
Chỉ đưa vào di chuyển dữ liệu khi ý nghĩa kinh doanh, cấu trúc đích, quy trình sử dụng tiếp theo và phương án xử lý được hỗ trợ đều rõ. Nếu chưa, hãy chuyển yêu cầu sang đánh giá xử lý riêng, hệ thống ngoài hoặc chủ động loại bỏ.