thảo luận Xin kinh nghiệm thiết kế database

tho go da nang said:

Migration thường dùng tool tùy ngôn ngữ mà viết ORM cho phù hợp, như mình hay xài thằng này https://alembic.sqlalchemy.org/en/latest/tutorial.html#the-migration-environment dễ track được migration logs

Gửi từ Xiaomi Redmi Note 9S bằng vozFApp

Click to expand...

Chắc tại mình hỏi k rõ. Ý mình là nếu nhân viên A làm việc ở phòng P nào đó, sau 1 thời gian phòng đó đổi tên thành Q. Nếu mình đổi tên P thành Q trong table phòng ban, thì tất cả các record của nhân viên A đó sẽ bị đổi tên phòng P thành Q, không thể hiện được quá khứ đã từng ở phòng P. Mình tay ngang nên hơi gà cái này ^^

Sent from Samsung SM-A920F using vozFApp

boytergirl said:

Chắc tại mình hỏi k rõ. Ý mình là nếu nhân viên A làm việc ở phòng P nào đó, sau 1 thời gian phòng đó đổi tên thành Q. Nếu mình đổi tên P thành Q trong table phòng ban, thì tất cả các record của nhân viên A đó sẽ bị đổi tên phòng P thành Q, không thể hiện được quá khứ đã từng ở phòng P. Mình tay ngang nên hơi gà cái này ^^

Sent from Samsung SM-A920F using vozFApp

Click to expand...

Cài này bạn cứ insert nhỉ kiểu có table logs transaction của việc chuyển phòng. Cái này mình nghĩ bạn đang miss giữa concept decentralization với centralization. Như mình làm thì sẽ có table user với table phòng ban, còn các record nhỏ lẻ thì sẽ có chứa join key với table user. Bạn search thêm keyword trên như mình nói để design lại db ha

Gửi từ Xiaomi Redmi Note 9S bằng vozFApp

boytergirl said:

Cho mình ké tí, mình gặp vấn đề thiết kế database nhân sự, phòng ban thì nhiều, rồi nhiều cấp, tách, nhập, đổi tên liên tục. Bạn nào có tài liệu về vấn đề này không, cho mình keyword với

Sent from Samsung SM-A920F using vozFApp

Click to expand...

Rõ ràng yêu cầu đề bài hơn đi bạn.
Theo mình hiểu ý bạn ở đây là bạn đang chưa biết design employee-department model thế nào để đáp ứng:

• Một department có nhiều parent, nhiều child
• Cho phép thay đổi 1/ nhiều parent, child của department đó.
• Employee thì multi department?
• Đảm bảo các chức năng: tách, gộp department. Điều chuyển employee (thuyên chuyển, điều động, biệt phái, ...) giữa các department?

Việc design một model phân cấp (hierarchical database model) thì có gì khó khăn ở đây nhỉ?

À, với cái schema trên thì chắc bạn khó trong việc design để sau này chạy báo cáo cho đúng thôi

boytergirl said:

Chắc tại mình hỏi k rõ. Ý mình là nếu nhân viên A làm việc ở phòng P nào đó, sau 1 thời gian phòng đó đổi tên thành Q. Nếu mình đổi tên P thành Q trong table phòng ban, thì tất cả các record của nhân viên A đó sẽ bị đổi tên phòng P thành Q, không thể hiện được quá khứ đã từng ở phòng P. Mình tay ngang nên hơi gà cái này ^^

Sent from Samsung SM-A920F using vozFApp

Click to expand...

Mình hiểu bạn đang lưu departmentId. Thì department có đổi tên là gì, department vẫn giữ được Id chứ nhỉ?

Chỗ báo cáo bạn cần gì thì nêu ra, ghi log lại hoặc thêm/ dùng cột nào để tính effort cũng đc mà

Đưa ra 1 vài phương án thế này nhé. Bạn xem phù hợp không.

