Làm thế nào tôi có thể làm cho cơ sở dữ liệu của tôi ngắn gọn hơn?

Tôi đang viết một ứng dụng cho Android bằng SQLite (được ORMlite hỗ trợ nếu có vấn đề). Cho đến nay tôi đang trong giai đoạn khái niệm và làm việc về thiết kế cơ sở dữ liệu. Cơ sở dữ liệu đang được thiết kế để chứa một tập hợp các tài sản được đăng ký cho một hoặc nhiều người dùng. Tôi chưa bao giờ làm việc trên bất kỳ dữ liệu nào ngoài SQLite và thậm chí sau đó tôi chỉ tạo ra một vài cơ sở dữ liệu rất nhỏ. Vì vậy, tôi không chắc chắn rằng tôi xử lý thiết kế này một cách chính xác. Khi tôi mở rộng thiết kế của mình, nó bắt đầu trông như một mớ hỗn độn. Câu hỏi của tôi là:

Tôi có đang thiết kế cơ sở dữ liệu này theo kiểu quá nhiều đối tượng không? Là một lập trình viên java, đây chỉ là cách nó có ý nghĩa để thiết kế cơ sở dữ liệu.
Có cách nào để làm cho cơ sở dữ liệu trông giống như một mớ hỗn độn không?
Tôi thậm chí đang đi đúng hướng?

Để tham khảo ở đây là một protoype dễ đọc hơn của thiết kế cơ sở dữ liệu. Không có đánh máy đã được chỉ định chưa, xin lỗi.

Thiết kế cơ sở dữ liệu trước đó

Dưới đây là một hình ảnh cập nhật hơn về vấn đề của tôi.

Thiết kế cơ sở dữ liệu hiện tại

database-design

— ahodder
nguồn

Những gì bạn gọi messylà thực sự normalizationlà một điều tốt.

— JNK

@JNK, Ok. Vì vậy, sự phân mảnh nhiều này là một điều tốt. Điều gì sẽ là một tình huống phi thường?

— ahodder

Nó phụ thuộc vào trường hợp sử dụng của bạn. Nếu bạn sẽ chèn / cập nhật nhiều, việc chuẩn hóa có thể được ưu tiên vì bạn đang khóa / cập nhật ít dữ liệu hơn tại một thời điểm. Trong môi trường nặng đọc với dữ liệu tĩnh, dữ liệu không chuẩn hóa có thể được ưa thích vì nó đơn giản hóa các truy vấn và có thể thực hiện tốt hơn cho việc đọc.

— JNK

Tuy nhiên, một số câu hỏi - có vẻ như Tài sản / Xuất bản / Mã vạch LUÔN LUÔN cùng nhau ngoại trừ trong một trường hợp. Là mã vạch và xuất bản một tài sản của tài sản?

— JNK

Có vẻ như mô hình này có thể được hưởng lợi từ một số loại mối quan hệ cha mẹ / con cái, nhưng nếu không thì nó có vẻ hoàn toàn hợp lý.

— Jon Seigel

Đây là một nhận xét nhiều hơn, nhưng vì đây là một phản hồi dài đáng được đề cập, tôi sẽ đăng nó như một câu trả lời.

Cơ sở dữ liệu của bạn có vẻ đủ cho nhu cầu của bạn. (Vâng, là tốt nhất có thể giả định từ biểu đồ.) Tôi giả định rằng UserAccountbảng có mối quan hệ một-nhiều giữa bốn bảng Vehicle, Book, VideoGamevà Movie(từ đây trở đi, các bảng VBVM.) Tiếp theo, tôi giả định rằng Assetbảng có mối quan hệ một đối một với mỗi liên kết giữa các mục trong bảng VBVM. Với thông tin này, tôi khuyên bạn nên chuyển UserAccount_idtừ mỗi bảng VBVM sang AssetTable.

Tiếp theo, dường như Assetluôn được liên kết với một trong bốn bảng VBVM. Xem xét loại thiết lập này, tôi khuyên bạn nên tạo một bảng bổ sung-- AssetType.

+-----------+
| AssetType |
+-----------+
| id        |
| typeDesc  |
+-----------+

Tiếp theo, cập nhật Assetbảng và từng bảng VBVM để bao gồm một AssetType_IDtrường. các AssetTypebảng nên bao gồm một bài dự thi, đối với từng loại tài sản. Trong trường hợp này, Vehicle, Book, Video Gamevà Movie, mỗi với một mô tả độc đáo và ID.

