Bảng tin - Tối ưu hóa cơ sở dữ liệu

.
22.3. Cần hiểu tại sao, không có vấn đề gì cả. Chỉ trẻ em mới mù quáng tuân theo những quy tắc đơn giản, và bạn chắc chắn không phải là một trong số đó.
.
23. Đã xác nhận:users.total_bulletins là thừa; nó có thể được dẫn xuất. Đã xóa.
.
24. Tất cả PK của bạn đều là Id. Bạn vẫn chưa cảm thấy mệt mỏi vì bị mất mã chưa? Quên việc dán Id iot PK trên mọi thứ di chuyển, hãy cùng tìm hiểu xem người dùng của bạn như thế nào Xác định các Thực thể của chúng; Thực thể nào thực sự Độc lập và đối tượng nào phụ thuộc vào Thực thể độc lập.

24.1. Không bao giờ sử dụng Id hoặc bất kỳ hình thức nào như vậy. Nếu nó là PK, hãy sử dụng biểu mẫu đầy đủ.

24.2. Gọi location_id, location_id, mọi lúc mọi nơi, kể cả bảng PK. Ngoại lệ là khi bạn cần thể hiện vai diễn. Điều này sẽ trở nên rõ ràng trong Mô hình Dữ liệu.
.
25. Bạn không có Tính toàn vẹn tham chiếu được khai báo, không có Được xác định Khóa ngoại. Đó là một tin xấu vì nhiều lý do khác nhau. Sau khi những câu hỏi này được xác nhận, vui lòng thêm chúng vào. DRI có nghĩa là càng nhiều càng tốt, nếu không phải tất cả, Tính toàn vẹn được khai báo trong SQL. Tiêu chuẩn SQL ISO / IEC / ANSI cho phép điều này, nhưng phần mềm miễn phí của thị trường không cung cấp tiêu chuẩn và đang dần bắt kịp. Nó có nghĩa là máy chủ sẽ không cho phép thêm một hàng trong bảng FK trừ khi PK tồn tại trong bảng mẹ. MySQL gần đây đã cung cấp DRI cho Khóa ngoại. Đối với FK, hãy tham khảo ▶ bài viết này ◀ .

25.1. Đối với các ràng buộc và QUY TẮC KIỂM TRA, bạn sẽ phải triển khai chúng trong mã.

Các khóa ngoài của tôi giống như, users-id (fk) =users.id (pk) Tôi không chắc cách thêm chúng vào những gì tôi đã làm nhưng chắc chắn sẽ làm như vậy khi tôi biết cách.

Hai mươi lăm. Đã ghi chú nhận xét. Tôi không phải là chuyên gia MySQL. Vâng, đó là những vấn đề bạn phải tự tìm ra. Nói chung, theo sự tìm hiểu của tôi, MySQL là không có chân; đối với bất kỳ thứ gì SQL-ish, bạn cần InnoDB.

.
27. Đã cho: Tôi đã suy nghĩ lại các yêu cầu sắp xếp cho bản tin. Người dùng có thể sắp xếp theo thứ tự thời gian- dễ dàng, hợp lý. Người dùng có thể sắp xếp các bản tin theo ngày trả lời bản tin gần nhất. Sau đó, chúng ta có thể quên đi thứ hạng và sẽ thực sự dễ dàng để sắp xếp các bản tin theo thứ tự thời gian vào thời điểm phản hồi cuối cùng của chúng? Suy nghĩ của bạn là gì.

Sự cố mở

(Không)

Mô hình dữ liệu

Được, giả sử bạn không gặp vấn đề với ERD và triển khai tất cả các Vấn đề đã đóng, tôi đã lập mô hình dữ liệu và chuẩn bị Mô hình dữ liệu thứ năm ngày 09 tháng 12 năm 10 cho nhận xét của bạn. Tôi chắc chắn cần nhiều hơn nữa phản hồi, câu hỏi, v.v. về điều này. Tôi đang gặp khó khăn trong việc chấp nhận rằng nó đã được thực hiện. Có lẽ tốt nhất nên bắt đầu viết mã thực cho các lĩnh vực vấn đề của bạn.

Liên kết

