1 vài thắc mắc về database trong ứng dụng winform

Vừa rồi mình có làm 1 đồ án và sử dụng linq. Mình thấy linq nó rất đơn giản và dễ hiểu mà :))
cái thứ 4 không biết bạn thực hiện ntn nhưng mình biết là trong sql có kiểu là Image để lưu hình ảnh, bạn sử dụng nó thử xem sao. Với lại mình không hiểu ý câu hỏi cuối của bạn cho lắm (chắc do còn gà) ^^

Với lúc mình đưa phần mềm cho khách hàng, mình muốn tạo ra 1 frmConnect để kết nối csdl rồi tạo dữ liệu mẫu ban đầu hoặc import từ csdl có sẵn, cái đó mình tìm tutorial trên mạng mà không ra. Bạn có thể gợi ý cho mình keyword được không?

Với tạo dữ liệu mẫu ban đầu, thường là mình sẽ tạo 1 database mặc định khi install software cho khách hàng. Bạn tham khảo 2 link sau để tạo Database mặc định. Ngoài ra trong file script đó, bạn có thể import sẵn database mẫu cho khách hàng luôn

https://msdn.microsoft.com/en-us/library/49b92ztk(v=vs.100).aspx

Create SQL Server database during application installation

1/ Theo như những project mình đã từng được biết thì họ xài db first. Lý do là việc tạo và thay đổi db sẽ đỡ tốn công sức hơn so với chuyện code model. Sau khi tạo/thay đổi db xong, việc còn lại làgenerate ra model là xong, lúc tính cost của project thì lợi hơn ( nhất là càng về sau càng có nhiều thay đổi hay chỉnh sửa ).

Khi dùng code first thì bạn được lợi điểm là logic của bạn không care tới loại db nào (database independence). Mysql, sqlserver, oracle không care, cứ code xong model rồi generate ra là xong. Sau này có thay đổi loại db thì cũng khỏe, chỉ việc generate lại.

Việc này thì tùy bạn cân nhắc thôi. Với project lớn thì nên code first, còn nếu nhỏ nhỏ và không có ý định làm lâu dài với nó thì db first. Ngoài ra nó còn liên quan đến style của bạn nữa, sở thích rất quan trọng, thích cái gì làm cái đấy.

2/ Việc sử dụng stored procedures hay object relation mapping thì lại là một câu chuyện dài dây dẳng. Nhiều ý kiến trên mạng tranh cãi lắm. Nhưng chung quy lại thì có thể chia ra như sau.

Stored Procedure:

• Điểm mạnh:
  – Performance cao, cái này khỏi bàn, lưu dưới cache của db mà.
  – Tách biệt db ra khỏi ứng dụng. Nếu có bất cứ thay đổi nào về stored procedure hoặc kiến trúc của db, thì tầng ứng dụng không cần care.
• Điểm yếu:
  – Logic ứng dụng bị quăng xuống tầng database. Mà vốn dĩ tầng db không phải là nới nên chứa logic của ứng dụng. Ngoài ra logic bị đặt ở 2, 3 nới khác nhau, được viết bằng các ngôn ngữ khác nhau làm cho ứng dụng trở nên khó bảo trì sau này.
  – Sau này có chuyển db sang mysql hay oracle thì có mà viết lại đống logic đó từ đầu.

Object Relation mapping (ORM):

• Điểm mạnh:
  – Mapping toàn bộ db dưới dạng model trên tầng code. Việc này làm logic ứng dụng nhất quán hơn. Dễ đọc, dễ bảo trì.
  – Không bị phụ thuộc vào bất cứ loại db nào. Sau này có muốn thay mysql thằng sql server cũng chả thành vấn đề. Đó là việc của engine mapping object giữa code và db tương ứng.
• Điểm yếu:
  – Do bị phụ thuộc vào chuyện mapping nên nếu db có thay đổi thì tầng ứng dụng sau khi generate lại thì phải test lại luôn tầng ứng dụng. Cái này tạo ra nghịch lý giống như việc “Thằng A nó thay đổi, nên chúng ta phải kiểm tra thằng B”
  – Chậm hơn stored procedure. Cái này thì chắc rồi vì phải mapping qua database language rồi execute.

Nói chung nhiều ý kiến. Nhưng chung quy lại là nếu cần tốc độ thì nên xài stored procedure. Còn bình thường thì nên xài ORM. Các ứng dụng càng lớn và logic càng phức tạp thì người ta hướng tới việc dụng ORM. Bạn cứ tưởng tượng mở 1 cái stored procedure viết dài gần 1000 dòng thì bạn sẽ không muốn rớ tới đâu. Với lại có một nhận định vui như vầy:
“Giá của CPU với RAM ngày càng rẻ, nhưng giá duy trì và phát triển ngày càng mắc. Nên thôi, code cho nó chậm tí mà ổn định sau này thì tốt hơn” Cái này một anh làm chung nói chuyện chơi với nhau cho vui.

