Tôi đang bắt đầu một dự án mới và muốn lấy tên bảng và cột của mình ngay từ đầu. Ví dụ, tôi đã luôn sử dụng số nhiều trong tên bảng nhưng số ít được học gần đây là chính xác.

Vì vậy, nếu tôi có một bảng "người dùng" và sau đó tôi có các sản phẩm mà chỉ người dùng mới có, thì bảng đó có được đặt tên là "user_product" hay chỉ là "sản phẩm"? Đây là một mối quan hệ một đến nhiều.

Và hơn nữa, nếu tôi có (vì một số lý do) một số mô tả sản phẩm cho mỗi sản phẩm, thì đó sẽ là "user_product_description" hay "sản phẩm_descrip" hay chỉ là "mô tả"? Tất nhiên với các khóa ngoại đúng được đặt .. Đặt tên mô tả chỉ có vấn đề vì tôi cũng có thể có mô tả người dùng hoặc mô tả tài khoản hoặc bất cứ điều gì ..

Thế còn nếu tôi muốn một bảng quan hệ thuần túy (nhiều đến nhiều) chỉ với hai cột, thì nó sẽ trông như thế nào? "user_ ware" hoặc có thể là một cái gì đó như "rel_user_ ware"? Và nếu là cái đầu tiên, cái gì sẽ phân biệt cái này, ví dụ "user_product"?

Bất kỳ trợ giúp đều được đánh giá cao và nếu có một số loại tiêu chuẩn quy ước đặt tên ngoài kia mà các bạn đề nghị, hãy liên kết.

Cảm ơn

Bảng • Tên

số ít học gần đây là chính xác

Đúng. Cẩn thận với những người ngoại đạo. Số nhiều trong tên bảng là một dấu hiệu chắc chắn của một người chưa đọc bất kỳ tài liệu tiêu chuẩn nào và không có kiến ​​thức về lý thuyết cơ sở dữ liệu.

Một số điều tuyệt vời về Tiêu chuẩn là:

• tất cả chúng được tích hợp với nhau
• Họ làm việc cùng nhau
• chúng được viết bởi những bộ óc lớn hơn chúng ta, vì vậy chúng ta không phải tranh luận về chúng.

Tên bảng tiêu chuẩn đề cập đến từng hàng trong bảng, được sử dụng trong tất cả các phiên bản, không phải toàn bộ nội dung của bảng (chúng tôi biết rằng Customerbảng chứa tất cả các Khách hàng).

Mối quan hệ, cụm động từ