• Department tạo ra rồi thì ko chuyển nút cha của nó. Muốn chuyển nhân viên A từ phòng X sang phòng Y thì làm chức năng chuyển 1 hoặc chuyển nhiều
• Tất cả các thực thể dạng transaction đều lưu DepartmentId và thời gian để tiện cho việc báo cáo
• Trong trường hợp cần gộp phòng ban thì hãy làm chức năng gộp phòng ban, bao gồm việc thay đổi tất cả các DepartmentId tương ứng của các thực thể dạng transaction ( nếu thực hiện điều này sẽ làm mất tính đúng đắn của báo cáo đó)
• Mình không thích dùng từ Department lắm, thích dùng từ Organization hơn

Cảm ơn mọi người tư vấn. Để tối rảnh mình vẽ cái lược đồ nhìn cho dễ hiểu. Nay bận quá

Sent from Samsung SM-A920F using vozFApp

boytergirl said:

Cụ thể hơn tí được không, mình tưởng migration là move database từ instance này sang instance khác chứ nhỉ?

Sent from Samsung SM-A920F using vozFApp

Click to expand...

tưởng bác muốn thay đổi rồi lưu lại version

the_ruler said:

Rõ ràng yêu cầu đề bài hơn đi bạn.
Theo mình hiểu ý bạn ở đây là bạn đang chưa biết design employee-department model thế nào để đáp ứng:

• Một department có nhiều parent, nhiều child
• Cho phép thay đổi 1/ nhiều parent, child của department đó.
• Employee thì multi department?
• Đảm bảo các chức năng: tách, gộp department. Điều chuyển employee (thuyên chuyển, điều động, biệt phái, ...) giữa các department?

Việc design một model phân cấp (hierarchical database model) thì có gì khó khăn ở đây nhỉ?

À, với cái schema trên thì chắc bạn khó trong việc design để sau này chạy báo cáo cho đúng thôi

Click to expand...

Anh cho em hỏi sao để tìm ra quan hệ một nhiều, nhiều nhiều, một một chuẩn từ đầu được không? Em cứ bắt đầu vào viết code mới biết đang nhầm quan hệ, loạn hết lên.

thaiviptn1201 said:

Anh cho em hỏi sao để tìm ra quan hệ một nhiều, nhiều nhiều, một một chuẩn từ đầu được không? Em cứ bắt đầu vào viết code mới biết đang nhầm quan hệ, loạn hết lên.

Click to expand...

Mình hỏi đơn giản thế này nha.
Để định nghĩa được một bảng dữ liệu trong db hay một object trong ORM gồm những field gì, type gì, các attr khác sao thì bạn cần làm những bước gì?
Bạn trả lời câu hỏi đó trước rồi mình sẽ cùng bạn tìm ra lời giải cho câu hỏi của bạn.

via theNEXTvoz for iPhone

Mình post ảnh cho chi tiết. Ví dụ mình có các table này:

Với các record quá trình công tác của nhân viên A:

Khi mình đổi tên Phòng Tài Chính - Kế hoạch trong table Phong thì tên phòng khi truy vấn cũng thay đổi theo (ID phòng vẫn giữ nguyên trong table ViTri). Sau này khi làm báo cáo sẽ không thể hiện nhân viên A từng công tác tại Phòng Tài chính - Kế hoạch. Có cách nào khi tên phòng thay đổi hoặc tách nhập phòng mà vẫn thể hiện chính xác được không ạ?

Cứ nghĩ đơn giản thôi, rồi làm theo những gì mình đã lên kế hoạch. Tự trải nghiệm và rút ra kinh nghiệm bản thân thôi. Vì cái gì cũng có 2 mặt của nó.
Ví dụ: trường tên sản phẩm chẳng hạn. Vì muốn tối ưu hóa bộ nhớ và truy xuất, bạn đặt max ký tự là 25. Ban đầu chương trình của bạn chạy OK. Nhưng sau đấy phát sinh các sản phẩm có tên dài, hoặc vì lí do gì đó mà tên sản phẩm phải đi kèm xuất xứ, bạn phải tăng max ký tự lên.
Còn sau đây là một số kinh nghiệm thiết kế dataBase mà mình sưu tầm và tự rút ra được:


