Không phải là SQLite một chút đánh giá thấp? [đóng cửa]


15

Trước khi tôi đặt câu hỏi, trước tiên hãy để tôi mô tả suy nghĩ của tôi về SQLite.

Tôi thích các công cụ nhỏ, nhanh và quan trọng hơn là chỉ có các chức năng thực sự cần thiết. Đó là lý do tại sao tôi thích SQLite và tôi thích MS-SQL ít hơn một chút.

Ví dụ: MS-SQL có thể có nhiều chức năng, khả năng mở rộng hơn, v.v., nhưng cũng có thể gây khó khăn khi cài đặt nếu bạn không may mắn. Tất nhiên, tôi không nói rằng việc cài đặt khó khăn là lý do để không chọn một cơ sở dữ liệu cụ thể.

Đừng hiểu tôi sai: MS-SQL là một sản phẩm chất lượng tốt. Tôi rất có kinh nghiệm với MS-SQL; Tôi hiểu sản phẩm rất tốt như một chuyên gia. Tôi chỉ thích nó ít hơn trong một số trường hợp không thực sự cần thiết (= không có nhiều người dùng, <10-15).

Bạn thực sự sử dụng bao nhiêu chức năng của cơ sở dữ liệu? Theo kinh nghiệm của tôi, nó thường chỉ là SQL bình thường (CHỌN, CHERTN và CẬP NHẬT).

Tôi thích SQLite. Hấp dẫn nhanh. Thật dễ dàng để "cài đặt". Tôi nghĩ rằng SQLite có thể làm nhiều hơn những gì nó tuyên bố nó có thể làm. Tại sao chỉ sử dụng nó cho các ứng dụng một quá trình / một người dùng? Rốt cuộc: không có nhiều ứng dụng liên tục truy cập cơ sở dữ liệu.

Ví dụ: xem xét một ứng dụng ERP với, giả sử, 15 người dùng. Tại sao SQLite không thể được sử dụng cho điều đó? Hãy đối mặt với nó: theo kinh nghiệm chuyên môn của tôi, hầu hết người dùng loại ứng dụng này sẽ truy cập cơ sở dữ liệu trong khoảng 5-10% tổng thời gian họ đang sử dụng ứng dụng. Trong 90-95% khác, họ chỉ xem thông tin trên màn hình, nhập dữ liệu theo dạng lưới / biểu mẫu và khi họ lưu dữ liệu đầu vào của họ không quá 1 giây thời gian cơ sở dữ liệu. Fe: 1,5 phút thời gian đầu vào so với 1 giây thời gian tiết kiệm.

Nếu tệp cơ sở dữ liệu SQLite bị khóa trong thời gian "tiết kiệm thời gian", những người dùng khác cần truy cập cơ sở dữ liệu chỉ chờ, nhưng họ không nhận thấy rằng vì thời gian chờ sẽ rất nhỏ (không thể nhận thấy). Trong mã, bạn chỉ cần xử lý thời gian "bận rộn" có thể của cơ sở dữ liệu, để tránh các ngoại lệ, nhưng điều đó không khó thực hiện.

Một số người, những người phải suy nghĩ giống như tôi, thậm chí đã xây dựng một giải pháp máy khách-máy chủ cho SQLite: SQLitening . Điều này khiến tôi tin chắc rằng tôi có thể không tự lừa dối mình.

Tất nhiên, có những ứng dụng chuyên sâu về cơ sở dữ liệu mà SQLite không phù hợp. Nhưng như bây giờ tôi nghĩ về nó, nhiều ứng dụng nhiều người dùng, nếu họ không vượt quá 15 người dùng hoặc hơn, thì sẽ làm tốt với SQLite.

Nhiều khách hàng của chúng tôi không chi tiêu nhiều cho phần cứng, vì vậy tôi thường gặp một máy chủ duy nhất có mọi thứ trên đó (Exchange, SQL (s), máy khách, v.v.) và vì điều đó gần như "hết hơi". Nếu tôi có thể cung cấp một sản phẩm không có yêu cầu hệ thống cao, thì khách hàng của tôi sẽ rất vui. SQLite không thêm bất kỳ trọng lượng nào (ít nhất là không nhiều), MS-SQL cũng vậy. Vì vậy, tôi sẽ không chọn SQLite vì nó miễn phí, rẻ hoặc dễ cài đặt. Tôi sẽ chọn nó vì lý do thực tế / kỹ thuật.

