Tôi đang xem một số video Brent Ozar ( ví dụ như video này ) và anh ấy đề nghị không nên thêm tiền tố vào các bảng có ‘tbl’hoặc ‘TBL’.

Trên internet tôi thấy một số blog nói rằng nó không thêm gì vào tài liệu, và cũng mất thời gian để đọc nó.

Câu hỏi và cân nhắc

• Nó thực sự là một vấn đề? Bởi vì tôi đang tiền tố các bảng với 'tbl' kể từ công việc dba đầu tiên của tôi (DBA cấp cao bảo tôi làm điều đó cho tổ chức).
• Đây có phải là một cái gì đó mà tôi cần phải thoát khỏi? Tôi đã thực hiện một số thử nghiệm, sao chép một bảng thực sự lớn và đặt tiền tố 'tbl', trong khi vẫn giữ một bảng khác mà không có nó và tôi không nhận thấy bất kỳ vấn đề nào về hiệu suất.

Tôi đã từng có một cái bàn và nó sáng bóng và đẹp. Nó tổ chức tất cả các giao dịch tài chính cho một tổ chức. Và sau đó chúng tôi bắt đầu tải dữ liệu vào nó.

Trong tháng hiện tại, họ có thể nêu và phục hồi các giá trị bao nhiêu lần tùy ý. Trong 10 ngày cuối cùng của tháng, họ sẽ lập lại các số -> chạy xử lý ETL -> xem xét các báo cáo nhiều lần trong ngày. Khi tháng hoàn thành, các cuốn sách sẽ được niêm phong và chúng không thể sửa đổi các giá trị.

Thật đáng kinh ngạc khi có bao nhiêu dữ liệu tài chính mà một công ty dịch vụ tài chính tạo ra ... Một điều chúng tôi không nhận ra với bộ dữ liệu thử nghiệm của mình là khối lượng dữ liệu sẽ làm cho các thủ tục cuối tháng của họ không thể thực hiện được. Phải mất một thời gian ngày càng dài để xóa "dữ liệu của tháng hiện tại" trước khi thay thế nó bằng lần chạy thử mới.

Chúng tôi đã phải làm một cái gì đó để làm cho nó nhanh hơn để xử lý mà không phá vỡ danh sách "những người biết những gì" mà tất cả phụ thuộc vào bảng WeeklyAllocation. Tôi quyết định chơi ảo thuật gia và quất chiếc khăn trải bàn từ bên dưới chúng. Tôi đã đi học cũ và sử dụng Chế độ xem phân vùng . Dữ liệu đã có cờ IsComplete nên tôi đã tạo hai bảng - mỗi bảng có các ràng buộc kiểm tra trái ngược nhau: Hàng tháng AllocationComplete, Weekly AllocationInComplete

Sau đó, tôi đã tạo chế độ xem được phân vùng có cùng tên với bảng gốc: Weekly Allocation. Không có quá trình nào là khôn ngoan hơn về sự thay đổi vật lý mà chúng ta đã thực hiện đối với cơ sở dữ liệu. Không có báo cáo nào bị phá vỡ, không có nhà phân tích nào có quyền truy cập trực tiếp báo cáo bất kỳ vấn đề nào với "bảng" đó trước hoặc sau đó.

Câu chuyện tuyệt vời bro, nhưng bạn đi đâu?

Điều gì xảy ra nếu họ có một quy ước đặt tên ở đó, tbl_Monthly Allocation? Giờ thì sao? Chúng ta có dành nhiều giờ làm việc cho mọi ETL, mọi báo cáo, mọi bảng tính đặc biệt trong tổ chức và cập nhật chúng để sử dụng vw_Monthly Allocation không? Và dĩ nhiên, tất cả những thay đổi đó đều thông qua Bảng thay đổi và đó luôn là một quá trình nhanh chóng và không đau đớn.

Ông chủ của bạn có thể hỏi: phần thưởng cho công ty là gì cho tất cả những công việc đó một lần nữa?

Tùy chọn khác trở thành chúng tôi để chế độ xem này được đặt tên là tbl_ và không dành toàn bộ thời gian đó để kiểm tra, cập nhật và triển khai mã. Điều này trở thành một giai thoại thú vị mà bạn giải thích cho tất cả các nhân viên mới và những người có thời gian chú ý ngắn, phải làm việc với cơ sở dữ liệu về lý do tại sao bạn không phù hợp với việc đặt tên các đối tượng

