2K/tự nhom-2ktự hàng-3ky tu chung loại
-GO75001: Sắt góc 75 loại 001
-GA14002: Sắt gai phi 14 loại 002
Có vấn đề gì, nhân thể các bạn cũng tham gia giùm.
Khi nào phần mềm hỗ trợ tra cứu khi gõ:
GO 75 01 thì nó nhảy đúng tới dòng đó mà ko cần có mã như vậy, chỉ cần hàng có các thuộc tính như:
Sắt góc 75 loại
001
Đó là cách mà hiện có nhiều người làm PM đã nghĩ đến (Cách thức tìm kiếm thông minh dạng Google, gõ dấu hoặc ko dấu đều hiện ra)
Nói vậy thôi, chắc mọi người đang nói tơi Excel, còn tôi lại nói tới thiết kế CSDL và trường ID là khóa có kiểu Long dùng để liên kết với các bảng khác, trường Code là UniqueIndex có kiểu Varchar. Thông thường trước kia (và ngày nay) rất nhiều người dùng luôn trường Code làm khóa chính (chính tôi cũng bị dính đòn chuyện này rồi mà bây giờ gỡ ko nổi). Trường Code là 1 trường độc lập trong bảng, ko phải là khóa, không dùng để làm relationship với nhiều bảng khác. Làm thế có lợi như sau:
- Cascade Update là ko dùng tới (Vì ko ai sửa cái ID làm gì cả, họ chỉ sửa Code thôi, mà sửa code thì ko cascade với các bảng khác nên CSDL sẽ chạy rất nhanh, khi nào tới triệu bản ghi các bạn sẽ thấy vấn đề này)
- Nếu dùng Code để làm PK và cascade update sang nhiều bảng khác, chỉ cần quan hệ bố con tới 3 mức thôi là bất kể CSDL nào cũng chịu cứng ko cho phép cascade update. Đó chính là lý do ko sửa code được nếu code làm khóa chính. Ví dụ: Employee có Training History, mỗi 1 training có 1 Cerfiticate. Như vậy là có quan hệ 3 cấp xảy ra. Nếu bạn sửa Employee Code thì đáng ra phải cascade update tới cả bảng Training History và bảng Cerfiticate. Tiếc thay ko có hệ quản trị CSDL nào cho phép làm điều đó. Vì thế các bạn sẽ ko sửa được Code ở chương trình một khi dùng nó làm khóa chính. Còn nếu các bạn dùng ID làm khóa chính, còn trường code chỉ là phụ thôi thì các bạn đang sở hữu 1 CSDL cực ngon rồi đó (vì 70% số lập trình viên ko biết tới những điều này).
- Khi dùng ID (Long) làm khóa chính thì CSDL sẽ chạy nhanh hơn rất nhiều vì relationship sẽ faster nếu thông qua trường số (numeric) chứ ko phải varchar.
Đây là cái đoạn mà các bạn đang bàn tới:
Còn trường code, bạn muốn ghép thuộc tính nào của bản ghi đều được, ghép 1 ký tự, ghép 2 ký tự, độ dài là 10, là 20, là 100 ký tự, thích đặt prefix là ký tự nào (ví dụ: PN001, PX001, PT001, PC001...), subfix là ký tự nào cũng được v.v... Dân coder, ko, chỉ cần những ai trên GPE đều có thể làm được với mấy hàm Left$(), v.v.. gì đó, biết dăm ba lệnh xử lý và ghép string đều có thể làm được những điều đó. Còn chuyện ghép dài hay ghép ngắn, ghép khó hiểu hay dễ hiểu,... đều phụ thuộc vào yêu cầu quản lý của các bạn (quản lý thuốc khác, quản lý phụ tùng khác, quản lý nhân viên khác, quản lý tài sản khác, quản lý xa máy, ô to, bệnh nhân, tài khoản, chứng từ, v.v.... Có rất nhiều loại đối tượng mà ko thể cứ khăng khăng ép cách thức tạo mã của đối tượng nào cũng giống đối tượng nào cả. Nhưng nếu bạn làm công cụ cho người khác, bạn cần cung cấp cái tool, cái option để cho người ta muốn ghép gì thì ghép, ghép ngắn hay dài gì thì tùy họ. Và đó mới là cái đáng bàn!)
Nhưng, lại 1 lần nữa tôi nói, các thông tin dạng non-identify relationship đều thông qua ID (Long) chứ ko phải thông qua mã hay tên đối tượng.
Ví dụ:
tb_Item (Bảng hàng hóa)
===================
ID (Long - PK)
----------------------
Code
Name
....
CategoryID (Long FK) --> non-identify relationship với bảng tb_Category
tb_Category (Bảng nhóm hàng)
=======================
ID (Long - PK)
-------------------
Code
Name
ParentCategoryID (Long - FK, Self Referent relationship)
....
Không hiểu nói thế có phù hợp với GPE hay ko?
I am sorry, ko nói thêm về món này nữa.
P/S: Hãy thử nghĩ tại sao họ lại sinh ra các chuẩn mã vạch như EVN13, EVN8,... hay Identification No toàn là số thôi?
Không ai ghép mã nước, mã tỉnh, mã huyện, STT (có dạng chữ) để tạo thành số CMT cả. Tất cả cái đó được mã hóa dạng số hết. Tương tự, mã số thuế, mã số....