FYI: Trong nghề nghiệp của chúng tôi, chúng tôi bán sản phẩm (tùy chỉnh và tiêu chuẩn, chủ yếu liên quan đến ERP) cho khách hàng, trung bình, không quá 5-6 người sẽ sử dụng sản phẩm. Có một số trường hợp ngoại lệ, nhưng không quá 10-15 người dùng.

Câu hỏi là: Tôi có đúng khi nghĩ rằng tôi có thể sử dụng SQLite cho một số ứng dụng nhiều người dùng như ví dụ tôi mô tả không? Có bất kỳ nhược điểm kỹ thuật nào mà tôi nên biết không? Những kinh nghiệm của bạn (tiêu cực hay tích cực) sẽ giúp tôi lựa chọn đúng đắn là gì?

Cập nhật: Xin đừng xem đây là một đánh giá tiêu cực của các cơ sở dữ liệu khác. Họ chủ yếu là tất cả các sản phẩm tốt. Chỉ cần chia sẻ suy nghĩ của tôi ở đây và quan tâm đến ý kiến ​​của bạn về điều này.


9
Xin lỗi, nhưng thêm "Tôi có đúng không?" không biến một câu nói thành một câu hỏi.
pdr

1
@pdr: Tại sao bạn coi đây là một lời ca ngợi? Tôi không đánh giá tiêu cực MS-SQL hoặc các cơ sở dữ liệu khác; họ chủ yếu là tất cả các sản phẩm tốt. Tôi chỉ chia sẻ suy nghĩ của mình và muốn nghe ý kiến ​​của các lập trình viên khác. Không hơn không kém.

3
Không có câu hỏi ở đó, chỉ có một tìm kiếm để xác nhận. Từ Câu hỏi thường gặp: "Bạn chỉ nên đặt câu hỏi thực tế, có thể trả lời dựa trên các vấn đề thực tế mà bạn gặp phải. Câu hỏi mở, câu chuyện mở làm giảm tính hữu ích của trang web của chúng tôi và đẩy các câu hỏi khác ra khỏi trang nhất." lập trình
viên.stackexchange.com / faq

1
@pdr: Tôi hiểu điều đó, nhưng tôi thành thật muốn hỏi một câu hỏi ở đây. Có lẽ tôi đã không rõ ràng, vì vậy tôi đã đọc lại câu hỏi.

4
Lựa chọn cơ sở dữ liệu, tối ưu hóa mã, ứng dụng khách, máy chủ hoặc ứng dụng dựa trên web, đây là tất cả các lĩnh vực cần xem xét và những ưu và nhược điểm cần được thảo luận trên một nền tảng như thế này. Đối với tôi, một cơn thịnh nộ là nhiều hơn khi ai đó từ chối tìm kiếm bất kỳ chất lượng chuộc lỗi nào trong một công nghệ cụ thể.
JeffO

Câu trả lời:


8

Có rất nhiều trường hợp trong đó SQLite là rất nhiều. Người dùng, bộ phận hoặc công ty hiếm khi phát triển nhanh hơn (Chúng tôi không nghe về nó nhiều vì không ai gọi cho lập trình viên nếu ứng dụng hoạt động tốt.) Bạn có thể đưa ra lập luận tương tự cho tệp MS Access (Windows) hoặc SQL Server Compact Edition (yêu cầu cài đặt một số). Tất cả đều đủ tốt cho một ứng dụng cục bộ vì bạn không phải lo lắng về tính bảo mật của tệp.

Trong một scenerio nhiều người dùng trên một mạng cục bộ, tệp sẽ chuyển đến một thư mục dùng chung sẽ cần truy cập bởi tất cả người dùng - bảo mật cuộc gọi. Bảo trì đơn giản hoặc bất kỳ thay đổi cấu trúc bảng nào như sao lưu hoặc thêm một cột sẽ ngăn người dùng khác truy cập. Đêm qua, bản sao lưu không hoạt động vì ai đó quên thoát khỏi ứng dụng. Điều gì xảy ra khi bạn muốn thực hiện sao lưu vào giữa ngày? Mọi người hợp lý hóa rằng họ không cần bất kỳ bản sao lưu nào trong ngày vì những hạn chế kỹ thuật của cơ sở dữ liệu của họ. Tại một số điểm, việc cài đặt SQL Server Express / tương đương khác trên máy chủ của bạn sẽ có một số thiết lập ban đầu và cấu hình bảo mật, được tham gia nhiều hơn trước, nhưng sẽ cần ít bảo trì.