Hoặc bạn không mã hóa hai đối tượng bằng siêu dữ liệu dự phòng. Cơ sở dữ liệu sẽ vui vẻ cho bạn biết bảng là gì, chế độ xem là gì, chức năng có giá trị của bảng là gì, v.v.

Các quy ước đặt tên là tốt, chỉ cần đừng vẽ mình vào một góc với chúng.

Brent ở đây (anh chàng mà bạn đang đề cập đến trong câu hỏi).

Lý do tôi nói với bạn là không thêm tbl vào phía trước tên bảng của bạn cũng chính là lý do tôi nói không nên thêm con vào phía trước tên của con bạn. Bạn đừng gọi họ là childJohn và childJane. Nó không chỉ không thêm bất kỳ giá trị nào, chúng có thể không phải là một đứa trẻ sau này trong cuộc sống - và các đối tượng của bạn sau này có thể trở thành quan điểm.

Đây là một lập luận rất chủ quan, nhưng đây là ý kiến ​​của tôi: tiền tố tbl là vô dụng.

Có bao nhiêu kịch bản bạn đang xem mã và bạn không thể biết nếu một cái gì đó là một cái bàn hay cái gì khác?

Giá trị nào mà tbl thêm vào ngoại trừ khi bạn xem danh sách các bảng trong Object Explorer, bạn phải thực hiện nhiều công việc hơn để tìm (các) bảng bạn đang tìm kiếm?

Một số người nói rằng họ muốn mã này rõ ràng khi họ đang xử lý một bảng hoặc một khung nhìn. Tại sao? Và nếu điều này là rất quan trọng, tại sao không chỉ đặt tên cho quan điểm một cách đặc biệt? Trong hầu hết các trường hợp, chúng hoạt động giống như các bảng, vì vậy tôi thấy rất ít giá trị trong việc phân biệt.

Đó là một thực tế khủng khiếp.

tbl
tbl_
Table_
t_

... Đã thấy tất cả trong sản xuất.

Một trong những sản phẩm tôi hiện đang làm việc có một nửa số bảng được đặt tên tbl_whatevervà nửa còn lại có tên "bình thường" - Rõ ràng là họ đã có các nhà phát triển đang làm việc theo các tiêu chuẩn khác nhau. Một trong những thói quen xấu khác của họ là tiền tố tên cột là khóa ngoại fk, theo sau là tên bảng, fksau đó là tên cột, đặt tên cột khủng khiếp như vậy fktbl_AlarmsfkAlarmsID. Quy ước đặt tên đó chỉ là một phần mở rộng hợp lý của toàn bộ tbl_%câu thần chú, và bạn có thể thấy nó thật lố bịch!