Trong Cơ sở dữ liệu quan hệ chính hãng đã được mô hình hóa (trái ngược với Hệ thống lưu trữ hồ sơ trước năm 1970 [đặc trưng Record IDsđược triển khai trong bộ chứa cơ sở dữ liệu SQL để thuận tiện):

• các bảng là Chủ đề của cơ sở dữ liệu, do đó chúng là danh từ , một lần nữa, số ít
• các mối quan hệ giữa các bảng là các Hành động diễn ra giữa các danh từ, do đó chúng là các động từ (nghĩa là chúng không được đánh số hoặc đặt tên tùy ý)
• đó là vị ngữ
• tất cả những gì có thể được đọc trực tiếp từ mô hình dữ liệu (tham khảo ví dụ của tôi ở cuối)
• (Vị ngữ dành cho một bảng độc lập (cha mẹ nhiều nhất trong một hệ thống phân cấp) là nó độc lập)
• do đó, Cụm động từ được chọn cẩn thận, sao cho đó là cụm từ có ý nghĩa nhất và tránh các thuật ngữ chung chung (điều này trở nên dễ dàng hơn với kinh nghiệm). Cụm động từ rất quan trọng trong quá trình lập mô hình vì nó hỗ trợ giải quyết mô hình, tức là. làm rõ các mối quan hệ, xác định lỗi và sửa tên bảng.

Sơ đồ_A

Tất nhiên, mối quan hệ được triển khai trong SQL dưới dạng CONSTRAINT FOREIGN KEYtrong bảng con (nhiều hơn, sau này). Đây là Cụm động từ (trong mô hình), Vị ngữ mà nó đại diện (được đọc từ mô hình) và Tên ràng buộc FK :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Bảng • Ngôn ngữ

Tuy nhiên, khi mô tả bảng, đặc biệt là ngôn ngữ kỹ thuật như Vị ngữ hoặc tài liệu khác, hãy sử dụng số ít và số nhiều như tự nhiên trong ngôn ngữ tiếng Anh. Hãy ghi nhớ bảng được đặt tên cho một hàng đơn (quan hệ) và ngôn ngữ đề cập đến từng hàng xuất phát (quan hệ xuất phát):

    Each Customer initiates zero-to-many SalesOrders

không phải

    Customers have zero-to-many SalesOrders 

Vì vậy, nếu tôi có một bảng "người dùng" và sau đó tôi có các sản phẩm mà chỉ người dùng mới có, thì bảng đó có nên được đặt tên là "sản phẩm người dùng" hay chỉ là "sản phẩm"? Đây là một mối quan hệ một đến nhiều.

(Đó không phải là câu hỏi quy ước đặt tên; đó là câu hỏi thiết kế db.) Không thành vấn đề nếu user::productlà 1 :: n. Vấn đề là liệu có phải productlà một thực thể riêng biệt hay không và đó có phải là Bảng độc lập hay không . nó có thể tự tồn tại Do đó product, không user_product.

Và nếu productchỉ tồn tại trong bối cảnh của một user, tức là. nó là một bảng phụ thuộc , do đó user_product.

Sơ đồ_B

Và hơn nữa, nếu tôi có (vì một số lý do) một số mô tả sản phẩm cho mỗi sản phẩm, thì đó sẽ là "mô tả sản phẩm người dùng" hay "mô tả sản phẩm" hay chỉ là "mô tả"? Tất nhiên với các khóa ngoại đúng được đặt .. Đặt tên mô tả chỉ có vấn đề vì tôi cũng có thể có mô tả người dùng hoặc mô tả tài khoản hoặc bất cứ điều gì.

Đúng rồi. Hoặc là user_product_descriptionxor product_descriptionsẽ đúng, dựa trên những điều trên. Nó không phải là để phân biệt nó với cái khác xxxx_descriptions, mà là để cho cái tên có ý nghĩa về nơi nó thuộc về, tiền tố là bảng cha.

Thế còn nếu tôi muốn một bảng quan hệ thuần túy (nhiều đến nhiều) chỉ với hai cột, thì nó sẽ trông như thế nào? "Công cụ người dùng" hoặc có thể là một cái gì đó như "công cụ người dùng"? Và nếu là cái đầu tiên, cái gì sẽ phân biệt cái này, ví dụ "sản phẩm người dùng"?

1. Hy vọng rằng tất cả các bảng trong cơ sở dữ liệu quan hệ là các bảng quan hệ, chuẩn hóa thuần túy. Không cần phải xác định rằng trong tên (nếu không tất cả các bảng sẽ được rel_something).

2. Nếu nó chỉ chứa PK của hai cha mẹ (giải quyết mối quan hệ logic n :: n không tồn tại dưới dạng thực thể ở cấp logic, vào bảng vật lý ), thì đó là Bảng kết hợp . Có, thông thường tên là sự kết hợp của hai tên bảng cha.

   • Lưu ý rằng đó là những trường hợp như vậy, Cụm động từ áp dụng cho và được đọc là, từ cha mẹ sang cha mẹ, bỏ qua bảng con, vì mục đích duy nhất của nó trong cuộc sống là liên quan đến hai cha mẹ.

     Sơ đồ_C

   • Nếu nó không phải là Bảng kết hợp (nghĩa là ngoài hai PK, nó chứa dữ liệu), sau đó đặt tên cho nó một cách thích hợp và Cụm động từ áp dụng cho nó, không phải là cha mẹ ở cuối mối quan hệ.

     Sơ đồ_D

3. Nếu bạn kết thúc với hai user_productbảng, thì đó là một tín hiệu rất lớn rằng bạn chưa chuẩn hóa dữ liệu. Vì vậy, quay trở lại một vài bước và làm điều đó, và đặt tên cho các bảng chính xác và nhất quán. Các tên sau đó sẽ tự giải quyết.

Quy ước đặt tên

Bất kỳ trợ giúp đều được đánh giá cao và nếu có một số loại tiêu chuẩn quy ước đặt tên ngoài kia mà các bạn đề nghị, hãy liên kết.

Những gì bạn đang làm là rất quan trọng, và nó sẽ ảnh hưởng đến sự dễ sử dụng và hiểu biết ở mọi cấp độ. Vì vậy, thật tốt khi có được sự hiểu biết nhiều nhất có thể ngay từ đầu. Sự liên quan của hầu hết những điều này sẽ không rõ ràng, cho đến khi bạn bắt đầu viết mã bằng SQL.

1. Trường hợp là mục đầu tiên để giải quyết. Tất cả các mũ là không thể chấp nhận. Trường hợp hỗn hợp là bình thường, đặc biệt là nếu các bảng có thể truy cập trực tiếp bởi người dùng. Tham khảo các mô hình dữ liệu của tôi. Lưu ý rằng khi người tìm kiếm đang sử dụng một số NonQuery bị mất trí nhớ, chỉ có chữ thường, tôi cho rằng, trong trường hợp đó tôi bao gồm cả dấu gạch dưới (theo ví dụ của bạn).

2. Duy trì trọng tâm dữ liệu , không phải tập trung vào ứng dụng hoặc sử dụng. Đó là, sau tất cả năm 2011, chúng tôi đã có Kiến trúc mở từ năm 1984 và cơ sở dữ liệu được cho là độc lập với các ứng dụng sử dụng chúng.

   Theo cách đó, khi chúng phát triển và hơn một ứng dụng sử dụng chúng, việc đặt tên sẽ vẫn có ý nghĩa và không cần chỉnh sửa. (Cơ sở dữ liệu được nhúng hoàn toàn trong một ứng dụng không phải là cơ sở dữ liệu.) Chỉ đặt tên cho các thành phần dữ liệu là dữ liệu.

3. Hãy thật chu đáo, và đặt tên bảng và cột rất chính xác . Không sử dụng UpdatedDatenếu nó là một DATETIMEkiểu dữ liệu, sử dụng UpdatedDtm. Không sử dụng _descriptionnếu nó chứa một liều lượng.

4. Điều quan trọng là phải nhất quán trên cơ sở dữ liệu. Không sử dụng NumProductở một nơi để chỉ số lượng Sản phẩm và ItemNohoặc ItemNumở một nơi khác để chỉ số lượng Sản phẩm. Sử dụng NumSomethingcho số-và, SomethingNohoặc SomethingIdcho định danh, nhất quán.

5. Không đặt tiền tố tên cột bằng tên bảng hoặc mã ngắn, chẳng hạn như user_first_name. SQL đã cung cấp cho tablename như một vòng loại:

       table_name.column_name  -- notice the dot
   

6. Ngoại lệ:

   • Ngoại lệ đầu tiên là cho các PK, chúng cần xử lý đặc biệt vì bạn mã hóa chúng trong các phép nối, mọi lúc và bạn muốn các khóa nổi bật khỏi các cột dữ liệu. Luôn luôn sử dụng user_id, không bao giờ id.

     • Lưu ý rằng đây không phải là tên bảng được sử dụng làm tiền tố, mà là tên mô tả phù hợp cho thành phần của khóa: user_idlà cột xác định người dùng, không phải idlà userbảng.
       • (Tất nhiên ngoại trừ trong các hệ thống lưu trữ hồ sơ, nơi các tệp được truy cập bởi người thay thế và không có khóa quan hệ, chúng có một và cùng một thứ).
     • Luôn sử dụng cùng tên chính xác cho cột khóa bất cứ nơi nào PK được mang (di chuyển) dưới dạng FK.
     • Do đó, user_productbảng sẽ có user_idmột thành phần của PK (user_id, product_no).
     • sự liên quan của điều này sẽ trở nên rõ ràng khi bạn bắt đầu viết mã. Đầu tiên, với một idtrên nhiều bảng, thật dễ dàng bị lẫn lộn trong mã hóa SQL. Thứ hai, bất cứ ai khác mà lập trình viên ban đầu không biết anh ta đang cố gắng làm gì. Cả hai đều dễ dàng ngăn chặn, nếu các cột chính được xử lý như trên.

   • Ngoại lệ thứ hai là nơi có nhiều hơn một FK tham chiếu cùng một bảng bảng cha, được mang trong đứa trẻ. Theo Mô hình quan hệ , sử dụng Tên vai trò để phân biệt ý nghĩa hoặc cách sử dụng, ví dụ: AssemblyCodevà ComponentCodecho hai PartCodes. Và trong trường hợp đó, không sử dụng không phân biệt PartCodecho một trong số họ. Chính xác.

     Sơ đồ_E

7. Tiền tố
   Nơi bạn có nhiều hơn 100 bảng, tiền tố tên bảng với Vùng chủ đề:

   REF_cho các bảng tham chiếu
   OE_cho cụm mục nhập đơn hàng, v.v.

   Chỉ ở cấp độ vật lý, không logic (nó làm mờ mô hình).

8. Hậu tố
   Không bao giờ sử dụng hậu tố trên bảng và luôn sử dụng hậu tố trên mọi thứ khác. Điều đó có nghĩa là trong cơ sở dữ liệu hợp lý, sử dụng bình thường, không có dấu gạch dưới; nhưng về mặt hành chính, dấu gạch dưới được sử dụng như một dấu phân cách:

   _VXem (với khóa chính TableNameở phía trước, tất nhiên)
   _fkKhóa ngoài (tên ràng buộc, không phải tên cột) Giao dịch phân đoạn
   _cacbộ
   _segđệm
   _tr(lưu trữ hoặc chức năng được lưu trữ)
   _fnChức năng (không giao dịch), v.v.

   Định dạng là tên bảng hoặc tên FK, dấu gạch dưới và tên hành động, dấu gạch dưới và cuối cùng là hậu tố.

   Điều này thực sự quan trọng vì khi máy chủ cung cấp cho bạn thông báo lỗi:

   ____blah blah blah error on object_name

   bạn biết chính xác đối tượng nào đã bị vi phạm và những gì nó đang cố gắng thực hiện:

   ____blah blah blah error on Customer_Add_tr

9. Khóa ngoại (ràng buộc, không phải cột). Cách đặt tên tốt nhất cho FK là sử dụng Cụm động từ (trừ "mỗi" và số lượng thẻ).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Sử dụng Parent_Child_fktrình tự, không phải Child_Parent_fklà vì (a) nó hiển thị theo thứ tự đúng khi bạn tìm chúng và (b) chúng tôi luôn biết đứa trẻ có liên quan, những gì chúng tôi đoán là, cha mẹ nào. Thông báo lỗi sau đó rất thú vị:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   Điều đó hoạt động tốt cho những người bận tâm mô hình hóa dữ liệu của họ, nơi các Cụm động từ đã được xác định. Đối với phần còn lại, các hệ thống nộp hồ sơ, vv, sử dụng Parent_Child_fk.

10. Các chỉ số là đặc biệt, vì vậy chúng có một quy ước đặt tên của riêng chúng, được tạo thành, theo thứ tự , mỗi vị trí ký tự từ 1 đến 3:

    UDuy nhất hoặc _cho phân cụm Không duy nhất
    Choặc _cho
    _phân cách không phân cụm

    Đối với phần còn lại:

    • Nếu khóa là một cột hoặc rất ít cột:
      ____ColumnNames

    • Nếu khóa nhiều hơn một vài cột:
      ____ PKKhóa chính (theo mô hình)
      ____ AK[*n*]Khóa thay thế (thuật ngữ IDEF1X)

    Lưu ý rằng tên bảng không bắt buộc trong tên chỉ mục, vì nó luôn hiển thị dưới dạngtable_name.index_name.

    Vì vậy, khi Customer.UC_CustomerIdhoặc Product.U__AKxuất hiện trong một thông báo lỗi, nó cho bạn biết điều gì đó có ý nghĩa. Khi bạn nhìn vào các chỉ số trên bàn, bạn có thể phân biệt chúng dễ dàng.

11. Tìm ai đó có trình độ và chuyên nghiệp và làm theo họ. Nhìn vào thiết kế của họ, và nghiên cứu kỹ các quy ước đặt tên mà họ sử dụng. Hỏi họ những câu hỏi cụ thể về bất cứ điều gì bạn không hiểu. Ngược lại, chạy như địa ngục từ bất cứ ai thể hiện ít quan tâm đến việc đặt tên cho các quy ước hoặc tiêu chuẩn. Đây là một vài để giúp bạn bắt đầu:

    • Chúng chứa các ví dụ thực tế của tất cả các bên trên. Đặt câu hỏi đặt lại câu hỏi trong chủ đề này.
    • Tất nhiên, các mô hình thực hiện một số Tiêu chuẩn khác , ngoài các quy ước đặt tên; bây giờ bạn có thể bỏ qua những câu hỏi đó hoặc thoải mái đặt câu hỏi mới cụ thể .
    • Chúng là một vài trang mỗi trang, hỗ trợ hình ảnh nội tuyến tại Stack Overflow dành cho các loài chim và chúng không tải liên tục trên các trình duyệt khác nhau; Vì vậy, bạn sẽ phải nhấp vào liên kết.
    • Lưu ý rằng các tệp PDF có điều hướng đầy đủ, vì vậy hãy nhấp vào các nút kính màu xanh lam hoặc các đối tượng nơi xác định mở rộng:
    • Những độc giả không quen thuộc với Tiêu chuẩn mô hình hóa quan hệ có thể thấy Ký hiệu IDEF1X hữu ích.

Đặt hàng & hàng tồn kho với các địa chỉ tuân thủ tiêu chuẩn

Hệ thống Bản tin liên văn phòng đơn giản cho PHP / MyNonSQL

Giám sát cảm biến với khả năng tạm thời đầy đủ

Trả lời câu hỏi

^{Điều đó không thể được trả lời hợp lý trong không gian bình luận.}

Larry Lustig:
... ngay cả ví dụ tầm thường nhất cũng cho thấy ...
Nếu Khách hàng có nhiều Sản phẩm và một Sản phẩm có nhiều Thành phần và Thành phần có nhiều Nhà cung cấp và Nhà cung cấp bán không -to-many Linh kiện và SalesRep có một-nhiều Khách hàng tên "tự nhiên" mà các bảng giữ Khách hàng, Sản phẩm, Linh kiện và Nhà cung cấp là gì?

Có hai vấn đề chính trong bình luận của bạn:

1. Bạn tuyên bố ví dụ của bạn là "tầm thường nhất", tuy nhiên, đó là bất cứ điều gì nhưng. Với mâu thuẫn đó, tôi không chắc bạn có nghiêm túc không, nếu có khả năng về mặt kỹ thuật.

2. Sự đầu cơ "tầm thường" đó có một số lỗi Tổng bình thường hóa (Thiết kế DB).

   • Cho đến khi bạn sửa chúng, chúng không tự nhiên và bất thường, và chúng không có ý nghĩa gì. Bạn cũng có thể đặt tên cho chúng là bất thường_1, bất thường_2, v.v.

   • Bạn có "nhà cung cấp", những người không cung cấp bất cứ thứ gì; tài liệu tham khảo thông tư (bất hợp pháp và không cần thiết); khách hàng mua sản phẩm mà không có bất kỳ công cụ thương mại nào (như Hóa đơn hoặc SalesOrder) làm cơ sở cho việc mua hàng (hoặc khách hàng "sở hữu" sản phẩm?); mối quan hệ nhiều-nhiều-chưa giải quyết; Vân vân.

   • Khi đã được Chuẩn hóa và các bảng cần thiết được xác định, tên của chúng sẽ trở nên rõ ràng. Một cách tự nhiên.

Trong mọi trường hợp, tôi sẽ cố gắng phục vụ truy vấn của bạn. Điều đó có nghĩa là tôi sẽ phải thêm một số ý nghĩa cho nó, không biết ý của bạn là gì, vì vậy xin vui lòng chịu đựng với tôi. Các lỗi thô quá nhiều để liệt kê, và đưa ra các đặc điểm kỹ thuật dự phòng, tôi không tự tin rằng tôi đã sửa tất cả.

• Tôi sẽ giả định rằng nếu sản phẩm được tạo thành từ các thành phần, thì sản phẩm là một bộ lắp ráp và các thành phần được sử dụng trong nhiều bộ phận.

• Hơn nữa, vì "Nhà cung cấp bán từ 0 đến nhiều Thành phần", rằng họ không bán sản phẩm hoặc lắp ráp, họ chỉ bán các thành phần.

Đầu cơ so với mô hình chuẩn hóa

Trong trường hợp bạn không biết, sự khác biệt giữa góc vuông (Độc lập) và góc tròn (Phụ thuộc) là đáng kể, vui lòng tham khảo liên kết Ký hiệu IDEF1X. Tương tự như vậy, các đường liền nét (Xác định) so với các đường đứt nét (Không xác định).

... các tên "tự nhiên" mà các bảng giữ Khách hàng, Sản phẩm, Linh kiện và Nhà cung cấp là gì?

• khách hàng
• Sản phẩm
• Thành phần (Hoặc, AssociationComponent, dành cho những người nhận ra rằng một thực tế xác định thực tế khác)
• Nhà cung cấp

Bây giờ tôi đã giải quyết các bảng, tôi không hiểu vấn đề của bạn. Có lẽ bạn có thể gửi một câu hỏi cụ thể .

VoteCoffee:
Làm thế nào để bạn xử lý kịch bản Ronni được đăng trong ví dụ của anh ấy, nơi có nhiều mối quan hệ tồn tại giữa 2 bảng (user_like_product, user_b think_product)? Tôi có thể hiểu nhầm, nhưng điều này dường như dẫn đến tên bảng trùng lặp bằng cách sử dụng quy ước mà bạn đã nêu chi tiết.

Giả sử không có lỗi Chuẩn hóa, User likes Productlà một vị ngữ, không phải là bảng. Đừng nhầm lẫn chúng. Tham khảo Câu trả lời của tôi, nơi nó liên quan đến Chủ đề, Động từ và Vị ngữ và phản hồi của tôi với Larry ngay trên đây.

• Mỗi bảng chứa một bộ Sự kiện (mỗi hàng là một Sự thật). Vị ngữ (hoặc mệnh đề), không phải là Sự kiện, chúng có thể hoặc không thể đúng.

  • Các Relational Model dựa trên First Sắp xếp Predicate Calculus (thường được gọi là First Sắp xếp Logic). Vị ngữ là một câu có một mệnh đề bằng tiếng Anh đơn giản, chính xác, đánh giá là đúng hoặc sai.

  • Hơn nữa, mỗi bảng đại diện, hoặc là việc thực hiện, nhiều Vị ngữ, không phải một.

• Truy vấn là một bài kiểm tra của Vị ngữ (hoặc một số Vị ngữ, được xâu chuỗi lại với nhau) cho kết quả đúng (Sự thật tồn tại) hoặc sai (Sự thật không tồn tại).

• Do đó, các bảng phải được đặt tên, như chi tiết trong Câu trả lời của tôi (quy ước đặt tên), cho hàng, Sự thật và Vị ngữ nên được ghi lại (bằng mọi cách, nó là một phần của tài liệu cơ sở dữ liệu), nhưng là một danh sách riêng của Dự báo .

• Đây không phải là một gợi ý rằng chúng không quan trọng. Chúng rất quan trọng, nhưng tôi sẽ không viết nó lên đây.

• Nhanh chóng, sau đó. Vì Mô hình quan hệ được thành lập trên FOPC, toàn bộ cơ sở dữ liệu có thể được coi là một tập hợp các khai báo FOPC, một tập hợp các Vị ngữ. Nhưng (a) có nhiều loại Vị ngữ và (b) một bảng không đại diện cho một Vị ngữ (đó là cách triển khai vật lý của nhiều Vị ngữ và các loại Vị ngữ khác nhau ).

• Do đó, việc đặt tên cho bảng "Dự đoán rằng nó" đại diện "là một khái niệm vô lý.

• Các "nhà lý thuyết" chỉ biết đến một vài Vị ngữ, họ không hiểu rằng vì RM được thành lập trên FOL, toàn bộ cơ sở dữ liệu là một tập hợp các Vị ngữ và các loại khác nhau.

  • Và tất nhiên, họ chọn những người vô lý từ số ít mà họ biết : EXISTING_PERSON; PERSON_IS_CALLED. Nếu nó không quá buồn, nó sẽ rất vui nhộn.

  • Cũng lưu ý rằng tên bảng tiêu chuẩn hoặc nguyên tử (đặt tên hàng) hoạt động tuyệt vời cho tất cả các thông số (bao gồm tất cả các Vị ngữ được đính kèm trong bảng). Ngược lại, tên "bảng đại diện" vị ngữ không thể. Điều này tốt cho "các nhà lý luận", những người hiểu rất ít về Vị ngữ, nhưng lại chậm nói.

• Các Vị ngữ có liên quan đến mô hình dữ liệu, được thể hiện trong mô hình, chúng có hai thứ tự.

  1. Vị ngữ
     đầu tiên Tập đầu tiên là sơ đồ , không phải văn bản: bản thân ký hiệu . Chúng bao gồm nhiều tồn tại khác nhau; Định hướng hạn chế; và Mô tả (thuộc tính) Vị ngữ.

     • Tất nhiên, điều đó có nghĩa là chỉ những người có thể 'đọc' một mô hình dữ liệu Tiêu chuẩn mới có thể đọc các Vị ngữ đó. Đó là lý do tại sao các "nhà lý thuyết", những người bị tê liệt nghiêm trọng bởi tư duy chỉ có văn bản của họ, không thể đọc các mô hình dữ liệu, tại sao họ dính vào tư duy chỉ văn bản trước năm 1984 của họ.

  2. Dự đoán nhị phân
     Tập thứ hai là những người hình thành mối quan hệ giữa các Sự kiện. Đây là dòng quan hệ. Cụm động từ (chi tiết ở trên) xác định Vị ngữ, mệnh đề , đã được triển khai (có thể được kiểm tra thông qua truy vấn). Người ta không thể có được rõ ràng hơn thế.

     • Do đó, đối với một người thông thạo các mô hình dữ liệu Tiêu chuẩn, tất cả các Vị ngữ có liên quan , đều được ghi lại trong mô hình. Họ không cần một danh sách Dự đoán riêng biệt (nhưng người dùng, những người không thể 'đọc' mọi thứ từ mô hình dữ liệu, hãy làm!).

• Đây là một Mô hình Dữ liệu , nơi tôi đã liệt kê các Vị ngữ. Tôi đã chọn ví dụ đó bởi vì nó hiển thị Hiện tại, v.v., Vị ngữ, cũng như các Mối quan hệ, các Vị ngữ duy nhất không được liệt kê là Mô tả. Ở đây, do trình độ học tập của người tìm kiếm, tôi đang coi anh ta như một người dùng.

Do đó, sự kiện có nhiều hơn một bảng con giữa hai bảng cha không phải là vấn đề, chỉ cần đặt tên chúng là Sự thật Hiện sinh là nội dung của chúng và chuẩn hóa tên.

Các quy tắc tôi đưa ra cho Cụm động từ cho tên mối quan hệ cho Bảng kết hợp được sử dụng ở đây. Dưới đây là một cuộc thảo luận Vị ngữ và Bảng , bao gồm tất cả các điểm được đề cập, tóm tắt.

Để có một mô tả ngắn gọn, hãy sử dụng lại các Vị ngữ thích hợp và cách sử dụng chúng (đó là một bối cảnh hoàn toàn khác với cách trả lời các bình luận ở đây), truy cập câu trả lời này và cuộn xuống phần Vị ngữ .

Charles Burns:
Theo trình tự, tôi có nghĩa là đối tượng kiểu Oracle hoàn toàn được sử dụng để lưu trữ một số và tiếp theo theo quy tắc nào đó (ví dụ: "thêm 1"). Do Oracle thiếu các bảng ID tự động, nên cách sử dụng thông thường của tôi là tạo ID duy nhất cho PK bảng. XÁC NHẬN VÀO foo (id, somedata) GIÁ TRỊ (foo_s.nextval, "dữ liệu" ...)

Ok, đó là những gì chúng ta gọi là bảng Key hoặc NextKey. Đặt tên như vậy. Nếu bạn có SubjectAreas, hãy sử dụng COM_NextKey để chỉ ra nó phổ biến trên cơ sở dữ liệu.

Btw, đó là một phương pháp tạo khóa rất kém. Không thể mở rộng được, nhưng với hiệu suất của Oracle, có lẽ nó "ổn". Hơn nữa, nó chỉ ra rằng cơ sở dữ liệu của bạn có đầy đủ các đại diện thay thế, không liên quan trong các lĩnh vực đó. Có nghĩa là hiệu suất cực kỳ kém và thiếu tính toàn vẹn.

Số ít so với số nhiều: Chọn một và gắn bó với nó.

Các cột không nên được thêm tiền tố / hậu tố / được trộn hoặc trong bất kỳ cách nào được cố định với các tham chiếu đến thực tế rằng đó là một cột. Các bảng cũng vậy. Không đặt tên bảng EMPLOYEE_T hoặc TBL_EMPLOYEES vì bảng thứ hai được thay thế bằng chế độ xem, mọi thứ trở nên thực sự khó hiểu.

Không nhúng thông tin loại trong tên, chẳng hạn như "vc_firstname" cho varchar hoặc "flavour_enum". Đồng thời, không nhúng các ràng buộc trong tên cột, chẳng hạn như "cục_fk" hoặc "worker_pk".

Trên thực tế, điều duy nhất tốt về * sửa lỗi tôi có thể nghĩ ra, là bạn có thể sử dụng các từ dành riêng như where_t, tbl_order, user_vw. Tất nhiên, trong những ví dụ đó, sử dụng số nhiều sẽ giải quyết được vấn đề :)