▶ Liên kết tới IDEF1X Notation ◀ Bạn thực sự cần đọc và hiểu điều này trước khi đọc Mô hình dữ liệu.

▶ Liên kết đến Dữ liệu Bản tin Thứ Năm Mô hình ◀ Sơ đồ quan hệ thực thể nằm trên trang đầu tiên, tiếp theo là Mô hình dữ liệu .

• Các phím có khá nhiều IDEF1X thẳng (ngoại trừ UserId mà tôi đã cung cấp làm điểm đối chiếu); có nghĩa là ví Chìa khóa quan hệ. Chưa được nâng cao và không được tối ưu hóa để xem xét Vật lý. Trước khi bạn phản đối họ, trước tiên hãy chú ý đến họ, đăng ký và đánh giá họ. Tất nhiên, chúng tôi có thể thêm Id iot key, nhưng trước khi làm điều đó, hãy đảm bảo rằng chúng tôi hiểu những gì chúng tôi sẽ mất.

• Lưu ý các Số nhận dạng (đường liền nét) theo tài liệu Ký hiệu. Cột sống, đốt sống của hệ thống là Location ... Bulletin ... Response .

• Lưu ý rằng Keys thực sự triển khai nhiều Quy tắc kinh doanh.

• Lưu ý Cấu trúc phân cấp tự nhiên mà tôi đã kết xuất. Hãy xem nó có ý nghĩa gì đối với bạn không.

• Các Cụm động từ thực sự quan trọng; xem chúng có ý nghĩa gì không.

Nhận xét về Mô hình dữ liệu đầu tiên và các phản hồi

Một câu hỏi của tôi là khóa chính của vị trí sẽ được sử dụng để tạo khóa chính con? (chúng được nối với nhau bằng một đường liền nét) Tôi không thực sự hiểu khái niệm đó

• Định danh tốt cho Bản tin là gì? , những gì người dùng của bạn thường sử dụng để xác định một bản tin ...
• "bạn đã xem bản tin của Virginia FO hôm qua chưa?",
• "Sally từ Washington chắc chắn viết những bản tin tốt", v.v.

hoặc tại sao mối quan hệ đó không tồn tại giữa người dùng và bản tin?

• Theo ý định đã nêu thêm ở trên, vì bây giờ tôi đã hiển thị Xếp hạng dưới dạng bảng và kết xuất sẽ như thế nào, một lần, tôi sẽ xóa nó đi

• Tôi nghĩ Quyền phải là một Thực thể.

• Bulletins PK bây giờ là (StateCode, Town, UserId, SequenceNo) . Để rõ ràng, SequenceNo nằm trong StateCode, Town, UserId :nó sẽ là 5 cho bản tin thứ 5 của Sally là MO / Billngs FO.

• Lưu ý rằng Cài đặt người dùng BulletinsPerPage , v.v., là 1 ::1 với User , vì vậy chúng nằm trong User; bảng con sẽ không chính xác.

• Đã sửa lỗi đánh máy.

Nhận xét về Mô hình dữ liệu thứ hai và các phản hồi

• PK cho cả Bulletins và Responses đã được thay đổi để phản ánh (7). BulletinNo và ResponseNo đã được thay thế bằng BulletinDate và ResponseDate (từng là CreatedDate ), để cho phép nhiều câu trả lời cho mỗi User per Bulletins .

Nhận xét về Mô hình dữ liệu thứ ba và các phản hồi

Tin rằng bạn đã có một kỳ nghỉ tốt.