1. Phân tích kỹ các kịch bản trước khi thiết kế dữ liệu:
Bạn cần phải đảm bảo cân bằng giữa giảm dung lượng lưu trữ với những trường, bảng dữ liệu trong tương lai, để đạt hiệu quả tối ưu nhất

2. Cách đặt tên bảng trong Data Base:

a) Tên bảng dễ hiểu, đồng thời cần có template nhất định như sử dụng camel
VD: SinhVien, nguoiDung, ...

b) Đặt tên số ít: Nếu đặt tên bảng bằng tiếng Anh thì nên đặt số ít
VD: nên đặt là History không nên đặt Histories

c) Không sử dụng dấu cách trong tên bảng
Nếu muốn các chữ trong tên bảng tách ra cho dễ nhìn thì hãy dùng _ đừng dùng dấu cách
VD: Không nên đặt là [Sinh vien] mà nên đặt là Sinh_Vien

3. Chia nhỏ bảng để tăng tính linh động và mềm dẻo
Trong ví dụ của thớt nếu không chắc chắn là quan hệ n - n hay không hoặc có thể phát sinh quan hệ n - n trong tương lai, ta nên tạo thêm 1 bảng trung gian chỉ có 3 trường id của bảng trung gian, userID và bookingID => để dễ dàng kiểm soát

4. Xác định số cột truy vấn
Khi truy vấn dữ liệu, cần xác định các cột (trường) để lấy dữ liệu, tránh trường hợp:
select * from someTable
dẫn đến trường hợp chậm trả về kết quả

Đấy là kinh nghiệm của em, các bác có gì cho ý kiến

boytergirl said:

Khi mình đổi tên Phòng Tài Chính - Kế hoạch trong table Phong thì tên phòng khi truy vấn cũng thay đổi theo (ID phòng vẫn giữ nguyên trong table ViTri). Sau này khi làm báo cáo sẽ không thể hiện nhân viên A từng công tác tại Phòng Tài chính - Kế hoạch. Có cách nào khi tên phòng thay đổi hoặc tách nhập phòng mà vẫn thể hiện chính xác được không ạ?

Click to expand...

Câu hỏi OK hơn rồi đó. Bạn đang hướng câu hỏi tới việc reporting cho dữ liệu.

Theo những gì bạn hỏi thì mình giả định bạn chưa biết các kiến thức cơ bản về OLAP Databse như star schema, dimension table, fact table, slowly changing dimension (SCD 0,1,2,3,4,5,6), rapidly changing dimensions (RCD).

Còn câu trả lời cho câu hỏi của bạn, bạn thử nghĩ theo hướng này nhé:
Trong table Phong của bạn:

• Thêm 3 col: TuNgay, DenNgay, HieuLuc (col HieuLuc này có thể bạn thấy hơi thừa, bỏ đi cũng được, thêm vào thì chạy báo cáo cho thời điểm cuối cùng sẽ nhanh hơn)
• Mỗi khi phòng đó được rename thì sẽ sinh ra một bản ghi mới và update các thông tin tương ứng.
• Khi đó báo cáo của bạn sẽ có thể lấy được tên phòng ban ở một thời điểm trong quá khứ đúng không.

Theo mình, nếu bạn có thời gian thì có thể tìm hiểu các keyword trên, khi đó bạn sẽ hiểu được vì sao lại làm như trên nhé, có quy chuẩn cả đó.

By the way: Tìm hiểu về OLAP vs OLTP - Chú ý ở điểm này, vì sao lại đẻ ra những thằng như bọn mình chuyên đi thiết kế mấy con OLAP nhé.

Đừng đổi tên phòng, khi muốn đổi tên hoặc gộp thì tạo bản ghi mới cho phòng mới. Đánh dấu những phòng cũ "không hoạt động (isActive: false)" kiểu vậy. Rồi chuyển toàn bộ nhân viên từ phòng cũ sang phòng mới luôn. Quả "TuNgay, DenNgay" thì tùy nghiệp vụ mà sửa cho nhân viên khi đổi tên (gộp) phòng.

