Helpex - Trao đổi & giúp đỡ Đăng nhập

Thiết kế cơ sở dữ liệu cho các ứng dụng bất khả tri cơ sở dữ liệu

Lê Nguyên Khoa
· 08:28 15/10/2008
hôm qua

Tôi phải xem xét điều gì trong thiết kế cơ sở dữ liệu cho một ứng dụng mới có thể hỗ trợ các hệ thống cơ sở dữ liệu quan hệ phổ biến nhất (SQL Server, MySQL, Oracle, PostgreSQL ...)?

Nó thậm chí có giá trị nỗ lực? Cạm bẫy là gì?

17 hữu ích 0 bình luận 7.1k xem chia sẻ
Đặng Bảo Thái
· 09:45 15/10/2008
09:45:28 15/10/2008

Câu trả lời ngắn gọn là bám vào các tính năng được triển khai tiêu chuẩn hoặc gần với các tính năng được triển khai theo tiêu chuẩn. Chi tiết hơn điều này có nghĩa là:

  • Tránh bất kỳ thứ gì sử dụng ngôn ngữ thủ tục của cơ sở dữ liệu (thủ tục được lưu trữ hoặc trình kích hoạt) vì đây là nơi tạo ra sự khác biệt lớn giữa các hệ thống. Bạn có thể cần sử dụng chúng để mô phỏng một số tính năng, nhưng không sử dụng chúng để tạo chức năng của riêng bạn.

  • Tách các trình tự của các trường tăng tự động khỏi chính các trường đó. Điều này trông hơi gượng ép đối với MSSQL nhưng sẽ thực hiện sạch sẽ trong Oracle, DB / 2, v.v. mà không cần bất kỳ bản sửa lỗi mô phỏng nào.

  • Giữ các trường char và varchar dưới kích thước tối đa nhỏ nhất cho bộ công cụ bạn đang nhắm tới.

  • Khi bạn viết các truy vấn, hãy sử dụng cú pháp JOIN đầy đủ và đặt dấu ngoặc nhọn các JOIN để mỗi phép nối nằm giữa một bảng và biểu thức trong ngoặc.

  • Giữ logic xử lý ngày tháng trong mã, không phải các truy vấn, vì rất nhiều hàm ngày nằm ngoài tiêu chuẩn. (Ví dụ: nếu bạn muốn nhận nội dung trong hai tuần qua, hãy tính ngày hai tuần trước trong mã và sử dụng ngày đó trong truy vấn.)

Ngoài ra, nỗ lực liên quan không nên quá đáng sợ, vì vậy nó có thể xứng đáng.

15 hữu ích 0 bình luận chia sẻ
Trần Nguyệt Nga
· 08:43 15/10/2008
08:43:48 15/10/2008

Nếu tôi là bạn, tôi sẽ suy nghĩ kỹ về lợi tức đầu tư của bạn ở đây .

Nó luôn luôn có vẻ giống như một ý tưởng tuyệt vời để có thể treo lên để mọi back-end hay để thay đổi lại kết thúc bất cứ khi nào bạn thích, nhưng điều này rất hiếm khi xảy ra trong The Real World trong kinh nghiệm của tôi.

Hóa ra là bạn có thể bao gồm 95% khách hàng tiềm năng của mình bằng cách chỉ hỗ trợ Oracle & SQL Server (hoặc MySQL & SQL Server, hoặc ... vv).

Thực hiện nghiên cứu của bạn trước khi đi xa hơn , và chúc may mắn!

7 hữu ích 1 bình luận chia sẻ
Lý Thanh Như
· 08:41 15/10/2008
08:41:49 15/10/2008

Tôi hiện hỗ trợ Oracle, MySQL và SQLite. Và thành thật mà nói, nó khó khăn. Một số khuyến nghị sẽ là:

  • tránh các thủ tục được lưu trữ, nhưng bạn có thể cần chúng để mô phỏng các tính năng còn thiếu trên một số nền tảng (xem bên dưới)
  • tìm hiểu cách sử dụng trình kích hoạt, vì bạn sẽ cần chúng để mô phỏng các tính năng còn thiếu (ví dụ: với Oracle, bạn không có tính năng tự động tăng, vì vậy bạn cần phải mô phỏng nó và một lựa chọn tốt là sử dụng trình kích hoạt)
  • có một môi trường kiểm tra tốt vì bạn sẽ cần phải kiểm tra rất nhiều SQL trước khi biết chắc chắn rằng nó đang làm những gì bạn muốn trên tất cả các nền tảng của bạn.