Luôn có mối quan tâm về khả năng mở rộng / kỹ thuật quá mức. Ngay cả khi số lượng người dùng hoặc lượng dữ liệu vẫn có thể quản lý được, một người nào đó luôn có ý tưởng sử dụng dữ liệu trực tiếp trên một số mạng nội bộ hoặc giao diện trang web / trình duyệt khác. Cơ sở dữ liệu tập tin trình bày vấn đề. Chỉ cần một người muốn truy cập tệp dữ liệu qua VPN (ứng dụng được cài đặt trên máy tính xách tay của họ) để cung cấp cho bạn một vấn đề 'mở rộng'. Bạn có thể xây dựng ứng dụng để cho phép người dùng bị ngắt kết nối có thể đồng bộ hóa khi họ quay lại. Có vẻ như không có giá trị đối với người dùng văn phòng không thường xuyên.


Bạn có thể đưa ra lập luận tương tự cho SQL Server Compact Edition, nhưng không phải cho cơ sở dữ liệu MS Access. Cơ sở dữ liệu truy cập được coi như chúng là một cơ sở dữ liệu thực, nhưng hoạt động giống như các tệp được chia sẻ. Chúng là một giải pháp dễ vỡ; SQL Server Compact thực sự là một sự thay thế tốt hơn, nhanh hơn, đáng tin cậy hơn mà vẫn hoạt động với các giao diện Access. Tôi nghi ngờ rằng SQLite bền hơn đáng kể so với cơ sở dữ liệu Access, mặc dù về mặt kỹ thuật nó là một giải pháp tệp được chia sẻ.
Robert Harvey

@RobertHarvey - Chúng tôi có nhu cầu kinh doanh trong đó MS Access là giải pháp đủ tốt (tức là tốt hơn Excel) trong 10 năm. Khi một thỏa thuận lớn được thực hiện, chúng ta phải có một cái gì đó và chạy. Người dùng quyền lực với các kỹ năng Access dễ dàng tìm kiếm và tận dụng hơn nhiều. Chức năng phải có ở một ngày nhất định, nhưng chúng tôi may mắn rằng khả năng mở rộng, hiệu suất, tăng trưởng dữ liệu và bảo mật chưa bao giờ là một yếu tố. Nâng cấp quyền truy cập, bây giờ đó là một câu chuyện khác.
JeffO

Đừng hiểu lầm tôi; Tôi nghĩ rằng Access là tuyệt vời. Nhưng SQL Server Compact sẽ là yêu cầu phụ trợ tối thiểu của tôi cho bất kỳ ứng dụng Access mới nào mà người dùng chia sẻ dữ liệu.
Robert Harvey

@RobertHarvey - Tôi sẽ phải xem xét điều đó. Cảm ơn
JeffO

12

Tôi nghĩ thật tuyệt khi sử dụng khi bạn cần cơ sở dữ liệu "nội bộ". Đó là, một cơ sở dữ liệu mà ứng dụng / mã của bạn sẽ tương tác nhưng điều đó sẽ không liên quan trực tiếp đến lý do chính khiến ứng dụng của bạn tồn tại. Thay vì sử dụng ánh xạ trong bộ nhớ lớn hoặc trình quản lý bộ đệm, bạn cũng có thể sử dụng cơ sở dữ liệu như vậy. Tôi có một ví dụ rất cụ thể về điều này, vì gần đây tôi đã sử dụng nó trong các trường hợp thử nghiệm JUnit / DBunit khi tôi cần kết nối với cơ sở dữ liệu, thực hiện một số công việc, đọc dữ liệu và xóa mọi thứ ở cuối. Vì bạn chỉ cần tạo một tệp trống để tạo cơ sở dữ liệu , điều đó khá dễ thực hiện.

Một cách sử dụng khác tôi thấy: khi bạn chỉ có một người dùng. Vâng, điều đó là có thể, hãy nghĩ "Firefox" hoặc "Opera" chẳng hạn :-)

Ngoài ra, trên trang web SQLite, họ rất trung thực về điều đó và đưa ra lý do khi KHÔNG SỬ DỤNG CNTT (xem đoạn "Tình huống trong đó một RDBMS khác có thể hoạt động tốt hơn")

ps: liên quan đến các bình luận trên Sql Server Express, vâng, nó cần phải được "cài đặt". Và tôi đã gặp một số khó khăn khi cập nhật nó một cách cá nhân (tôi phải xóa thủ công một số khóa đăng ký liên quan đến phiên bản trước để có thể cài đặt 2008 R2). Tuy nhiên, nếu bạn muốn so sánh SQLite với cơ sở dữ liệu do Microsoft phát triển, hãy xem Sql Server Compact Edition , bạn không cần phải cài đặt (xem "triển khai dựa trên tệp riêng tư").