1. Ít nhất 30 năm trước (mà tôi được biết), những người khổng lồ trong ngành đã có cuộc tranh luận này. Tên luôn luôn là số ít. Bàn là danh từ. VerbPhrases là động từ. Điều này không giới hạn ở quy ước đặt tên db, nó áp dụng cho các tài liệu, luận văn, luận án, v.v. Bạn có thể có 5 kết luận ở cuối tài liệu, nhưng phần hoặc tiêu đề chương, trong cả ToC và đầu trang là "Kết luận".

   Sau khi chiến đấu với họ bằng mọi cách thông qua Uni, ngay khi tôi bắt đầu công việc lập trình được trả lương đầu tiên, và thấy tầm quan trọng của các quy tắc trong thế giới thực, trái ngược với những lý lẽ lý thuyết mà chúng tôi có ở trường đại học, tôi đã từ bỏ nó như một sự lãng phí của thời gian. Tất cả thời gian và năng lượng tôi lãng phí đã được giải phóng để làm việc hiệu quả. Kể từ đó, tôi không thắc mắc về những người khổng lồ; Tôi chỉ chấp nhận. Rằng tâm trí của họ vĩ đại hơn tôi. Nó giống như việc chấp nhận các Tiêu chuẩn, hoặc cư xử theo luật pháp, hoặc Chúa. Tôi không có lý do thực sự, thực sự chính đáng để làm bất cứ điều gì bất hợp pháp.

   Dù sao đi nữa, không thể giải thích đầy đủ về tính dễ bị mòn mỏi (thảo luận, SQL, tài liệu) được hỗ trợ bởi các quy tắc như vậy; khi bạn viết ngày càng nhiều mã SQL, nó sẽ trở nên rõ ràng.

   Bạn luôn được tự do sử dụng bất cứ thứ gì bạn muốn. Tôi chỉ cung cấp số ít.

2. Tốt với tôi.

   Nhưng bạn cần lưu ý rằng hai yếu tố đó, trong trình tự đã xác định (Chỉ số duy nhất không phải PK, hoặc Khóa thay thế) được yêu cầu phổ biến để thiết lập Tính duy nhất cho một Người. Loại bỏ chúng sẽ dẫn đến hai điều. Đầu tiên, bạn sẽ không thể xác định tính duy nhất trên User nữa (và do đó bạn có thể có các hàng trùng lặp). Thứ hai, AK trở thành không duy nhất, một Mục nhập Đảo ngược.

3. Vấn đề là (trái với một trong các bài đăng), bất kỳ cột nào là 1 ::1 với User PK, phải nằm trong User . Tất cả các cài đặt tùy chọn. Vì chúng tôi đã dọn dẹp InterestedLocations và InterestedCategories , Tôi chỉ biết duy nhất BulletinsPerPage còn lại; nhưng tôi chắc chắn rằng có những người khác. IsPreference2 là một ví dụ. của một boolean; NumPreference3 là một ví dụ. của một Số nguyên. Vv. Bạn có thể cho tôi biết Preferences thực sự là gì.

   (Hãy thử điều đó ở dạng số nhiều:... bất kỳ cột nào là 1 ::1 với Users PK, phải nằm trong Users . Chỉ là tôi không làm được điều đó, tôi cảm thấy chán nản vì tiếng Anh hỏng, và tôi hơi quý về tiếng mẹ đẻ của mình.)

   Đã cập nhật mô hình dữ liệu.

4. Thông minh. Hãy cho tôi biết khi bạn cảm thấy thoải mái với điều đó và tôi sẽ cung cấp cho bạn Mô hình vật lý.

   Làm thế nào về các VerbPhrases?

Nhận xét vào ngày 6 tháng 12 10 tháng 12 20:38 EST (Cập nhật nhỏ)