Không đặt tên cho tất cả các khóa "ID". Các khóa tham chiếu đến cùng một thứ, nên có cùng tên trong tất cả các bảng. Cột id người dùng có thể được gọi là USER_ID trong bảng người dùng và tất cả các bảng tham chiếu người dùng. Lần duy nhất nó được đổi tên là khi những người dùng khác nhau đang đóng các vai trò khác nhau, chẳng hạn như Message (sender_user_id, receive_user_id). Điều này thực sự có ích khi xử lý các truy vấn lớn hơn.

Về CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

Nói chung, tốt hơn là đặt tên "bảng ánh xạ" để phù hợp với mối quan hệ mà nó mô tả thay vì tên của các bảng được tham chiếu. Một người sử dụng có thể có bất kỳ số lượng các mối quan hệ với các sản phẩm: user_likes_product, user_bought_product, user_wants_to_buy_product.

Không có "chính xác" về số ít so với số nhiều - chủ yếu là vấn đề của hương vị.

Nó phụ thuộc một phần vào sự tập trung của bạn. Nếu bạn nghĩ bảng là một đơn vị, nó chứa 'số nhiều' (vì nó chứa nhiều hàng - vì vậy một tên số nhiều là phù hợp). Nếu bạn nghĩ tên bảng là xác định một hàng trong bảng, bạn sẽ thích 'số ít'. Điều này có nghĩa là SQL của bạn sẽ được coi là hoạt động trên một hàng từ bảng. Điều đó ổn, mặc dù nó thường là một sự đơn giản hóa; SQL hoạt động trên các tập hợp (nhiều hơn hoặc ít hơn). Tuy nhiên, chúng ta có thể đi với số ít cho câu trả lời cho câu hỏi này.