Nó có giá trị nó không ... cũng phụ thuộc. Về mặt thương mại, nó đáng giá đối với các ứng dụng cấp doanh nghiệp, nhưng đối với blog hoặc trang web, bạn cũng có thể gắn bó với một nền tảng nếu có thể.

6 hữu ích 2 bình luận chia sẻ
Phạm Anh Tuấn
· 08:42 15/10/2008
08:42:41 15/10/2008

Một câu trả lời mà mọi người thường nói với bạn là không sử dụng sql dành riêng cho cơ sở dữ liệu và chỉ viết mã theo tiêu chuẩn ansi. Họ thường nói rằng chỉ nói chuyện với cơ sở dữ liệu thông qua các procs được lưu trữ để tóm tắt bất kỳ sql nào. Đây là những câu trả lời sai và chỉ dẫn đến đau đớn. Việc mã hóa thành sql 'tiêu chuẩn' là khá bất khả thi vì mỗi nhà cung cấp đều có những cách hiểu khác nhau như vậy.

Những gì bạn cần là có một số loại lớp bền vững của cơ sở dữ liệu để tóm tắt sự khác biệt giữa các cơ sở dữ liệu (xin lỗi johnstock, đây gần như là chính xác những gì bạn đã nói). Có nhiều ORM khác và các sản phẩm tương tự để thực hiện việc này cho mọi nền tảng,

6 hữu ích 3 bình luận chia sẻ
Hồ Đức Huy
· 08:44 15/10/2008
08:44:13 15/10/2008

Tôi sẽ tiết lộ câu trả lời của johnstok về 1) Không sử dụng các thủ tục được lưu trữ và 2) Không sử dụng SQL cụ thể của nhà cung cấp và thêm vào nó.

Bạn cũng hỏi, "Liệu nó có đáng để nỗ lực?". Tôi muốn nói ... có thể. Tôi đã viết một trình theo dõi lỗi mã nguồn mở, BugTracker.NET, dựa trên SQL Server. Có nhiều nhà phát triển chỉ đơn giản là sẽ không thử vì họ thích gắn bó với những công nghệ mà họ cảm thấy thoải mái. Và, khi tôi đang xem xét việc bắt đầu một dịch vụ lưu trữ, tôi nhận thấy rằng các máy chủ ảo Linux chuyên dụng rẻ hơn nhiều so với các dịch vụ Windows (không phải ảo). Về mặt lý thuyết, tôi có thể chạy C # dưới dạng mono, nhưng SQL của tôi quá cụ thể đối với SQL Server (mặc dù tôi không sử dụng procs được lưu trữ) nên sẽ là một nỗ lực rất lớn để chuyển.

Nếu bạn đang nhắm mục tiêu đến thị trường doanh nghiệp / công ty, bạn sẽ thấy rằng một số cửa hàng sử dụng Oracle hoặc SQL Server hoàn toàn khác và ứng dụng của bạn có thể bị loại trong các vòng đầu của cuộc thi dựa trên công nghệ mà nó sử dụng.

Vì vậy, có thể cởi mở không quan trọng đối với bạn. Đó là loại ứng dụng nào? Ai sẽ sử dụng nó?

Bạn cũng hỏi, "Các cạm bẫy là gì". Không thử nghiệm khi bạn tiếp tục. Nếu bạn có kế hoạch hỗ trợ 4 dbs mà bạn đã liệt kê, thì bạn nên thử nghiệm chúng sớm và thường xuyên hơn là chỉ nhắm mục tiêu một trong khi nghĩ rằng sẽ dễ dàng chuyển đổi sang các dbs khác. Đến lúc đó, bạn có thể thấy mình đang ở trong một công trình kiến ​​trúc.

5 hữu ích 0 bình luận chia sẻ
loading
Không tìm thấy câu trả lời bạn tìm kiếm? Duyệt qua các câu hỏi được gắn thẻ sql database database-design , hoặc hỏi câu hỏi của bạn.

Có thể bạn quan tâm