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:
http://www.codeproject.com/Tips/873677/SQL-Server-Database-Backup-and-Restore-in-Csharp
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?
