Có một nhược điểm nào khi sử dụng Access làm cơ sở dữ liệu không?

Tôi đã kế thừa một ứng dụng lưu trữ dữ liệu trong nhiều bảng trong Microsoft Access; Access DB chỉ được sử dụng để lưu trữ, mọi xử lý dữ liệu đều được xử lý bởi ứng dụng (VB.net).

Đây có phải là thực hành tốt? Tôi cần xây dựng một ứng dụng tương tự từ đầu và không chắc chắn về thực tiễn 'bình thường'.

Tôi đã thử Googling câu hỏi ở nhiều định dạng khác nhau và kiểm tra qua nhiều kết quả (bao gồm nhiều kết quả trên diễn đàn này) nhưng tất cả các câu hỏi dường như liên quan đến nơi bạn đang lập trình trong Access thay vì chỉ sử dụng nó để lưu trữ dữ liệu.

Tôi đoán tôi có thể cụ thể hơn và nói rằng SQL Server Express hoặc tương tự sẽ là một lựa chọn tốt hơn và nếu vậy tại sao?

Nếu bạn đang đọc bài đăng này do có một câu hỏi tương tự thì hãy xem liên kết này được cung cấp bởi @DanielB bên dưới - /programming/694921/ms-access-mdb-concurrency

Cơ sở dữ liệu MSAccess thường không được sử dụng vì một vài lý do. Trước đây, chúng không ổn định và không chấp nhận nhiều kết nối cùng một lúc. Khi cơ sở dữ liệu MSAccess đang được sử dụng, một tệp khóa được tạo (ldb). Khi tệp khóa đó có mặt, không ai khác có thể truy cập cơ sở dữ liệu. Tôi thấy rằng khi có một ứng dụng sử dụng một lần, hiệu suất của MSAccess sẽ giảm nghiêm trọng sau khoảng 50 nghìn hàng. Điều này có lẽ tốt hơn bây giờ, nhưng nó chắc chắn không được điều chỉnh cho sử dụng lớn hơn.

Điều điển hình hơn là sử dụng một hệ thống cơ sở dữ liệu mạnh mẽ hơn như postgres, mysql hoặc MSSQL. Đối với cơ sở dữ liệu kết nối đơn, tôi đã sử dụng Derby (với Java).

Theo như VB, bạn sẽ không tìm thấy các giải pháp chuyên nghiệp sử dụng VB làm phần mềm máy khách cho cơ sở dữ liệu. Vâng, có lẽ có một số giải pháp đang được bán, nhưng cá nhân tôi, tôi sẽ tránh chúng.

Thông thường, quá trình xử lý của bạn sẽ được thực hiện bằng một ngôn ngữ như C #, C ++, Java, Perl, Python hoặc các ngôn ngữ phổ biến khác. Thư viện sẽ được sử dụng để kết nối với cơ sở dữ liệu tách biệt với ngôn ngữ. Một số giải pháp sẽ sử dụng SQL để truy vấn và nhận dữ liệu và các giải pháp khác sẽ sử dụng thư viện Persistence để tạo các đối tượng từ dữ liệu (điều này đang trở nên phổ biến hơn).

Theo như thông lệ tốt nhất, tôi luôn thấy tốt nhất là phải nhất quán. Nếu bạn có một cửa hàng gồm bốn người hiểu MSAccess và VisualBasic, thì sẽ rất có ý nghĩa khi tiếp tục làm theo cách này. Nếu có một mục tiêu trong công ty để tránh xa nó do những thất bại trong quá khứ, bạn có thể tiếp tục sử dụng VB và chuyển sang cơ sở dữ liệu khác. Xem xét các Bảng liên kết trong MSAccess - Tôi đã sử dụng ứng dụng VB trên cơ sở dữ liệu MSSQL bằng cách liên kết các bảng MSSQL vào cơ sở dữ liệu MSAccess. VB không biết sự khác biệt giữa bảng MSAccess nguyên bản và bảng được liên kết nằm trên một máy chủ khác. Giải pháp VB vẫn không ổn định, nhưng hoạt động tốt hơn nhiều với các bộ dữ liệu lớn hơn.

