Ví dụ: nếu tôi muốn lưu trữ danh sách bạn bè của người dùng, thì cách tôi có thể nghĩ ra sẽ giống như thế này
người dùng. bạn
John. Jim
John. Bob
John. Amy
Bob. Jim
Bob. Amy
Vì vậy, danh sách bạn bè của John sẽ bao gồm Jim, Bob và Amy và danh sách bạn bè của Bob sẽ bao gồm Jim và Amy. Nhưng có vẻ như không hiệu quả khi tạo một hàng mới mỗi khi cần một mục mới trong danh sách
Tôi muốn có thể lưu trữ các giá trị như thế này
người dùng. danh sách bạn bè
John. Jim,Bob,Amy
Bob. Jim, Amy
Điều gì sẽ là cách hiệu quả nhất để làm điều này?
13 Sep '08 #
9 33372
Xin chào
Phương pháp thứ hai bạn đề cập không bao giờ nên được sử dụng. Không trường nào được chứa nhiều hơn một mẩu dữ liệu
Một phương pháp đơn giản để làm điều gì đó như thế là tạo hai bảng. Một cho thông tin người dùng và một cho mối quan hệ giữa mỗi người dùng
Nó có thể trông giống như
- Người sử dụng
- ----------------
- UserID Tên người dùng
- 1 John
- 2 Jim
- 3 Amy
- ----------------
- Quan hệ người dùng
- ----------------
- UserID FriendID
- 1 2
- 1 3
- 2 1
- 3 2
- ----------------
13 Sep '08 #
Xin chàoĐây gần như là thiết lập mà tôi hiện có, nhưng tôi nghĩ nó không hiệu quả. Vì vậy, chỉ để làm rõ, đây là cách tốt nhất để lưu trữ tập dữ liệu kiểu danh sách?Phương pháp thứ hai bạn đề cập không bao giờ nên được sử dụng. Không trường nào được chứa nhiều hơn một mẩu dữ liệu
Một phương pháp đơn giản để làm điều gì đó như thế là tạo hai bảng. Một cho thông tin người dùng và một cho mối quan hệ giữa mỗi người dùng
Nó có thể trông giống như
Trường hợp cả hai trường của bảng đếm UserRelation đều tham chiếu đến trường UserID trong bảng Người dùng. Bạn thậm chí có thể tham gia chúng với tư cách là Khóa chính để tránh các mục nhập trùng lặp
- Người sử dụng
- ----------------
- UserID Tên người dùng
- 1 John
- 2 Jim
- 3 Amy
- ----------------
- Quan hệ người dùng
- ----------------
- UserID FriendID
- 1 2
- 1 3
- 2 1
- 3 2
- ----------------
Một thứ khác. Trên bảng thứ hai đó, khóa chính duy nhất sẽ là gì?
14 Sep '08 #
Đúng. Đây gần như là cơ sở của một N. mối quan hệ M
Điều này cũng hiệu quả hơn nhiều so với những gì bạn đã đề xuất trong bài đăng đầu tiên của mình
Đầu tiên, ví dụ đầu tiên của bạn lưu trữ mọi thứ dưới dạng trường văn bản. Tìm kiếm thông qua các số nguyên nhanh hơn nhiều so với văn bản, ngay cả khi các trường văn bản được lập chỉ mục. Chưa kể dung lượng đĩa mà tất cả văn bản đó chiếm, so với các số nguyên
Ví dụ thứ hai của bạn, trong khi sử dụng cấu trúc bảng ít phức tạp hơn, lưu trữ nhiều phần dữ liệu trong mỗi trường dưới dạng một chuỗi, chuỗi này phải được xử lý và chia thành từng phần riêng lẻ mỗi khi cần sử dụng bất kỳ phần nào trong số chúng.
Chi phí hoạt động vượt xa bất kỳ chi phí hoạt động nào mà một THAM GIA đơn giản sẽ gây ra, đặc biệt là sử dụng cấu trúc đơn giản, giống như cấu trúc tôi đã đăng.
Bảng thứ hai không cần khóa chính số nguyên một cột truyền thống mà chúng tôi sử dụng trên hầu hết các bảng.
Bạn có thể sử dụng hai cột khóa ngoại làm khóa chính.
- TẠO BẢNG BẢNG Quan hệ người dùng [
- UserID_FK INT Chưa ký Không phải Không Tham chiếu Người dùng[UserID],
- FriendID_FK Int Unsigned Not Null References Người dùng[UserID],
- Khóa chính [UserID_FK, FriendID_FK]
- ];
14 Sep '08 #
Đúng. Đây gần như là cơ sở của một N. mối quan hệ MTôi không quen với cú pháp tạo bảng tham chiếu khóa ngoại. Bạn có thể giải thích việc sử dụng hai tên cột với Khóa chính[] không?Điều này cũng hiệu quả hơn nhiều so với những gì bạn đã đề xuất trong bài đăng đầu tiên của mình
Đầu tiên, ví dụ đầu tiên của bạn lưu trữ mọi thứ dưới dạng trường văn bản. Tìm kiếm thông qua các số nguyên nhanh hơn nhiều so với văn bản, ngay cả khi các trường văn bản được lập chỉ mục. Chưa kể dung lượng đĩa mà tất cả văn bản đó chiếm, so với các số nguyên
Ví dụ thứ hai của bạn, trong khi sử dụng cấu trúc bảng ít phức tạp hơn, lưu trữ nhiều phần dữ liệu trong mỗi trường dưới dạng một chuỗi, chuỗi này phải được xử lý và chia thành từng phần riêng lẻ mỗi khi cần sử dụng bất kỳ phần nào trong số chúng.
Chi phí hoạt động vượt xa bất kỳ chi phí hoạt động nào mà một THAM GIA đơn giản sẽ gây ra, đặc biệt là sử dụng cấu trúc đơn giản, giống như cấu trúc tôi đã đăng.Bảng thứ hai không cần khóa chính số nguyên một cột truyền thống mà chúng tôi sử dụng trên hầu hết các bảng.
Bạn có thể sử dụng hai cột khóa ngoại làm khóa chính.Điều này cũng sẽ bảo vệ bảng khỏi các mục nhập trùng lặp, chẳng hạn như liên kết một người dùng hai lần với cùng một người bạn
- TẠO BẢNG BẢNG Quan hệ người dùng [
- UserID_FK INT Chưa ký Không phải Không Tham chiếu Người dùng[UserID],
- FriendID_FK Int Unsigned Not Null References Người dùng[UserID],
- Khóa chính [UserID_FK, FriendID_FK]
- ];
Cảm ơn đã giúp đỡ
14 Sep '08 #
Chắc chắn rồi
Nói một cách đơn giản, nếu bạn chỉ định nhiều cột trong mệnh đề Khóa chính, MySQL sẽ tạo một khóa chung, bao gồm tất cả các cột đó
Giá trị thực của Khóa chính sẽ giống như.
Trường hợp các giá trị col1-colN sẽ được thay thế bằng giá trị của từng cột trong hàng đã cho.
Do đó, bạn không thể tạo một hàng chứa tổ hợp chính xác các giá trị cho các cột PK như bất kỳ hàng nào trước đó. Giá trị Khóa chính phải là duy nhất, thậm chí mỗi cột tạo nên Khóa chính có thể có các mục nhập trùng lặp
Điều này làm cho điều này trở nên lý tưởng cho tình huống chính xác mà chúng ta đang thảo luận
14 Sep '08 #
Vì vậy, nếu bảng Người dùng và Quan hệ người dùng được triển khai trong một ứng dụng thực tế, để hiển thị danh sách bạn bè của John, bạn phải thực hiện như sau
- CHỌN UserID TỪ `User` WHERE UserName = 'John'
- CHỌN ID bạn bè TỪ `UserRelation` WHERE UserID = 1
- CHỌN Tên người dùng TỪ `UserRelation` WHERE UserID = 2
- CHỌN Tên người dùng TỪ `UserRelation` WHERE UserID = 3
- Bạn bè
- ----------------
- Tên người dùng Tên bạn bè
- John Jim
- John Amy
- Jim John
- Amy John
- ----------------
11 Oct '08 #
Có. Đối sánh văn bản thường chậm hơn nhiều so với đối sánh số, mặc dù cách tiếp cận của bạn rất đơn giản.
Chưa kể rằng cách bạn đang đề xuất sẽ lãng phí vô số dung lượng ổ đĩa so với cách thích hợp.
Bạn cần sử dụng các công cụ có sẵn trong cơ sở dữ liệu quan hệ.
Truy vấn CHỌN không chỉ giới hạn ở cú pháp CHỌN TỪ ĐÂU. Bạn có thể yêu cầu nó tìm nạp dữ liệu từ nhiều bảng và yêu cầu nó lọc dữ liệu này dựa trên nhiều hơn sau đó kiểm tra boolean x = y đơn giản.
Đây là cách một cơ sở dữ liệu như vậy nên được sử dụng
- CHỌN `Người dùng`. `Tên người dùng` NHƯ 'Tên bạn bè'
- TỪ `Người dùng`
- INNER THAM GIA `UserRelation`
- BẬT `Người dùng`. `UserID` = `UserRelation`. `ID bạn bè_FK`
- VÀ `Mối quan hệ người dùng`. `UserID_FK` = [
- CHỌN `UserID` TỪ `Người dùng`
- WHERE `UserName` = 'John'
- ]
Lưu ý rằng tôi cho rằng Tên người dùng là duy nhất, đó là lý do tại sao tôi sử dụng nó trong truy vấn con mà không có mệnh đề GIỚI HẠN.
Nó thực hiện chính xác những gì mà tất cả các truy vấn CHỌN của bạn thực hiện, nhưng theo cách phù hợp.
Đây là sức mạnh thực sự của cơ sở dữ liệu quan hệ, đó là khả năng nối các bảng và lọc dữ liệu dựa trên nhiều hơn là chỉ một bảng duy nhất câu lệnh SELECT FROM WHERE.
Nếu bạn không hiểu cú pháp, tôi khuyên bạn nên đọc về cú pháp Tham gia và Truy vấn con.
Nếu nó hoàn toàn mới đối với bạn, bạn có thể muốn tra cứu một số hướng dẫn về các khái niệm đó.
11 Oct '08 #
Tất cả đều ổn và tốt cho đến khi người bạn đó có nhiều hơn một người bạn lol
17 Mar '11 #
Làm thế nào để bạn có nghĩa là?
Toàn bộ mục đích của các khái niệm mà chúng ta đang nói đến ở đây là liên kết một hàng với nhiều hàng khác. [Đọc. cho phép một người kết bạn với nhiều người. ]