Tôi đã xem xét CE, nhưng bằng cách nào đó có vẻ như SQLite tốt hơn / nhanh hơn / dễ dàng hơn. Không biết chắc chắn, tôi đã không sử dụng / kiểm tra CE đủ để chắc chắn.

5

Ví dụ: xem xét một ứng dụng ERP với, giả sử, 15 người dùng. Tại sao SQLite không thể được sử dụng cho điều đó?

Rất ít ứng dụng có ít người dùng mãi mãi. Và đối với bất cứ điều gì nhìn thấy nhiều người dùng hơn và thao tác dữ liệu phức tạp hơn, việc sử dụng SQLite hoàn toàn không còn là vấn đề vì lý do hiệu suất do mô hình khóa "giao dịch một lần ghi" đơn giản.

Giả sử bạn có 100 người dùng, mỗi người làm việc trong 60 giây điền vào một biểu mẫu và sau đó gửi nó. Vì vậy, bạn cần xử lý khoảng 1,6 giao dịch mỗi giây. Mô hình dữ liệu rất phức tạp và lưu một biểu mẫu liên quan đến việc đọc và ghi vào nhiều bảng lớn, thậm chí có thể giao tiếp với một hệ thống khác nhau, do đó, mỗi "biểu mẫu gửi" dẫn đến một giao dịch mất 2 giây. Nhưng SQLite không thể xử lý đồng thời các giao dịch, vì vậy điều này có nghĩa là nó chỉ có thể xử lý 0,5 giao dịch mỗi lần. Giáo sư.

"Có thể là một nỗi đau để cài đặt" không phải là một lý do tốt để quyết định chống lại một phần cơ sở hạ tầng quan trọng. Ngoài ra, có các công cụ DB khác để lựa chọn, ít nhất hai trong số đó (MySQL và Postgres) là miễn phí và không có giới hạn đồng thời của SQLite. Chúng thậm chí có thể dễ cài đặt hơn MS-SQL.


Tôi hiểu và đồng ý. Nhưng trong nghề nghiệp của tôi, tôi thực sự không có khách hàng sử dụng các sản phẩm của chúng tôi (tiêu chuẩn và tùy chỉnh, chủ yếu liên quan đến ERP) với hơn 10 người. Trung bình chỉ có 5-6 người dùng. Tôi sẽ viết lại câu hỏi của tôi.

4
@Marcus V: Câu hỏi đặt ra là: nếu một khách hàng đã phát triển rất nhiều và thấy rằng ứng dụng bạn xây dựng trở nên chậm sử dụng và bạn nói với họ lý do là DBMS không thể xử lý nhiều người dùng đó và họ hỏi " Tại sao bạn không sử dụng DBMS tốt hơn ", bạn nghĩ câu trả lời" khó cài đặt "như thế nào? Tôi có thể nói cho bạn biết phản ứng của tôi sẽ như thế nào: Tôi nghĩ rằng "đây là một kẻ nghiệp dư. Tôi cần tìm người khác để viết phần mềm của mình".
Michael Borgwardt

Bạn đúng. Tôi không nghĩ bạn có ý như vậy, nhưng tôi có thể đảm bảo với bạn rằng tôi không phải là một người nghiệp dư. Tôi chắc chắn sẽ sử dụng các hệ thống DBMS "thực" nếu tình huống sẽ yêu cầu. Sản phẩm của chúng tôi được cấp phép cho một số người dùng. Tôi sẽ chỉ phát triển bằng SQLite nếu tôi biết rằng số lượng người dùng tương đối ít (<10-15). Nếu khách hàng vượt quá giới hạn, điều mà trong cơ sở khách hàng của chúng tôi sẽ không xảy ra sớm, chúng tôi luôn có thể chuyển đổi tương đối nhanh chóng / đơn giản sang cơ sở dữ liệu khác. Đó không phải là khoa học tên lửa;). Dựa trên nhận xét của bạn, tôi đã đọc lại câu hỏi để làm cho nó rõ ràng hơn.

Người dùng khóc lóc về việc phát triển ứng dụng có thể đã được thông báo về những hạn chế của người dùng nhưng đã chọn đi theo con đường rẻ hơn. Mọi thứ đều ổn với thiết lập nội bộ, nhưng họ sẽ vui đến mức nào khi bạn phải tính phí cho họ một khoản phí khác để cài đặt trên máy chủ mới, khi họ có thể vừa sao chép một tệp?
JeffO