the_ruler said:

Câu hỏi OK hơn rồi đó. Bạn đang hướng câu hỏi tới việc reporting cho dữ liệu.

Theo những gì bạn hỏi thì mình giả định bạn chưa biết các kiến thức cơ bản về OLAP Databse như star schema, dimension table, fact table, slowly changing dimension (SCD 0,1,2,3,4,5,6), rapidly changing dimensions (RCD).

Còn câu trả lời cho câu hỏi của bạn, bạn thử nghĩ theo hướng này nhé:
Trong table Phong của bạn:

• Thêm 3 col: TuNgay, DenNgay, HieuLuc (col HieuLuc này có thể bạn thấy hơi thừa, bỏ đi cũng được, thêm vào thì chạy báo cáo cho thời điểm cuối cùng sẽ nhanh hơn)
• Mỗi khi phòng đó được rename thì sẽ sinh ra một bản ghi mới và update các thông tin tương ứng.
• Khi đó báo cáo của bạn sẽ có thể lấy được tên phòng ban ở một thời điểm trong quá khứ đúng không.

Theo mình, nếu bạn có thời gian thì có thể tìm hiểu các keyword trên, khi đó bạn sẽ hiểu được vì sao lại làm như trên nhé, có quy chuẩn cả đó.

By the way: Tìm hiểu về OLAP vs OLTP - Chú ý ở điểm này, vì sao lại đẻ ra những thằng như bọn mình chuyên đi thiết kế mấy con OLAP nhé.

Click to expand...

Bắt đúng bệnh luôn. Mình tay ngang, do làm tổng hợp số liệu thấy cực quá nên mày mò MS Access, rồi kết hợp MS Access với SQL Server, SSRS, học được những cái cơ bản của RDBM. Kiến thức thì ít mà tham vọng thì nhiều. Mình muốn tự build một MIS (dùng dotnet) vì MS Access rất hạn chế khi mở rộng quy mô quản lý. Giờ mới thấy riêng bài toán thiết kết database đã khó nhằn, chưa kể back end, front end, ti tỉ thứ phải học. Theo bạn, với những người tay ngang như mình, kiến thức hạn chế thì học gì, làm gì là hợp lý nhất để xây dựng những hệ thống riêng phục vụ cho công việc của mình.

boytergirl said:

Bắt đúng bệnh luôn. Mình tay ngang, do làm tổng hợp số liệu thấy cực quá nên mày mò MS Access, rồi kết hợp MS Access với SQL Server, SSRS, học được những cái cơ bản của RDBM. Kiến thức thì ít mà tham vọng thì nhiều. Mình muốn tự build một MIS (dùng dotnet) vì MS Access rất hạn chế khi mở rộng quy mô quản lý. Giờ mới thấy riêng bài toán thiết kết database đã khó nhằn, chưa kể back end, front end, ti tỉ thứ phải học. Theo bạn, với những người tay ngang như mình, kiến thức hạn chế thì học gì, làm gì là hợp lý nhất để xây dựng những hệ thống riêng phục vụ cho công việc của mình.

Click to expand...

Chơi tool nhé.
Đừng cố gắng đi sâu xuống dưới khi việc chưa work. Lời khuyên của mình là như vậy.
Hãy làm cho việc nó work trước đã, khi đó bạn sẽ có thêm thời gian để đi top-down. Đừng cố gắng đi theo dạng bottom-up.

Trước mắt bạn nên thu nhỏ dần bài toán của bạn lại. MIS là một định nghĩa quá rộng, bạn có thể bóc tách dần nó xuống xem thực sự nó là hệ thống như nào.

Hoặc đơn giản hơn là bạn nên bài toán của bạn ra đây, cụ thể các yêu cầu mà bạn mong muốn, từ to tới nhỏ hoặc từ nhỏ tới to (làm cái mindmap càng tốt). Sẽ có người tư vấn cho bạn cái phù hợp.