1. Vì có thể bạn sẽ cần một bảng 'người dùng', một 'sản phẩm' khác và thứ ba để kết nối người dùng với các sản phẩm, sau đó bạn cần một bảng 'user_product'.

2. Vì mô tả áp dụng cho một sản phẩm, bạn sẽ sử dụng 'sản phẩm mô tả'. Trừ khi mỗi người dùng tự đặt tên cho từng sản phẩm ...

3. Bảng 'user_product' là (hoặc có thể) là một ví dụ về bảng có ID sản phẩm và ID người dùng và không nhiều thứ khác. Bạn đặt tên cho các bảng hai thuộc tính theo cùng một cách chung: 'user_ ware'. Các tiền tố trang trí như 'rel_' không thực sự hữu ích. Chẳng hạn, bạn sẽ thấy một số người sử dụng 't_' trước mỗi tên bảng. Đó không phải là rất nhiều sự giúp đỡ.

Số nhiều không tệ miễn là chúng được sử dụng một cách nhất quán - nhưng số ít là sở thích của tôi.

Tôi sẽ phân phối với các dấu gạch dưới trừ khi bạn muốn phác thảo một mối quan hệ nhiều-nhiều; và sử dụng vốn ban đầu vì nó giúp phân biệt mọi thứ trong ORM.