1
@Jeff O: Tôi đoán bạn đã hiểu nhầm ý định của tôi. Tôi không chọn SQLite vì nó miễn phí, rẻ và / hoặc dễ cài đặt. Tôi sẽ chọn nó chỉ vì nó nhỏ, nhanh và thân thiện với tài nguyên. Vì vậy, nó chủ yếu là vì lý do thực tế / kỹ thuật. Nhiều khách hàng của chúng tôi không chi tiêu nhiều cho phần cứng, vì vậy tôi thường gặp một máy chủ duy nhất có mọi thứ trên đó (Exchange, SQL, v.v.) và vì điều đó gần như "hết hơi". Nếu tôi có thể cung cấp một sản phẩm không có yêu cầu hệ thống cao, thì khách hàng của tôi sẽ rất vui. SQLite không thêm bất kỳ trọng lượng nào, MSSQL cũng vậy.

4

Tôi nghĩ rằng SQLLite là tuyệt vời để phát triển ứng dụng, điểm mạnh lớn nhất là nó không cần phải được cài đặt trên máy khách.

Tuy nhiên, đừng đánh giá thấp SQL Server Express, đó là một cơ sở dữ liệu tuyệt vời miễn phí với hầu hết các tính năng của máy chủ sql thông thường chỉ có giới hạn về kích thước cơ sở dữ liệu (khó vượt quá) cùng với khả năng sử dụng các công cụ tuyệt vời thông thường máy chủ sql.

Nhược điểm lớn nhất của nó là bạn cần phải cài đặt nó, tôi hơi không chắc chắn về phần đó, có thể là một cách xung quanh nó bây giờ


2
Bạn đúng. MS-SQL Express là một sản phẩm chất lượng tốt. Chỉ là tôi thấy nó hơi cồng kềnh và sử dụng quá nhiều tài nguyên. Ngày nay, PC / máy chủ không phải là vấn đề. Tôi chỉ là một học sinh cũ và vẫn nghĩ rằng phần cứng mạnh hơn không có nghĩa là tôi nên bỏ bê / lãng phí tài nguyên nếu tôi có thể tránh được. Ít hơn nó tốt hơn ...;).

2
cơ sở dữ liệu với các công cụ DB có thể tối ưu hóa việc truy cập bằng cách lưu vào bộ nhớ thay vì đọc / ghi từ đĩa. Nhưng tôi không chắc về hiệu suất của DB trong quá trình như SQL Lite
sarat

1
@sarat: Afaik SQLite sử dụng bộ nhớ đệm mạnh mẽ.

2

Tôi không coi SQLite là một cơ sở dữ liệu nghiêm túc nếu bạn đang xử lý một vài GB dữ liệu mỗi giờ. Nó bị chậm một cách đau đớn và làm giảm hiệu suất của toàn bộ Ứng dụng. Xin lỗi, nhưng tôi không đồng ý với niềm đam mê của bạn đối với SQLite :-)


1
Tôi tôn trọng ý kiến ​​của bạn. Tôi chỉ là một người đàn ông thực tế. Khi tôi chọn một công cụ tôi chọn nó vì tôi nghĩ đó là quyết định thực tế / thực tế nhất. Tôi không thích SQLite, nhưng rất ngưỡng mộ cách họ quản lý để đặt thật nhiều vào một gói nhỏ, hiệu quả và nhanh chóng như vậy. Giống như tôi đã đề cập trong câu hỏi của mình: nếu MS-SQL là một công cụ tốt hơn cho một công việc cụ thể, thì tôi chỉ cần chọn nó. Nhưng, như tôi đã giải thích, trong nhiều trường hợp, tôi thực sự tin rằng SQLite chỉ phù hợp.

Amout của dữ liệu sử dụng là một lớn nếu.
JeffO

@Jeff O: Phải. Tôi sẽ chỉ chọn SQLite nếu số lượng người dùng tương đối thấp (<10-15) và tổng lượng dữ liệu không cao. Theo kinh nghiệm của chúng tôi, tổng kích thước cơ sở dữ liệu thường là 300-400 MB và hầu như không bao giờ> 1GB.

1

Vấn đề với cơ sở dữ liệu là chúng có xu hướng tích lũy ngày càng nhiều dữ liệu. Chọn một DB nhẹ sẽ dẫn đến rủi ro là công cụ của bạn sẽ không mở rộng đúng cách.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.