thắc mắc Thiết kế database - quan hệ giữa các bảng

Trong lúc tìm chủ đề cũng như best practice để làm backend cho đồ án tốt nghiệp, em thấy project này họ không có liên kết nào cả, chỉ thêm association trong code; so sánh với db của công ty dùng magento thấy cỡ trăm cái liên kết . Em làm frontend thấy hoang mang quá.
Các bác cho hỏi trong thực tế thì mức độ chính xác khi liên kết bảng trên db so với quan hệ trên code backend api như thế nào nhỉ.

Một trường hợp cụ thể (có-vẻ-liên-quan) là use case xoá xxx: ví dụ trong trang bán hàng, người mua chọn và đặt hàng, xem hoá đơn,... thành công; rồi vào trang quản trị xoá sp vừa đặt đi.
Xong check lại hoá đơn kiểu gì cũng undefined nếu theo liên kết customer-(one-to-many)-order-(one-to-many)-orderproduct-(many-to-one)-product như bình thường

Tuỳ mục đích thiết kế, cá nhân mình vẫn thích nhiều FK vì giảm công sức validate và test

Tôi chưa làm các dự án e-commerce lớn nào nên ko rõ lắm. Nhưng tôi nghĩ chính xác thì order (đã thanh toán) sẽ link tới snapshot của product (e.g: hôm qua mua hộp durex 100k, hôm nay giảm còn 69k, ko thể để order cũ link tới 69k đc). Đồng thời thao tác "xóa product" sẽ nên là soft-delete để tránh các bug null pointer.
Còn vấn đề tạo hay ko tạo foreign key thì tùy mức độ consistency của từng quan hệ. Cũng có thể là team muốn đẩy công việc validate lên tầng application

DB này là dự án gì đây thím, đi học 3 năm chưa bao giờ thấy cái DB nào to như thế này

Theo mình thì Option 1:
product là masterdata, lúc xóa thì đổi status khác không cho hiển thị ở bên list product.
Còn data cũ (đơn hàng, hóa đơn,..) vẫn được kế thừa thông tin cơ bản của Product qua PK là ProductId
Option 2: Ở hóa đơn lưu thông tin product lúc đặt luôn, sẽ tránh cái undefined và phản ánh đúng product tại thời điểm đó.

P/s: ko xem được ảnh DB. Ngày nay ae thường đẩy validation lên lớp application nhưng nhiều cái cơ bản vẫn phải xử lý ở BE/DB mới chặt chẽ được

bỏ FK ở đây chủ yếu để tăng performance nhé.

HoangVu99 said:

DB này là dự án gì đây thím, đi học 3 năm chưa bao giờ thấy cái DB nào to như thế này

Click to expand...

Em học qua môn SQL rồi mà còn ko hiểu chủ thớt nói gì

HoangVu99 said:

DB này là dự án gì đây thím, đi học 3 năm chưa bao giờ thấy cái DB nào to như thế này

Click to expand...

Mình tìm với keyword "web bán hàng" thì thấy project này, tải về thây dùng Express mà không run được, db này tạo dựa trên code migration và phần model.
Có apidoc, đọc qua thấy vẫn có thể khai thác được

Nếu fen có FK giữa các bảng thì khi xoá sản phẩm sẽ báo lỗi không xoá được mà

tầng application mà các thím nói là phần nào nhỉ? controller hay service hay Dto hay repo

khongcotienver.3 said:

Nếu fen có FK giữa các bảng thì khi xoá sản phẩm sẽ báo lỗi không xoá được mà

Click to expand...

xóa sp làm gì fen ? soft-delete thôi chứ ai lại đi hard-delete làm gì mà bị lỗi FK. Mà thật ra sql cho phép xóa ko cần ràng buộc vẫn dc mà nên cái in đâm ko phải tại FK.

ừ mình đang nói case của thớt xoá sản phẩm, tạo quan hệ để ràng buộc dữ liệu các bảng với nhau thôi. Nhiều dự án vẫn hard delete đó fen.

chắc là bác học nhiều lý thuyết quá nên ra thực tế sẽ hoang mang. Bác có thời gian thì tìm hiểu cấu trúc EAV Entity–attribute–value những cái cơ sở dử liệu nó xài EAV thì nó gấp ít nhất là 5 lần so với thiết kế bảng truyền thống và thường nó sẽ kg có liên kết gì cả. lý do là mỗi bảng trên hệ thống nó lưu lại ở một file riêng. đăc điểm eav là nó thêm hoặc xóa bỏ thuộc tính nào thì kg ảnh hưởng gì đến hệ thống và kg có ràng buộc. nên khi một file cơ sở bị hư hay xóa bỏ thì kg ảnh hưởng gì đến chương trình nếu kg gọi thuộc tính đó. Còn với kiểu quan hệ thì nó nối với nhau và chuơng trình sẽ load theo kieu object load hết nên một file bị hư thì nguyên đám đi luôn. Thường những cái thiết kế kg có liên kết nó sẽ dùng phần lập trình mềm tạo ra hoặc truy vấn riêng