Tôi bắt đầu một ứng dụng cơ sở dữ liệu mới và tự hỏi liệu có nên bắt đầu thiết kế tại các đối tượng (với UML) và xây dựng lược đồ cơ sở dữ liệu cho phù hợp hay không. các đối tượng phù hợp.Tôi bắt đầu thiết kế khi sử dụng ánh xạ O/R ở đâu? Đối tượng hoặc bảng cơ sở dữ liệu?
Ưu và nhược điểm của một trong hai cách tiếp cận là gì?
(Tôi không nghĩ rằng nó quan trọng nhưng chỉ trong trường hợp: Tôi đang lập kế hoạch để sử dụng Java và Hibernate)
Phụ thuộc vào việc ứng dụng của bạn được thiết kế để đáp ứng nhu cầu của người dùng hay để đáp ứng nhu cầu của nhà phát triển.
Bắt đầu với các câu chuyện của người dùng và nhận các Lớp học OOP ngay lập tức. Và người dùng của bạn sẽ yêu bạn.
Nếu không, bạn kết thúc bằng một ứng dụng sẽ biến người dùng thành nhân viên nhập dữ liệu. (Bạn sẽ có nhiều công ty.)
Bắt đầu ở cấp cơ sở dữ liệu chắc chắn sẽ cho phép bạn tạo một cơ sở dữ liệu được dễ dàng hơn bằng cách xử lý một cơ sở dữ liệu quan hệ thường xuyên. Vì vậy, nếu bạn mong đợi để có được hàng trăm ngàn hoặc thậm chí hàng triệu đối tượng, đây là cách tiếp cận tôi sẽ thực hiện. Tuy nhiên, nếu bạn không mong đợi nhận được nhiều dữ liệu, hoặc nếu hiệu suất không liên quan, tôi sẽ đi với phương pháp tiếp cận đối tượng vì nó sẽ cho phép bạn lập mô hình một giải pháp phù hợp hơn với ứng dụng thực tế của bạn.
Ưu điểm của việc bắt đầu với cơ sở dữ liệu là bạn sẽ có hiệu suất và DBA của bạn trong tâm trí.
Ưu điểm của việc bắt đầu với bên OOP là bạn sẽ có thiết kế OO tinh khiết hơn, nhưng ORM của bạn có thể kém hiệu quả.
Tôi thấy các ORM hộp đen quá giới hạn, vì vậy hệ thống của tôi được mã hóa bằng tay hoặc mã được tạo và sửa đổi, vì vậy cơ sở dữ liệu của tôi thường khá chặt chẽ. Tôi mạnh mẽ tin rằng con người thông minh là giải pháp cho sự không phù hợp trở kháng.
Tùy thuộc vào nơi bạn muốn có hiệu suất tốt nhất. Nếu bạn mong đợi cơ sở dữ liệu là nút cổ chai của bạn, sau đó bắt đầu thiết kế ở đó để bạn có thể điều chỉnh nó cho hiệu suất. Nếu bạn chỉ sử dụng một cơ sở dữ liệu để lưu trạng thái của một vài đối tượng cần phải thực hiện trong ứng dụng của bạn, sau đó thiết kế chúng cho phù hợp. O/R lập bản đồ phần mềm không phải là đáng tin cậy (được nêu ra, và họ sẽ không bắt kịp sớm) tại điều chỉnh hiệu suất như là một trình biên dịch tốt. Bạn vẫn sẽ làm một công việc tốt hơn về thiết kế cho hiệu suất (mặc dù với chi phí phát triển trả trước cao hơn).
Nếu bạn đang viết một Ứng dụng OO thì tôi thấy rằng việc thiết kế các đối tượng trước tiên là nơi bắt đầu. Tôi muốn tạo ra một thiết kế OO tốt và sau đó cố gắng tối ưu hóa cơ sở dữ liệu thay vì xây dựng một cơ sở dữ liệu rồi cố gắng phù hợp với các đối tượng vào cơ sở dữ liệu.
Công cụ ORM cho phép bạn tự do tập trung sự chú ý vào thiết kế đối tượng.
Tuy nhiên, nó không thay thế Thiết kế cơ sở dữ liệu tốt. Bạn vẫn phải theo dõi cơ sở dữ liệu. Tôi thấy rằng với suy nghĩ cẩn thận, ánh xạ OR có thể được thực hiện để cơ sở dữ liệu được tạo ra khá tối ưu. Bạn luôn có thể xem các truy vấn và cố gắng tối ưu hóa chúng nếu bạn thấy một số truy vấn kém hiệu quả.
Bạn không cần phải xây dựng một ứng dụng phù hợp với mô hình cơ sở dữ liệu, cơ sở dữ liệu nên được thiết kế để hỗ trợ các ứng dụng của bạn. Và các công cụ ORM cho phép bạn tạo cơ sở dữ liệu và truy vấn được tối ưu hóa.
Điều đó tùy thuộc. Bạn đang làm lập trình hướng đối tượng hoặc lập trình hướng SQL?
Hoặc cách tiếp cận có thể hoạt động và mỗi phương pháp đều có ưu điểm và nhược điểm riêng. Cách tiếp cận tập trung vào DB là rất tốt cho nhiều ứng dụng chia sẻ dữ liệu. Cách tiếp cận đối tượng làm trung tâm là rất tốt để có được một ứng dụng và chạy.
Nếu DB không tồn tại, tôi sẽ xem xét việc tạo ứng dụng mà không cần lo lắng về nó. Có lẽ một cái gì đó giống như db4objs sẽ cung cấp cho bạn sự kiên trì đối tượng bạn cần trong khi bạn phát triển ứng dụng của bạn thành một cái gì đó hữu ích. Sau đó, khi các ứng dụng mới được thiết kế để chia sẻ dữ liệu hoặc truy vấn đặc biệt trở nên quan trọng, một ánh xạ DB quan hệ sẽ có ý nghĩa hơn. Có lẽ bạn sẽ không bao giờ cần quan hệ. Xây dựng nó khi bạn cần.
Nếu DB đã tồn tại hoặc yêu cầu lấy dữ liệu của bạn ở đó, tôi vẫn cố trì hoãn công việc quan hệ càng lâu càng tốt và làm cho các đối tượng và mã hoạt động. Nhưng tôi sẽ thay đổi suy nghĩ của mình nếu tôi thấy bản thân mình viết mã phức tạp có thể được thực hiện bởi SQL.
Tùy thuộc vào điểm mạnh của bạn và nơi bạn muốn đi.
Bạn có thể bắt đầu với các đối tượng và thực hiện một công việc khá tốt, bao gồm thiết kế bảng tốt trong cơ sở dữ liệu của bạn, nếu bạn bắt đầu ở đúng nơi.
Bắt đầu với phân tích hướng đối tượng, thay vì thiết kế hướng đối tượng. Tôi không thể nhấn mạnh sự khác biệt giữa phân tích và thiết kế đủ mạnh. Những người viết về phân tích hướng đối tượng, một số người sử dụng UML như một công cụ, cố gắng làm cho sự khác biệt này rõ ràng. Phân tích liên quan đến miền vấn đề, trong khi thiết kế liên quan đến miền giải pháp. Đây có thể dễ dàng được trộn lẫn với nhau, cho dù cách tiếp cận của bạn là hướng đối tượng hay không.
Nếu bạn thực hiện phân tích OOA tốt về các yêu cầu của dự án, bạn có thể làm một công việc hợp lý để xây dựng mô hình dữ liệu khái niệm song song và giữ hai mô hình đó đồng bộ với nhau. Khi bạn xây dựng một mô hình dữ liệu khái niệm, tôi đề nghị bạn giữ một mô hình giống như mô hình ER.
Mô hình ER sẽ không cho bạn biết cách thiết kế cơ sở dữ liệu của bạn. Đó là toàn bộ vấn đề. Cách bạn phân tách mối quan tâm phân tích từ mối quan tâm thiết kế trong mô hình hóa dữ liệu là thực hiện phân tích của bạn bằng cách sử dụng mô hình ER và thiết kế của bạn bằng cách sử dụng mô hình hóa dữ liệu quan hệ, ít nhất là lúc đầu.
Ánh xạ giữa OOA và ER đủ đơn giản để bạn có thể quản lý hai mô hình song song. Có thể có các công cụ mới hơn quản lý cả hai loại mô hình cho bạn. Việc ánh xạ giữa ER và RDM là đơn giản. Trong ánh xạ đơn giản nhất, bạn chuyển từng thực thể thành một bảng được đánh dấu trên danh tính của đối tượng và mỗi mối quan hệ thành một bảng riêng biệt được khóa trên các khóa ngoài tham chiếu đến các thực thể. Có thể và mong muốn giảm số lượng bảng bằng cách cắm một số khóa ngoại vào bảng thực thể, nhưng đó là một chi tiết.
Từ OOA, bạn tiến hành OOD để thiết kế và OOP để lập trình.
Từ ER cho mô hình hóa dữ liệu khái niệm, bạn tiến hành RDM để lập mô hình dữ liệu lôgic và phương ngữ cụ thể DBMS của SQL của bạn cho mô hình hóa dữ liệu vật lý. Có những công cụ chắc chắn để giúp bạn với điều này, nếu dự án của bạn quá lớn để lập mô hình trên giấy hoặc bảng trắng.
Định kỳ, bạn xây dựng những gì bạn đã có, có thể với phần cho phần không có sẵn và bạn điều chỉnh thiết kế ứng dụng của bạn với thiết kế cơ sở dữ liệu của bạn. Nếu bạn làm một công việc tốt, vào cuối ngày, bạn sẽ có hình dạng khá tốt.
Nếu bạn đang thiết kế một cơ sở dữ liệu và một số ứng dụng cùng một lúc, mọi thứ trở nên thực sự thú vị.
câu chuyện của người dùng ftw – TheSoftwareJedi