the_ruler said:

Chơi tool nhé.
Đừng cố gắng đi sâu xuống dưới khi việc chưa work. Lời khuyên của mình là như vậy.
Hãy làm cho việc nó work trước đã, khi đó bạn sẽ có thêm thời gian để đi top-down. Đừng cố gắng đi theo dạng bottom-up.

Trước mắt bạn nên thu nhỏ dần bài toán của bạn lại. MIS là một định nghĩa quá rộng, bạn có thể bóc tách dần nó xuống xem thực sự nó là hệ thống như nào.

Hoặc đơn giản hơn là bạn nên bài toán của bạn ra đây, cụ thể các yêu cầu mà bạn mong muốn, từ to tới nhỏ hoặc từ nhỏ tới to (làm cái mindmap càng tốt). Sẽ có người tư vấn cho bạn cái phù hợp.

Click to expand...

Keyword 1 đống kia rồi, chưa tìm hiểu mà cứ đi hỏi thì k hay. Mình hỏi nốt câu này thôi, tại vì nghĩ lâu rồi mà không có hướng giải quyết. Ví dụ ở huyện X có phòng A, B, C, huyện Y có phòng A, B, C, D. Rồi dưới phòng thì có tổ, nhóm. Vậy thiết kế cái bảng Phong, ViTri (Vị trí ) kia thế nào cho hợp lý. Có phải nó liên quan đến từ khóa hierarchy data model không?

boytergirl said:

Ví dụ ở huyện X có phòng A, B, C, huyện Y có phòng A, B, C, D. Rồi dưới phòng thì có tổ, nhóm. Vậy thiết kế cái bảng Phong, ViTri (Vị trí ) kia thế nào cho hợp lý. Có phải nó liên quan đến từ khóa hierarchy data model không?

Click to expand...

Vị trí của bạn ở đây là Vị trí địa lý (Location) hay Vị trí công tác - Chức vụ (Position) vậy?

Như bạn đang nói thì mình hiểu là Location. Mối quan hệ Phong - ViTri sẽ là quan hệ nhiều nhiều (m-n) nhé.

the_ruler said:

Vị trí của bạn ở đây là Vị trí địa lý (Location) hay Vị trí công tác - Chức vụ (Position) vậy?

Như bạn đang nói thì mình hiểu là Location. Mối quan hệ Phong - ViTri sẽ là quan hệ nhiều nhiều (m-n) nhé.

Click to expand...

Position bạn ạ. Vì huyện X và Y đều có phòng A, ở table Position làm sao phân biệt được phòng A nào thuộc huyện nào. Ví dụ chuyển từ phòng A sang B trong nội bộ huyện X, phòng A huyện X sang phòng B huyện Y. Không lẽ phòng A huyện X có ID riêng, phòng A huyện Y có ID riêng, mà nếu không có ID riêng thì table Postion phải thêm col ID của huyện, nếu tổ chức có nhiều cấp thì phải thêm 01 col ID cho cấp đó. Mình không biết thiết kế thế nào cho hợp lý.

học hướng đối tượng trước là dễ nhất

boytergirl said:

Position bạn ạ. Vì huyện X và Y đều có phòng A, ở table Position làm sao phân biệt được phòng A nào thuộc huyện nào. Ví dụ chuyển từ phòng A sang B trong nội bộ huyện X, phòng A huyện X sang phòng B huyện Y. Không lẽ phòng A huyện X có ID riêng, phòng A huyện Y có ID riêng, mà nếu không có ID riêng thì table Postion phải thêm col ID của huyện, nếu tổ chức có nhiều cấp thì phải thêm 01 col ID cho cấp đó. Mình không biết thiết kế thế nào cho hợp lý.

Click to expand...

Bác không có kiến thức về CSDL nên đúng là giải thích cũng hơi khó nhỉ
Chặc, để tránh làm loãng thread thì bác có thể inbox mình làm cái ERR cho bác.