3/ Việc tổ chức data thì nếu bài bản, bạn nên tách ra thành 3 bảng

• Transaction: Chứa thông tin chung của 1 lưọt khách ra vào. Sẽ chứa: mã thẻ, transaction id, loại xe, , trai gái, đẹp xấu bla bla.
• Incoming: chứa thông tin của lượt vào. Thưòng chứa: hình bảng số xe vào, hình chủ xe vào, thời gian vào, TransactionId, số người vào, bla bla bla
• Outgoing: Chứa thông tin lượt ra. . Thưòng chứa: bảng số xe ra, hình chủ xe ra, TransactionId, số người ra, bla bla
  Còn nếu đã làm biếng thì gom chung 1 bảng cũng không sao Làm outsource không ai để ý nhiều mấy cái này đâu. Chỉ là hổ thẹn với lương tâm nghề nghiệp thôi.

4/ Không chắc mình hiểu đúng ý bạn không, ý bạn là khi cần, bạn có thể load data mẫu vào db trống để test hoặc tutorial cho khách đúng không. Nếu đúng bạn có thể search về việc “C# restore database”, việc này cho phép bạn backup ra file backup trước, lúc cần bạn dùng ứng dụng của bạn restore nó ra thôi:

How to restore a database from C#

Cảm ơn comment hữu ích của bạn.
Trước giờ thì mình hay dùng store procedure(mình nghĩ app lớn thì nên dùng thằng này), nhưng sau khi bạn nói thì mình sẽ cân nhắc việc dùng ORM.
Cảm ơn bạn rất nhiều.

Ở vấn đề 3, thường là tách ra thành 2 bảng như bạn nói, nếu còn phân vân thì làm kiểu như thời đi học, môn phân tích hệ thống
Ở cái thứ 4 thì bạn nên lưu image của biến số xe đã chụp để làm đối chứng sau này, Nếu đúng quy trình mình hiểu thì khi xe vào bãi, camera xe chụp lại biển số xe và nchar các kí tự của biển số xe. Tới khi lấy xe thì cũng như vậy, camera xe chụp lại biển số xe và nchar các kí tự của biển số xe và so sánh với các kí tự của xe vào xem có khớp không!
Vấn đề cuối mình thường làm là lấy csdl mình đã đính kèm trong gói cài đặt luôn, rồi dùng form connect vô thôi.
http://www.codeproject.com/Articles/28434/Address-Book-and-Events-Reminder
Nhưng mình bạn định dùng ORM thì hơi khó với những gì mình vừa nói.
Không biết mình có hiểu sai ý bạn không thì thông cảm nha. hj

Cân nhắc khi sử dụng ORM, nếu không chuyên nghiệp xử lý thì có thể vướng vào lỗi, khá đâu đầu đáy

Thứ 4 là kiểu dữ liệu mình nên để là nchar(để lưu đường dẫn hình ảnh so sánh với camera khi chụp hình) hay mình lưu nó dạng text(khi chụp hình camera tự chuyển chuỗi hình ảnh thành text).
Mình chưa làm dự án thực tế bao giờ nên không hình dung ra camera lưu ra text hay giữ là image.

Lưu đường dẫn bạn à!

À, với lại vụ image lưu trong db, mình ít thấy ứng dụng làm chuyện đó lắm trừ khi hình ít và nhỏ. Tại vì bạn lưu cả tấm hình trong db, db cực kỳ nặng, rất phiền việc backup và restore. Khi cần query data để report hoặc show thông tin, bạn phải tốn chi phí để vận chuyển image trên đường truyền nữa.
Khi ứng dụng lớn cần sử dụng các biện pháp fail over hoặc clustering, việc lưu hình trong db làm dung lượng db tăng theo cấp số nhân.

Mình thấy bạn có thể follow theo ý kiến một vài bạn phía trên, lưu name của tấm hình trong db. Còn tấm hình thật nằm ở shared server. Khi cần thì load từ server đó. Mình nghĩ là do ứng dụng xe của bạn sẽ chạy trên khá nhiều máy nên bạn tính bỏ vào db luôn cho tiện nhưng thử cân nhắc cách này xem.

Cơ sở dữ liệu mình còn nhiều chỗ vướng mắc.
Không biết mình thiết kế như thế này có ổn không.
Các bạn xem hình hộ mình cần sửa chỗ nào cho trực quan.

Imgur