Bạn có thể muốn làm điều này vì một vài lý do-- Trước tiên, bây giờ bạn có thể truy vấn Assetbảng và phân biệt loại tài sản nào được lưu trữ trong một bản ghi cụ thể mà không phải liên kết dữ liệu với bốn bảng VBVM khác của bạn. Điều này sẽ tăng tốc truy vấn dữ liệu của bạn, khi tất cả thông tin từ bốn bảng của bạn không cần thiết. Thứ hai, điều này cũng cung cấp một phương tiện dễ dàng liên kết trong một mô tả văn bản về loại tài sản được liên kết với Assetmục nhập. Một lần nữa, không cần phải liên kết với các bảng VBVM để tìm ra điều đó.

Cuối cùng, bạn có thể muốn xem xét xử lý dữ liệu mã vạch khác nhau. Nếu mã vạch là một tra cứu đơn giản, bạn có thể thêm nó vào bảng nội dung. Tuy nhiên, nếu các giá trị mã vạch phải là duy nhất, việc giữ nó trong một bảng phụ là cần thiết bởi vì bạn phải đặt một ràng buộc trên cơ sở dữ liệu. Bạn có thể làm điều này nếu nó được tích hợp trong Assetbảng, tuy nhiên, dữ liệu xe của bạn sẽ gây ra vấn đề vì xe không có mã vạch. Theo hiểu biết của tôi, nếu không phải tất cả, các công cụ cơ sở dữ liệu chính sẽ không cho phép bạn xác định một trường duy nhất, điều đó cũng cho phép nullcác giá trị bởi vì, sau đó, dữ liệu không còn là duy nhất.

Bạn có thể có xu hướng nghĩ rằng bạn có thể kết hợp Barcodetrường với VIN. Vì số VIN là duy nhất và Mã vạch là duy nhất và không giống nhau, tại sao chúng không thể được kết hợp thành một trường trên Assetbảng, cho phép bạn bỏ Barcodebảng bổ sung . Tôi không khuyến nghị điều này bởi vì tôi nghĩ rằng nó mang lại cho dữ liệu ít "trọng tâm" hơn.

Đúng, nó là một dạng ID đối tượng duy nhất nhưng mã vạch là mã vạch và số VIN là số VIN-- khái niệm đằng sau cả hai hoàn toàn khác nhau và hợp nhất cả hai có thể trở nên khó hiểu với thời gian. Hơn nữa, nếu bạn mở rộng dự án của mình trong tương lai, nó có thể gây ra va chạm. Về mặt kỹ thuật, tôi không thấy vấn đề lớn với điều đó (trong trường hợp của bạn) nhưng tôi vẫn khuyên bạn nên tránh lựa chọn đó.

Ngoài ra, tôi cũng sẽ thêm assetType_idvào Barcodebảng, vì những lý do tương tự như bạn thêm nó vào Assetbảng.

— RLH
nguồn

Cảm ơn bạn đã trả lời dài và đầy đủ. Tôi thực sự đã làm hầu hết điều đó ngay trước khi câu trả lời của bạn được đăng. Sau khi nhận xét và tham khảo wiki phân cấp một lần nữa, nó có vẻ như là ý tưởng hợp lý và tốt nhất. Tôi, tuy nhiên, đã không nghĩ đến việc thêm property_type. Điều đó cũng làm cho một lượng lớn ý nghĩa.

— ahodder

@AedonEtLIRA: Vâng, tôi đã không thấy cập nhật của bạn trong khi gõ câu trả lời. Tôi sẽ khuyên bạn nên di chuyển Barcodedữ liệu vào Publicationbảng, trừ khi bạn dự kiến sẽ tính Barcodeđến nhiều trường hợp của một ấn phẩm. Là mã vạch dành riêng cho một đối tượng, hay đây là một cái gì đó giống như ISDN?

— RLH

Tôi đã xem xét chuyển Barcodesang xuất bản. Tôi càng nghĩ về nó, nó càng có ý nghĩa khi ở trong đó. A Barcodekhông được đảm bảo là duy nhất. Ai đó có thể có nhiều phiên bản của một tài sản. Chúng ta sẽ ở đâu nếu (s / h / it) muốn theo dõi từng cái? Sau đó, một lần nữa, tôi có thể có một trường trong Assetbảng cho số lượng. Cảm ơn một lần nữa.

— ahodder