Hi vọng điêu nay co ich!

Tôi đã có một số kinh nghiệm về vấn đề này trong quá khứ trong một tập đoàn lớn.

Khi cơ sở người dùng tăng lên, các vấn đề về bảo mật và hiệu suất đã xuất hiện do các tệp Access nơi lưu trữ dữ liệu phải được lưu trữ trong thư mục chia sẻ mạng và tất cả người dùng phải có quyền truy cập W / R.

Đây không phải là lý thuyết, đây là trải nghiệm trong thế giới thực, cơ sở dữ liệu Access không mở rộng tốt cho hàng chục người dùng đồng thời, chứ chưa nói đến một vài trăm trải rộng về mặt địa lý.

Với các hệ thống cơ sở dữ liệu tốt và miễn phí như PostgreSQL có sẵn, có rất ít lý do để sử dụng Access ngoại trừ những điều sau đây: thiếu kỹ thuật về cách thức.

Cá nhân nếu bạn có thể tránh xa quyền truy cập, tôi đã có những khách hàng thực sự đau khổ vì đơn giản là họ không thể hoặc không "cắn viên đạn".

Như Kieveli đã đề cập đến cơ sở dữ liệu Access là khủng khiếp khi lưu trữ một lượng lớn dữ liệu, hãy nhớ rằng các ứng dụng phải luôn được thiết kế với lợi ích cho người dùng cuối. Hãy tưởng tượng bạn có một văn phòng đầy những người có hệ thống chậm khủng khiếp làm lãng phí hàng giờ thời gian của họ mỗi tuần?

Phát biểu từ kinh nghiệm cá nhân khi chuyển cơ sở dữ liệu truy cập sang SQL Server thực sự không gây khó khăn cho bạn khi lập kế hoạch đúng đắn, câu hỏi đặt ra là bạn có các kỹ năng kỹ thuật trong nhà để chuyển sang một thứ như vb.net, v.v.

Cơ sở dữ liệu truy cập không có quy mô tốt nhưng chúng dễ xử lý và phân phối. Nếu bạn đang sử dụng Trình ánh xạ quan hệ đối tượng (O / R-mapper) hỗ trợ các loại cơ sở dữ liệu khác nhau làm giao diện cho cơ sở dữ liệu của bạn, ứng dụng của bạn sẽ ít phụ thuộc hơn vào loại cơ sở dữ liệu cụ thể. Điều này cho phép bạn bắt đầu với Access và chuyển sang cơ sở dữ liệu khác sau đó.

Tôi đã làm điều này một lần và bắt đầu một dự án với Access và C # front-end, bởi vì cơ sở dữ liệu có thể được thiết lập và phát triển rất dễ dàng với Access. Sau đó tôi chuyển sang cơ sở dữ liệu Oracle vì khách hàng của tôi có cơ sở dữ liệu Oracle. Chỉ có một vài thay đổi khi cần thiết trong ứng dụng của tôi.

Jet-SQL được ghi lại một cách khủng khiếp. Đó là một lý do để tôi tránh xa Access.

/programming/11265817/where-can-i-find-a-complete-reference-for-microsoft-access-sql

Mặt khác, T-SQL (SQL Server) linh hoạt hơn nhiều và bạn có thể tìm thấy vô số tài liệu, blog và chuyên gia có thể giúp bạn.

Tất nhiên Access là cơ sở dữ liệu trên máy tính để bàn trong khi SQL Server là cơ sở dữ liệu Client-Server đầy đủ.

Có một số cơ sở dữ liệu máy tính để bàn khác (tôi cũng đang sử dụng Máy chủ cơ sở dữ liệu lợi thế, nhưng đó cũng là một sản phẩm thích hợp).