Lúc đầu mình định làm 2 bảng mà thằng bạn nó nói thấy cũng có lý:
Lúc xe ra thì cập nhật thời gian lúc ra rồi update cái tinhtrang=đã ra hoặc đã vào bãi.
Lúc vô người ta quẹt thẻ thì insert vô bảng, lúc ra thì người ta quẹt thẻ truy xuất id thẻ để lọc cái thông tin hình ảnh lúc vào rồi bảo vệ so sánh.
Xong rồi update ThoiGianRa, TinhTrang.
Mấy bạn thấy có ổn hơn cách phân ra 2 bảng không?

Với cái bảng Nhân Viên mình để 1 cột thời gian hoạt động của nhân viên nào để tiện ghi ra file log nếu mà có sai sót có bằng chứng đối chiếu.

Hình ảnh thì chắc mình sắm cái ổ lớn lớn khoảng 1Tb rồi mấy tháng xuống bảo trì lại.
Dữ liệu load lên datagridview thì mình phân trang table mỗi lần load 50 record thôi nên chắc hiệu suất cũng ổn định.

Bạn có thể nói rõ hơn những vấn đề hay lỗi khi dùng ORM không?
Trước giờ winform thì mình hay dùng 3 lớp theo hướng code first rồi viết store gọi vào thôi.
Bên ASP thì dùng ORM mình thấy cũng tiện, nhưng làm project nhỏ tương tác csdl bé nên cũng chưa gặp lỗi gì.
Cảm ơn bạn nhiều nha.

Như mình có nói ở trên thì bạn có thể chỉ cần dùng 1 table để lưu tất cả thông tin của 1 lượt ra vô. Chỉ là về mặt ngữ nghĩa nhìn nó không rõ ràng thôi ( dạng như kiểu bạn viết code nên bạn hiểu quy luật insert/update của table này ). Còn về logic thì ổn cả thôi, nhiều khi gom hết 1 bản lại tiện nếu ứng dụng không quá phức tạm. Mình nghĩ cái này tùy bạn thôi. Muốn rõ ràng tường minh thì tách. Muốn cho gọn thì gom.

Với lại cái này mình tò mò tí thôi. Table ThanhToan sao bạn không gom vào table ra vào luôn ? Theo mình hiểu thì một lần xe ra vào thì cũng là 1 lần thanh toán luôn. Nếu bạn tính gom lại cho gọn luôn thì bạn cân nhắc việc gom luôn bảng đó vào bảng XeRaVao. Còn nếu mình hiểu không đúng thì có thể cho qua.

Cái này nhắc chừng thôi, có thể bạn đã fix rồi. Hình như bạn thiếu primary key cho table nhanvien và thanhtoan. Ngoài ra chưa có mối liên kết giữa NhanVien và XeRaVao, ThanhToan và XeRaVao.

Cảm ơn bạn @chp nhiều nha.
Cái database mình chỉ làm mô phỏng ra để hỏi thôi chứ csdl của mình sẽ thay đổi nhiều khi code.

Table ThanhToan mình định như thế này.
Có 1 bảng VeThang để khách hàng có thể gửi vé tháng, bảng đó mình sẽ chứa thông tin khách hàng, biển số của họ riêng, đại loại như những người đó khi vào thì chỉ cần tự quẹt thẻ là vào thôi.
Bảng ThanhToan đó dùng cho vé tháng, nhưng mình phải thêm vài trường như Ngày Hết Hạn để có thể gia hạn thêm.
Còn cái thanh toán cho khách ra vô thường xuyên thì để bên bản XeRaVao chắc cũng hợp lý, vì lúc đầu mình định dùng bảng thanh toán đó cho cả 2 bảng XeRaVao, VeThang mà không biết được không.
Còn mấy cái khóa ngoại thì bình thường mình hay kéo từ table này hay table khác, nó rất bất tiện kiểu như:
Mình có 2 bảng Sản Phẩm, Nhà Cung Cấp. Mà lỡ như khách hàng nhập dữ liệu bên thằng Sản Phẩm (không được quyền này, vì Nhà Cung Cấp phải được nhập trước rồi mới được update bên Sản Phẩm). rất khó chịu cho khách hàng.
Đi làm 2 chỗ thì 2 anh leader bảo là khi em làm dự án thực tế (mình vẫn còn thử việc nên chưa được làm dự án) thì phần đó em đẩy logic qua code và ràng buộc ở đó, mà cũng không cần khóa ngoại gì, mình cũng không hiểu lắm, nếu ràng buộc ở code thì ràng buộc như thế nào?

Mình hỏi ràng buộc là giống như trong Model của thằng ASP mình [Required], [Validate] các attribute từng đối tượng trong bảng… của namespace DataAnnotations phải không thì mấy anh nói không phải.

Mình hỏi hơi nhiều tại có nhiều điều thắc mắc khi đi làm. Mong các bạn bỏ qua. Chân thành cảm ơn các bạn.