.
28. Trong trường hợp chỉ có một lần xuất hiện PK dưới dạng FK, tất nhiên, tên cột FK giống với tên cột PK. Tuy nhiên, khi có nhiều hơn một lần FK (hãy xem ResponseRating ), có ba UserIds ), chúng ta cần phân biệt chúng. Trong thuật ngữ IDEF1X, nó được gọi là Vai trò. Vai trò của User người đã phát hành Bulletins là Issuer , và như thế. Rõ ràng là tốt hơn nên sử dụng tên đó và giữ cho nó nhất quán trong toàn bộ phân cấp (không phải UserId trong Bulletins và sau đó khi chúng tôi nhận được Responses , trong đó có hai và cần có sự khác biệt, hãy đổi nó thành IssuerId . Tôi nghĩ rằng bạn có thể có một vấn đề với điều đó; trong giai đoạn đầu, việc sử dụng là Issuer.UserId để hoàn toàn rõ ràng đó là UserId với tư cách là FK và Vai trò là Issuer; khi chúng ta đến với mô hình vật lý, nó được đơn giản hóa thành IssuerId .

Tương tự như vậy, chúng ta có nhiều cột DateTime (Viết tắt là ngày nếu bạn thích; nếu không thì là Dtm), cần được phân biệt.
.
29. Tài liệu Ký hiệu IDEF1X không có ý nghĩa?

• PK cho mỗi bảng nằm trên dòng, theo thứ tự được chỉ định.
• Hãy nhớ rằng chúng tôi vẫn đang mang các PK của bảng cha và nếu có ý nghĩa, hãy sử dụng các FK đó để tạo PK con.

• Đối với Bulletins :

  • Vị trí FK (StateCode, Town) mà nó được phát hành
  • UserId của Nhà phát hành
  • và DateTime nó đã được phát hành, để làm cho nó trở nên độc đáo.
  • do đó (StateCode, Town, IssuerId, BulletinDate) `

• Để xóa tất cả ResponseRatings cho Bulletins này , sử dụng WHERE = trên bốn Bulletins đó cột.

.
30. Bởi vì (State, Town) là PK của Location , mang theo mọi lúc mọi nơi. Và nó tạo thành một phần của Bulletins PK, vì vậy bất kỳ bảng phụ thuộc nào cũng mang các cột đó vì chúng đang mang Bulletins PK.

Trước đây chúng tôi đã xác định rằng (State, Town) là PK, Tôi sẽ để nguyên như vậy Tham khảo (38) để biết sự thay đổi.

.
33. Đáng bàn. Có, nếu bạn định hiển thị nó khi (ví dụ) hiển thị Responses và người dùng hiểu UserName . Không, nếu nó là 30 byte và cũng có một UserId 4 byte duy nhất . Ý tưởng là thực hiện những lựa chọn này một cách có ý thức, nhận thức được những gì bạn đang từ bỏ, khi cuối cùng bạn quyết định rằng một số khóa 6 cột 30 byte quá cồng kềnh để chuyển sang phần con.

• Tôi đã nói ngay từ đầu, tôi sẽ sử dụng UserId như một Id điển hình Pk, vì nó được thực hiện / di chuyển sang một số bảng con.
• Chúng tôi có thể để lại cách tạo ra sau này. Nhưng đó là một PK phụ họa thuần túy.

.
34. Không vấn đề gì. Category đã có nó. Tôi sẽ thay đổi Order tới ListOrder .

.
35. Chắc chắn. Dựa trên những gì tôi đã đọc và nghe thấy, tôi khá hài lòng với nó. Nhưng tôi muốn nói lại nhiều hơn để đạt được sự tự tin nhất định, trước khi bạn viết mã. Ngoài ra, hãy xem nó như một trải nghiệm học tập và chấp nhận rằng mô hình và mã có thể thay đổi sau này. Bạn có muốn tôi sản xuất Vật lý bây giờ không? Nếu bạn cho tôi bất kỳ và tất cả các chỉnh sửa, tôi sẽ xuất bản phiên bản tiếp theo. Tôi đang mong đợi các tùy chọn trong User . Ngoài ra, hãy nhanh chóng chạy qua các chức năng và kiểm tra xem bạn có tất cả các cột bạn cần hay không.

Hãy xem một số câu trả lời khác, với mục đích tìm hiểu và quan tâm.

.
36. Tham gia. Bạn chỉ cần tham gia trên bốn ba cột đối lập với một. SQL cồng kềnh với các phép nối và cú pháp mới được cho là làm cho nó dễ dàng hơn, thực tế lại cồng kềnh hơn. Các lập trình viên của tôi không bao giờ viết phép nối:chúng tôi tiết kiệm thời gian và lỗi chính tả. Tôi có một chương trình cung cấp hai hoặc nhiều bảng, sẽ tạo mã với tất cả các cột và nối. Tôi không biết đủ MySQL để chuyển đổi nó cho bạn.

Đã cập nhật mô hình dữ liệu.
.

Nhận xét về ngày 08 tháng 12 10 20:49, Mô hình dữ liệu thứ tư và các phản hồi

.
Kiểm tra phần trước ngay phía trên, có các cập nhật nhỏ.

IDEF1X:Tốc độ của bạn ổn.

Lưu ý con luôn luôn "kế thừa" Parent PK, dưới dạng FK (đường liền hoặc đứt), nếu không thì không có Quan hệ giữa chúng. Bằng cách sử dụng các cột tồn tại trong con, để tạo PK con, chúng tôi mang ý nghĩa (và đó là sự khác biệt giữa rắn và vỡ). Và do đó, chúng tôi không cần phải tìm một Mã định danh độc lập cho đứa trẻ. Sức mạnh quan hệ trong phương pháp này sẽ trở nên rõ ràng sau này, khi bạn đang viết mã.

Phần chúng tôi đang giải quyết là về Số nhận dạng :tự nhiên vs không tự nhiên; có ý nghĩa vs vô nghĩa. Sau đó, bạn sẽ thấy cách chúng ta có thể sử dụng Khả năng quan hệ của động cơ, khi PK con được hình thành từ PK mẹ. (Họ của bạn không giống với tên của bố bạn sao?)

Điều quan trọng là phải hiểu Cơ sở dữ liệu quan hệ và khả năng của chúng. Điều đó bị mất đi khi chúng ta tiếp cận cơ sở dữ liệu (ví dụ) từ góc độ OO và coi nó như một vị trí để làm cho các lớp của chúng ta "bền bỉ". Vì vậy, chúng tôi sẽ cố gắng tìm hiểu và sử dụng các thuật ngữ Quan hệ. Sẽ thật khó khăn khi bạn đến Pháp và mong đợi rằng họ nói tiếng Mỹ và sử dụng cùng một loại tiền tệ; học nói 10 từ tiếng Pháp và họ chào đón bạn với vòng tay rộng mở, và bạn sẽ có trải nghiệm hoàn toàn khác với người dân địa phương.

Dù sao, hãy tiếp tục với việc thực hiện mô hình. Chỉ cần nhận ra rằng chúng ta có thể sẽ tạo ra sự thay đổi vào một thời điểm nào đó. Lưu tất cả DDL của bạn. Lưu tất cả dữ liệu thử nghiệm của bạn dưới dạng câu lệnh chèn hoặc sao lưu bảng hoặc xuất định dạng ký tự (không biết MySQL có thể / không thể làm gì trong lĩnh vực này) ..
37.1. Xử lý, mối quan hệ n ::n với Office &Category . Bạn sẽ chỉ "thấy" điều đó khi chúng tôi đến Mô hình vật lý.

37,2. Đã xong.

37.3 Hoàn tất.
.
38. Thông minh. Ngắn hơn nữa. Lưu ý rằng họ sẽ không bao giờ có thể có hai Offices trong cùng một mã Zip. NUMERIC (5,0) là tốt, nhưng tôi nghĩ rằng Hoa Kỳ đang tiến tới 7 chữ số. Không quan trọng, bạn có thể tìm ra nó; nó là một PK tuyệt vời cho Office . Bây giờ, cột này, là một phần của Address , có thể là ZipCode , đã được nâng tầm với mục đích cao hơn, không trùng lặp; vì chúng tôi đang chứa nó trong 5 bảng con và chúng tôi muốn tên PK rõ ràng, theo các quy ước đã giải thích trước đó, chúng tôi sẽ gọi nó là OfficeCode; OfficeZipCode có thể là ngớ ngẩn.

Chúng tôi cần một Chỉ mục duy nhất trên Name để đảm bảo họ không thêm hai Offices cùng tên. Lưu ý, với mục đích giải thích, đây thực sự là khóa logic của Office , thay thế (StateCode, Town) và nó vẫn như vậy.

Tôi vẫn nghĩ rằng bạn có thể cần StateCode và Town như một tài liệu tham khảo nhanh (ngoài việc ngồi ở đâu đó trong Address )

Đã cập nhật Mô hình Dữ liệu, Thứ năm hiện có sẵn để xem xét. Bạn đã không nêu sở thích của mình, cho ...Date so với ...Dtm . Tôi đang đi với cái sau, vì nó cụ thể hơn, xác định cả thành phần thời gian. Dễ dàng thay đổi.

Câu trả lời này đã đạt đến độ dài tối đa. Tiếp tục trong "Phần II"