Nhưng có nhiều quy ước đặt tên, vì vậy nếu bạn muốn sử dụng dấu gạch dưới thì không sao, miễn là nó được thực hiện một cách nhất quán.

Vì thế:

User

UserProduct (it is a users products after all)

Nếu chỉ có một người dùng có thể có bất kỳ sản phẩm nào thì

UserProductDescription

Nhưng nếu sản phẩm được chia sẻ bởi người dùng:

ProductDescription

Nếu bạn lưu dấu gạch dưới của mình cho các mối quan hệ nhiều-nhiều, bạn có thể làm một cái gì đó như:

UserProduct_Stuff

để tạo thành một M-to-M giữa Người dùng và Nội dung - không chắc chắn từ câu hỏi về bản chất chính xác của nhiều yêu cầu nhiều.

Không có gì chính xác hơn để sử dụng số ít hơn dạng số nhiều, bạn đã nghe điều đó ở đâu? Tôi muốn nói rằng hình thức số nhiều là phổ biến hơn để đặt tên các bảng cơ sở dữ liệu ... và theo tôi cũng logic hơn. Bảng thường chứa nhiều hơn một hàng;) Trong một mô hình khái niệm mặc dù tên của các thực thể thường ở dạng số ít.

Về câu hỏi của bạn, nếu 'Sản phẩm' và 'Mô tả sản phẩm' là các khái niệm có nhận dạng (nghĩa là các thực thể) trong mô hình của bạn, tôi chỉ cần gọi các bảng là 'Sản phẩm' và 'Mô tả sản phẩm'. Đối với các bảng được sử dụng để thực hiện mối quan hệ nhiều-nhiều, tôi thường sử dụng quy ước đặt tên "SideA2SideB", ví dụ: "Student2Cference".