Tôi gần như quên mất cơ sở dữ liệu khác khiến tôi khóc hàng ngày. Các kiểu dữ liệu tiền tố tên cột ... dtPaymentDate, vì tên thực sự cần dttiền tố? `

comDon verListen PrepTo adjThose adjOther nouP People. proYou auxShould advAlways verUse nouPrefixes PrepWith proYour adjTable nouNames. proI auxHave advEven verStarted gerSử dụng proThem PrepIn adjN normal nouWriting.

comSee advHow adjEffective proIt verIs? nouP People auxCan verUnderstand proYour nouWriting adjBetter!

Sử dụng một tiền tố như thế này được gọi là Ký hiệu Hungary . Tiền đề của nó rất đơn giản: bạn có thể xác định thứ gì đó bằng cách đặt tên. Điều này đặc biệt phổ biến trong các ngôn ngữ lập trình, đặc biệt là khi các nhà phát triển viết các hàm nguyên khối trải dài hàng chục trang, do thiếu kỹ năng hoặc thiếu các tính năng ngôn ngữ. Đó là một trợ giúp ghi nhớ giúp các nhà phát triển giữ các kiểu dữ liệu thẳng.

Nói chung, phong cách đặt tên này có thể sẽ được sử dụng trong mã thực sự cũ hoặc bởi các nhà phát triển vừa học (vừa tình cờ học thói quen này), hoặc đã thực hiện nó miễn là họ có thể nhớ. Theo kinh nghiệm của tôi, tôi đã nhận thấy rằng việc thấy các ký hiệu Hungary xuất hiện một cách tự nhiên với các nhà phát triển thiếu kinh nghiệm là điều tương đối hiếm khi họ không được giới thiệu về nó bởi một khóa học hoặc hướng dẫn lập trình; họ có nhiều khả năng sử dụng các tên biến như i hoặc x hoặc acct .

Bên cạnh việc vẽ mình vào một góc, đây thực sự chỉ là phụ. Cú pháp SQL đủ chính xác để nhà phát triển phải luôn biết nếu họ đang nói về một trường, bản ghi hoặc tập dữ liệu (có thể là bảng, dạng xem, v.v.). Mặc dù nó có thể tạo ra một trợ giúp giảng dạy tuyệt vời, cú pháp này thường không nên tồn tại trong cơ sở dữ liệu sản xuất. Nó có thể gây hại cho mức độ dễ đọc và khiến việc tìm bảng bạn đang tìm kiếm trở nên khó khăn hơn, đặc biệt là nếu một số chủ đề đặt tên thay thế bật lên, như tbl so với bảng so với tab , v.v.

Cơ sở dữ liệu không thực sự quan tâm những gì bạn gọi là bảng, trường, v.v. Chúng chỉ là các byte dữ liệu được sắp xếp theo thứ tự cụ thể bởi các toán tử hoặc tập lệnh con người của chúng. Tuy nhiên, những người phải duy trì dữ liệu này sẽ đánh giá cao những cái tên có ý nghĩa, như "người dùng", "đặt hàng" và "tài khoản". Sẽ thực tế hơn nếu bạn đang sử dụng các truy vấn SQL, như "hiển thị bảng như 'a%'". Sử dụng tiền tố và hậu tố có thể làm phức tạp một cách không cần thiết nếu không duy trì tầm thường.

Tôi đã đọc một vài bài đăng trên blog như thế này hoặc thế này (có khá nhiều) sau khi tôi thừa hưởng Sơ đồ máy chủ SQL đầu tiên của mình và nhận thấy nhiều đối tượng có tiền tố, tôi muốn bắt đầu phát triển các mục mới với cách tiếp cận ít chi tiết hơn và quy ước đặt tên đơn lẻ ( Tôi dễ dàng hơn rất nhiều để [ và có thể các nhà phát triển khác ] làm việc trên Bản đồ quan hệ đối tượng).

Một trong những tiền tố sử dụng rộng rãi nhất là Tblhay tbl, nhưng sau đó tôi đã TBLvà tbl_và thậm chí*TableName*_Tbl

Khi cố gắng truy vấn và làm việc từ Visual Studio, đây chỉ là một địa ngục, tôi sẽ không gặp vấn đề gì khi đặt toàn bộ bảng tiền tố, tblnhưng ít nhất hãy giữ nó theo cách đó cho toàn bộ Cơ sở dữ liệu.

Vì vậy, cuối cùng tôi chắc chắn sẽ nói là vấn đề sở thích cá nhân nhưng nó cũng có liên quan nhiều đến sự nhất quán và nếu bạn đi theo con đường đó, rất nhiều người sẽ vui mừng ít nhất là bạn giữ nó như vậy cùng với sự phát triển của bạn.

... Mặt khác, tôi chỉ muốn nói rằng, nếu bạn thực hiện một cách tiếp cận khác và không dùng tiền tố, bảng tên số ít bạn sẽ làm cho một nhà phát triển hạnh phúc trong tương lai, và điều gì quan trọng hơn hạnh phúc?

Có, việc thêm một tiền tố biểu thị loại đối tượng là một vấn đề và không cần thiết . Bởi vì,

1. Đôi khi các đối tượng bắt đầu cuộc sống như một cái gì đó nhưng cuối cùng sẽ trở thành một thứ khác . (ví dụ: bảng tblXxxđược chia thành tblXxxYvà tblXxxZvì một số lý do và được thay thế bằng chế độ xem tham gia hai bảng mới. Bây giờ bạn có chế độ xem được gọi tblXxx).
2. Khi bạn nhập tbltrình chỉnh sửa, tính năng AutoComplete của nó sẽ bị treo trong 45 giây và sau đó hiển thị cho bạn danh sách 4000 mục nhập.

Nhưng...

Tôi sẽ chơi trò bênh vực của quỷ và nói điều gì đó mà những người khác đã hoàn toàn khuyên ngăn. Có một số trường hợp hiếm hoi hậu tố / tiền tố có thể hữu ích và đây là một ví dụ từ tổ chức tôi làm việc.

Chúng tôi có một hệ thống ERP dựa trên thực thể, trong đó logic nghiệp vụ được viết bằng Oracle PL / SQL. Nó đã gần hai thập kỷ, nhưng là một hệ thống rất ổn định (Đây không phải là một hệ thống cũ. Chúng tôi đang tiếp tục phát triển nó).

Hệ thống này dựa trên thực thể và mỗi thực thể liên kết một bảng, nhiều khung nhìn, nhiều gói PL / SQL và một loạt các đối tượng cơ sở dữ liệu khác.

Bây giờ, chúng tôi muốn các đối tượng thuộc cùng một thực thể có cùng tên nhưng chưa thể phân biệt được mục đích và loại của nó. Vì vậy, nếu chúng ta có hai thực thể được đặt tên CustomerOrdervà CustomerInvoice, chúng ta sẽ có các đối tượng sau:

1. Bảng để lưu trữ dữ liệu [ TABhậu tố]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Lượt xem được khách hàng sử dụng [Không có hậu tố]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Giao diện cho các hoạt động cơ bản; (Gói PL / SQL) [ APIhậu tố]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Máy phát báo cáo; (Gói PL / SQL) [ RPIhậu tố]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Chỉ mục cho khóa chính [ PKhậu tố]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Chỉ số phụ [ IXhậu tố]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(nơi XXXmô tả việc sử dụng chỉ số).
7. ... và cứ thế.

Đây thực sự là một dạng Ứng dụng Hungary (lưu ý rằng cùng loại đối tượng có thể có các hậu tố khác nhau tùy thuộc vào mục đích). Nhưng, với một hậu tố thay vì tiền tố. Tôi không thể nói cho bạn đủ cách hệ thống này rất dễ đọc. IntelliSense thực sự hoạt động vì thay vì nhập TBLvà nhận 4000 kết quả, tôi có thể nhập Customervà nhận tất cả các đối tượng thuộc về các thực thể được đặt tên Customer*.

Vì vậy, ở đây tôi đã chỉ cho bạn cách siêu dữ liệu có thể hữu ích. Mục đích là để có một tập hợp các đối tượng cơ sở dữ liệu có liên quan có thể nhận dạng bằng một tên duy nhất, nhưng phân biệt chúng dựa trên mục đích của chúng .

Phải nói rằng, nếu bạn không có loại hệ thống này, sẽ không sử dụng tiền tố hoặc hậu tố loại đối tượng .

Lưu ý rằng chúng tôi đã không sử dụng hậu tố như _table, _packagehoặc _view(tức là kiểu của đối tượng). Ví dụ, cả (3) và (4) là các gói PL / SQL, nhưng sử dụng một hậu tố khác nhau. Nó giống nhau cho (5) và (6), cả hai đều là chỉ mục. Vì vậy, hậu tố dựa trên mục đích chứ không phải loại .

tl; dr Nó (rất có thể) thêm thông tin dư thừa, dẫn đến chi phí nhận thức, và do đó nên được loại bỏ.

Bối cảnh là một điều tuyệt vời, đặc biệt là trong các hệ thống máy tính. Ngoài ngữ cảnh, bạn không thể biết liệu cái gì được gọi userslà bảng, dạng xem, thủ tục được lưu trữ hay thứ gì khác hoàn toàn. Các hệ thống và ngôn ngữ kế thừa (hoặc chỉ được viết kém) thường gây khó khăn cho việc xử lý bối cảnh trong khi đọc mã. Ví dụ, trong Bash, bạn không thể biết những gì function userskhông cần ít nhất là đọc nội dung của hàm. Trong Java, Map<Uid,UserDetails> users()khá minh bạch và bạn có thể tìm hiểu chi tiết một cách dễ dàng.

Đưa đối số này vào các bảng SQL, khi nào nó sẽ hữu ích cho người tiêu dùng usersđể biết liệu đó là bảng hay dạng xem? Nói cách khác, là một tbltiền tố sẽ nói với bất kỳ người tiêu dùng một cái gì đó họ không biết và cần phải biết?Hy vọng rằng phần lớn người tiêu dùng sẽ viết các truy vấn DML và DQL chống lại nó. Đối với họ, đó chỉ là một nguồn dữ liệu khác và cho dù đó là chế độ xem hay bảng có liên quan như việc nó được phân vùng, lưu trữ trên ổ cứng hay SSD hay bất kỳ chi tiết kỹ thuật nào khác. DBA tất nhiên cần biết các chi tiết này để chạy một số truy vấn DDL / DCL hiếm, nhưng dường như phản tác dụng khi làm ô nhiễm không gian tên vì lợi ích của thiểu số người thực sự biết cách điều hướng lược đồ và nhận được tất cả các chi tiết kỹ thuật.

Một trong những tính năng của hệ thống quản lý cơ sở dữ liệu quan hệ là nó phân tách việc trình bày thông tin hợp lý cho khách hàng khỏi bộ lưu trữ vật lý. Các cựu là cột trong một hàng. Cái sau là tập tin trên một dung lượng lưu trữ. Công việc của DBMS là ánh xạ cái này sang cái khác. Nó chỉ là mối quan tâm đối với DBA hoặc sysadmin mà phần cứng đang hỗ trợ thông tin cần thiết. Người tiêu dùng không cần, thực sự không nên, nhận thức được những mối quan tâm đó.

Khách hàng cũng không nên lo lắng về cách xây dựng một hàng. Một bảng cơ sở, một khung nhìn hoặc một hàm là tất cả, về mặt này, giống hệt nhau. Mỗi đơn giản chỉ tạo ra một tập hợp các hàng và cột mà khách hàng tiêu thụ. Ngay cả một vô hướng đơn giản cũng có thể được coi là một bảng một hàng, một cột. Mô hình hàng / cột là hợp đồng giữa máy khách và máy chủ.

Bằng cách thêm tiền tố vào tên của các vật phẩm với kiểu triển khai của chúng, sự phân tách mối quan tâm này bị phá vỡ. Hiện tại khách hàng nhận thức được và phụ thuộc vào nội bộ của máy chủ. Thay đổi trong mã hóa của máy chủ có thể yêu cầu khách hàng làm việc lại.

Có rất nhiều câu trả lời ở đây mà tôi đồng ý với điều đó cho bạn biết rằng đây không phải là một quy ước đặt tên rất có giá trị. Đối với những người không bị thuyết phục bởi các câu trả lời khác, tôi sẽ cố gắng chứng minh những gì nhiều câu trả lời khác đang nói.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

Trong tuyên bố trên tôi đang chọn ba cột trong số một cái tên dbo.foo. Một trong những phàn nàn cốt lõi của tiền tố là họ không biết dbo.foolà bảng hay dạng xem. Tất nhiên đó là một trong những điểm mạnh của một quan điểm như một sự trừu tượng, nhưng tôi lạc đề. Họ nói rằng chúng ta nên thêm tiền tố vào đối tượng như thế này dbo.tblFoo. Bây giờ họ có thể thấy rằng đối tượng là một bảng (có thể) trong truy vấn trên. Tuy nhiên nếu chúng ta viết chức năng tương đương với mục tiêu đó thì nó sẽ trông như thế này.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

Tôi nghi ngờ rằng bình luận có vẻ ít hữu ích hơn mặc dù đó là những gì tiền tố đang tranh luận một cách hiệu quả. Để làm nổi bật tiếng ồn vô dụng, bình luận dữ liệu meta này xem xét một truy vấn phức tạp hơn.

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

Do các bình luận thêm làm cho truy vấn đó dễ dàng hơn để lý do hoặc họ chỉ thêm tiếng ồn? Theo tôi họ chỉ cần thêm tiếng ồn và thêm giá trị bằng không. Đó là những gì các tiền tố đang cố gắng nói. Hơn nữa, việc sử dụng tiền tố thực sự tồi tệ hơn các nhận xét đó vì chi phí cập nhật nhận xét thấp hơn nhiều so với cập nhật tên của bảng tiền tố nếu mô hình dữ liệu của bạn cần được điều chỉnh. Vì các tiền tố này có chi phí và chúng không truyền đạt thông tin có giá trị nên chúng cần tránh.

Một ưu điểm khác của tiền tố mà một số người trích dẫn là nó có thể truyền đạt một số loại nhóm hoặc thứ tự trong môi trường phát triển của bạn. Vì chúng tôi dành một lượng lớn thời gian để chỉnh sửa mã, đây có thể là một đối số quyến rũ đối với một số người. Tuy nhiên, theo kinh nghiệm của tôi, môi trường phát triển hiện đại cung cấp các tùy chọn tương đương hoặc ưu việt không làm mất mã của bạn với dữ liệu meta vô dụng và hạn chế tính linh hoạt của bạn.

Điều này đã được đề cập nhiều lần, nhưng có lẽ nổi tiếng nhất bởi Joe Celko , một chuyên gia về cơ sở dữ liệu quan hệ và SQL của Mỹ. Cá nhân tôi đã nhận được kết thúc của một trong những lời tán dương của anh ấy trên mạng (cảm thấy vinh dự), và anh ấy nói về những tiền tố này là "tibling", hay được mô tả chính xác hơn là "sự sai lệch ".

Ý tưởng chung là các tiền tố này là một thực tiễn mã hóa từ lâu (có lẽ do giới hạn đặt tên, như giới hạn 8 byte cho tên đối tượng), đã truyền lại cho các thế hệ lập trình viên không vì lý do rõ ràng hữu ích, ngoài ra nó chỉ là "cách xong rồi ".

Các công ty, blogger và lập trình viên truyền thông tin với phong cách mã hóa của riêng họ, và một số phong cách có thể hơi "Frankenstein" hơn một chút so với những người khác. Một công ty có thể có "kiểu nhà" và lập trình viên buộc phải học cách làm này.

Theo thời gian mọi thứ gắn bó, ngay cả khi lý do chúng được sử dụng ban đầu bây giờ không được chấp nhận. "Tibble" là một trong những ví dụ nổi tiếng nhất về vấn đề này trong quản lý cơ sở dữ liệu quan hệ.

Để làm tròn: nó không thêm bất kỳ giá trị nào, nó thêm chính xác 4 byte dung lượng lưu trữ vào mỗi tên bảng mà không có lý do nào khác ngoài vì nó ở đó. Nó không cung cấp gì cho các hệ thống SQL Server hiện đại, nhưng nếu nó khiến bạn cảm thấy tốt hơn khi có nó, hãy tiếp tục và sử dụng nó.

Đề nghị của tôi sẽ là bạn ngừng làm điều này ngay lập tức. Nếu điều này làm bạn khó chịu trong tương lai, hãy thêm "_tbl" vào cuối tên bảng của bạn. Tất nhiên vì những lý do đã được đề cập, cũng không cần phải làm điều đó. Người ban đầu bảo bạn làm điều đó đã cho bạn một lời khuyên tồi. Nó có thể là xấu "điều này có ý nghĩa về mặt hệ thống thiết lập tồi" của tổ chức chúng tôi, nhưng trong trường hợp đó, đó là công việc của anh ấy để khắc phục nó. Vẫn là lời khuyên tồi.

Có phải là không tiền tố các bảng của bạn với tbl không thực sự là một vấn đề?

Về hệ thống? Không. Về người khác? Có lẽ. Bạn có thể tạo ra rất nhiều sự ghét bỏ.

Cá nhân tôi không tiền tố bảng nhưng làm như vậy trên các đối tượng khác như khung nhìn, thủ tục được lưu trữ, hàm, v.v.

Tôi sẽ phải nói xin vui lòng ngừng làm điều này. Nó đã xảy ra trong quá khứ, nhưng bằng cách tiếp tục làm điều này, bạn khuyến khích những người mới vào môi trường của bạn nghĩ rằng đó là một quy ước địa phương và tiếp tục. Nhưng họ sẽ không tiếp tục, họ sẽ làm điều đó hơi khác

Khi truy tìm db cho một mục cụ thể và tôi không phải là người duy nhất sẽ mở trình thám hiểm đối tượng và chỉ nghĩ rằng tôi sẽ cuộn đến đó, bạn biết đó là bảng chữ cái. Đó là cho đến khi tiền tố bắt đầu làm vũng nước và tôi có tblname, tbl_name, tbname, t_name và hàng ngàn biến thể khác, thật khó để tìm thấy bảng mà bạn biết đã là bảng

Tương tự như vậy, tiền tố mọi thứ vw_ hoặc sp_, ai đó sẽ đến và bạn sẽ nhận được SPname, spname, s_p_name. Xóa tất cả các tiền tố, phần mềm biết mục này là gì, nếu bạn thực sự cần biết thì hãy sử dụng hậu tố thay thế. NameOfMyView_v, NameOfMyProc_sp. dễ dàng hơn nhiều để tìm kiếm trực quan

Nhưng điều gì sẽ xảy ra nếu bạn đang truy tìm một Proc được lưu trữ lâu và không thể dễ dàng biết được thế nào là một cái nhìn hay một cái bàn? Cũng có khả năng là những cái này sẽ được đặt bí danh, và ngay cả khi không phải là hậu tố để giải cứu bạn

Đừng sợ thay đổi những gì bạn làm, và nếu bạn bước vào một môi trường nơi các quy ước đặt tên đã bị bắn để không sợ thực hiện của riêng bạn, và bắt đầu thay đổi mọi thứ tốt hơn. Bằng cách kết hợp với sự hỗn loạn hiện tại, không có cơ hội làm cho nó bớt khó hiểu, chỉ làm cho nó trở nên đơn giản

Nếu tôi phải nghĩ đến một lợi thế của việc có tiền tố 'tbl', thì đó là trong SSMS hiện tại, với intellisense, tôi chỉ có thể gõ

select * from tbl

và sau đó tìm tên bảng tôi cần (giả sử tôi không biết gì về tên bảng chính xác). Đây là một công việc một bước. Tất nhiên, chúng ta luôn có thể tìm ra tên bảng thông qua các bước bổ sung, nhưng tôi nói rằng với tiền tố 'tbl', đây là bước MỘT hoạt động và đó là lý do tại sao tôi luôn thích tiền tố (không nhất thiết phải là 'tbl') trong dự án bài tập về nhà của riêng tôi.

Chỉnh sửa : (Sau rất nhiều phiếu giảm giá, tôi vẫn nghĩ rằng đáng để chỉ ra một số lợi thế thích hợp của việc đưa tiền tố cụ thể vào một danh mục cụ thể của các đối tượng trong máy chủ sql). Dường như không ai phàn nàn về việc có tiền tố cho các thủ tục / hàm / khung nhìn được lưu trữ, nhưng luôn có tranh luận về việc làm như vậy với các bảng. (Đối với tôi, trong thế giới thực, tôi không quan tâm đến việc chúng ta có đưa ra tiền tố hay không cho các bảng).

Tôi nhớ trong máy chủ sql 2005 ngày, có một yêu cầu phải tìm những bảng nào được sử dụng trong đó các thủ tục / khung nhìn được lưu trữ, với tên bảng được đặt trước, đó là một công việc dễ dàng với Biểu thức chính quy / C #. (Vâng, tôi biết có những cách khác, không có tranh luận ở đây).

Sự nghiệp của tôi phát triển với việc đọc rất nhiều bài báo / bài báo "thực tiễn tốt nhất", nhưng tôi cũng đã thấy đủ các ngoại lệ đối với hầu hết mọi "cách thực hành tốt nhất" theo cách này hay cách khác trong các tình huống khác nhau. Do đó, tôi luôn tự nhủ với bản thân và các DBA đồng nghiệp của mình, đưa ra phán đoán theo yêu cầu kinh doanh, "thực tiễn tốt nhất" có chỗ đứng chắc chắn, nhưng nó chỉ có thể được xem xét trong bối cảnh môi trường của chính chúng ta.

Xem xét dbo.Userso với dbo.tUser. Bây giờ hãy tưởng tượng bạn muốn tìm tất cả các vị trí trong mã mà bảng này được sử dụng. Phiên bản nào làm cho việc này dễ dàng hơn (hoặc thậm chí có thể?) Từ "người dùng" có thể có nhiều thông tin sai, như tên biến, trong các nhận xét, v.v.

Đó là điều tôi chưa từng thấy trong bất kỳ câu trả lời nào khác, nhưng tôi là nhà phát triển kiêm DBA, vì vậy có lẽ những người khác không phải làm việc với mã kế thừa, nơi các truy vấn có thể được nhúng trong ứng dụng chứ không phải tất cả truy vấn đủ điều kiện tham chiếu với lược đồ và những thứ tương tự. (Ngay cả khi tất cả mọi thứ là hoàn toàn đủ điều kiện, bạn cần phải tìm dbo.Uservà [dbo].[User]và dbo.[User]và vân vân). Hoặc các phiên bản cơ sở dữ liệu trong đó "thông tin phụ thuộc" cũ và không chính xác (ví dụ: các phiên bản cũ hơn của MS-SQL)

Vì vậy, đối với một số dự án tôi đã thực hiện, được trộn lẫn như vậy, tôi đã bắt buộc một thoặc vtiền tố (tbl_ trở nên ngớ ngẩn), chỉ đơn giản là biến nó thành một thuật ngữ tìm kiếm có chọn lọc hơn.

Trong các dự án sau này, với những thứ như Công cụ dữ liệu SQL Server (xin chào, Tìm tất cả tài liệu tham khảo) và truy cập cơ sở dữ liệu chỉ qua một lớp ORM, không có tiện ích nào, vì việc tìm kiếm tất cả các cách sử dụng của bảng là không quan trọng (như đổi tên nó!)

Mỗi bên đều có ưu điểm và nhược điểm của nó. Điều này tùy thuộc vào nhóm của bạn hoặc của công ty dẫn đến quyết định tuân theo các quy ước.

Chúng tôi, cho một, sử dụng tblquy ước. Lý do chính là chúng ta biết trong các kịch bản những gì chúng ta có thể và không nên làm. Chúng tôi có nhiều dự án khác nhau và những người nhảy vào không biết sơ đồ bằng trái tim. Các bảng của chúng tôi có tên logic, vì vậy thật dễ dàng để tìm đường trong khi viết tập lệnh. Trong khi làm như vậy, khi chúng tôi tìm thấy một bảng, chúng tôi biết ngay lập tức (thông qua IntelliSense) rằng đó là một bảng. Người ta có thể lập luận rằng việc thêm tiền tố không thêm nhiều ngữ cảnh. Tuy nhiên, loại bỏ nó có nghĩa là không có bối cảnh.

Ưu điểm thực sự duy nhất của việc không sử dụng tiền tố là khả năng thay thế lẫn nhau. Tuy nhiên, tôi sẽ cho rằng đây là một tình huống nguy hiểm tiềm tàng. Chắc chắn, các tập lệnh và truy vấn của bạn sẽ không bị hỏng, nhưng có lẽ bạn bắt đầu dựa vào thực tế đó quá nhiều, trong khi một số thứ không hoạt động với các khung nhìn hoặc không được khuyến khích.

Cuối cùng, nó thực sự chỉ tập trung vào những gì nhóm của bạn thích và cách nó viết mã / tập lệnh.

Tôi đã từng có một lý do để đặt tiền tố tên bảng với "tbl". Nếu bạn đang xem danh sách các đối tượng cơ sở dữ liệu, bạn có thể chạy truy vấn này:

select * from sysobjects

Nếu bạn muốn chỉ nhận các bảng, bạn có thể làm điều này:

select * from sysobjects where type = 'U'

Ai có thể nhớ điều đó? Nếu tất cả các tên bảng của bạn bắt đầu bằng "tbl", bạn có thể sử dụng truy vấn này không yêu cầu bạn ghi nhớ các giá trị của cột loại:

select * from sysobjects where name like 'tbl%'

Vì bạn đã gắn thẻ SQL Server 2014, điều này không áp dụng cho bạn vì kể từ SQL Server 2005, bạn có thể thực hiện việc này thay thế:

select * from sys.tables

Tôi không thể nghĩ ra một lý do khác cho tên bảng tiền tố.