2009-10-19 38 views
14

Gần đây tôi đã hỏi một đồng nghiệp tại sao họ đã bao gồm _TABLE ở cuối tất cả các tên bảng cơ sở dữ liệu của họ. Họ nói đó là một tiêu chuẩn tại một tổ chức khác mà họ đã làm việc cho. Các đồng nghiệp khác sử dụng V_ khi bắt đầu xem.
Đây có phải là phương pháp hay không?Đặt tên bảng và bảng cơ sở dữ liệu

Trả lời

24

Nhất quán là cách tiếp cận tốt nhất. Việc thêm một _TABLE hoặc _VIEW vào cuối một tên đối tượng là quá mức cần thiết trong cuốn sách của tôi, nhưng nếu cơ sở dữ liệu được thiết kế theo cách đó, tôi sẽ không phá vỡ quy ước.

Để đồng nghiệp của bạn mang quy ước đặt tên của mình từ tổ chức trước đó sang tổ chức mới mà không kiểm tra tiêu chuẩn 'cục bộ' là hành vi xấu.

+4

+1 cho nhận xét về quy ước đặt tên ... nó sẽ đánh bại mục đích nếu bạn kết thúc với nhiều quy ước đặt tên trong một cơ sở dữ liệu – Andomar

1

Từ http://vyaskn.tripod.com/object_naming.htm:

Có tồn tại rất nhiều quy ước đặt tên khác nhau cho các đối tượng cơ sở dữ liệu, không ai trong số họ là sai. Đó là một sở thích cá nhân của người thiết kế quy ước đặt tên. Tuy nhiên, trong một tổ chức, một người (hoặc một nhóm) xác định các quy ước đặt tên cơ sở dữ liệu, tiêu chuẩn hóa nó và những người khác sẽ làm theo nó cho dù họ có thích hay không.

Đọc full article để biết chi tiết về cách triển khai/tạo trong tổ chức của bạn.

2

Sử dụng tiền tố v_ hoặc vw_ có thể hữu ích nếu bạn đọc truy vấn SELECT thường xuyên; bạn có thể thấy nhanh chóng cho dù bạn đang chọn từ một khung nhìn hay bảng. Các khung nhìn tiền tố HOẶC các bảng postfixing là đủ, không cần cả hai. Chúng tôi sử dụng tiền tố xem.

Ngoài ra, chúng tôi sử dụng tiền tố "mô-đun" để nhóm bảng và chế độ xem xung quanh một nhóm chức năng. Ví dụ: bảng có liên quan đến thanh toán được gọi là BIL_ * và các chế độ xem có liên quan đến thanh toán VW_BIL_ *. Việc đặt tên module giữ các bảng và khung nhìn liên quan gần nhau trong SSMS.

19

Sử dụng v để xem làm tiêu chuẩn đặc biệt xấu trong mắt vì nó ngăn bạn sử dụng một trong những cách tốt nhất để tái cấu trúc cơ sở dữ liệu là đổi tên bảng và tạo chế độ xem với tên cũ giống với tên cũ cấu trúc để không có gì phá vỡ trong khi bạn đang thực hiện thay đổi nhưng bạn có thể bắt đầu tìm và sửa tất cả các tham chiếu cũ mà không phải sửa tất cả chúng trước khi thay đổi được đặt thành sản phẩm.

Tôi cũng đồng ý với ý tưởng rằng vấn đề thực sự là lấy các quy ước đặt tên từ một số tổ chức khác và bỏ qua các quy ước đặt tên của tổ chức hiện tại. Tôi sẽ dậm về điều này nhanh chóng và nhấn mạnh rằng ông thay đổi tất cả các đối tượng và mã liên quan đến bất kỳ tiêu chuẩn của bạn là gì hoặc điều này sẽ tiếp tục là một vấn đề.

3

Nó nghĩ rằng akf trả lời câu hỏi tốt. Và HLGEM làm cho một điểm tốt về tái cấu trúc.

Tuy nhiên, tôi sẽ thêm đối tượng này để không có quy ước tiền tố/hậu tố. Trong SQL Server (và có lẽ là các cơ sở dữ liệu khác), bạn không thể có một bảng và một khung nhìn có cùng tên trong cùng một lược đồ với cùng một chủ sở hữu. Nó là một mô hình phổ biến để tạo ra một cái nhìn không chuẩn hóa cho một bảng. Nếu bạn chưa chấp nhận một quy ước đặt tên phân biệt các khung nhìn từ các bảng thì bạn có thể kết thúc với các tên buồn cười cho các khung nhìn này như EMPLOYEE_DENORM thay vì EMPLOYEE_V.

Nếu nhu cầu phát sinh cho việc tái cấu trúc như HLGEM mô tả thì quy ước đặt tên của bạn có thể cho phép điều đó. Bằng cách đó, các chế độ xem không có tiền tố hoặc hậu tố có thể dễ dàng được xác định là chế độ xem "tái cấu trúc".

0

Tôi thích đặt tên cho các bảng của mình trong tất cả các camelCase, cũng như các tên trường. Ví dụ...

CREATE TABLE [crm].[company] 
(
    [id] INT NOT NULL PRIMARY KEY, 
    [companyName] NVARCHAR(255) NOT NULL 
) 

Và đối với chế độ xem, tôi thêm chúng bằng từ "xem". Ví dụ ...

CREATE VIEW [crm].[viewFullEmployee] 
    AS SELECT e.id, e.companyId, e.niceId, e.startDate, e.fullPart, p.firstName, p.middleName, p.lastName, p.active, p.birthDate, p.email, p.alternateEmail, p.phone, p.phoneExt, p.homePhone, p.mobilePhone, p.jobTitle, p.suffix, p.prefix FROM [crm].[Employee] as e FULL JOIN [crm].[person] as p on e.id = p.id 

Tôi cũng chia mọi thứ ra thành giản đồ và tôi không sử dụng lược đồ mặc định, buộc tôi phải luôn chỉ định giản đồ cho những thứ trong truy vấn của mình vì không có gì trong dbo.

Tôi biết điều gì đó là một bảng bằng cách thiếu chế độ xem từ phía trước. Điều này cũng ngăn cản việc có một bảng và một khung nhìn có cùng tên.

Tôi không thích sử dụng các tên gạch dưới như "employee_v" vì tôi tạo tất cả mã lớp dữ liệu với các mẫu T4 "PetaPoco" và tôi không thích phải nhập _ trong mã của mình khi đề cập đến một loại.

tôi chỉ như thế này tốt hơn

var person = uow.Db.Fetch<Models.viewFullEmployee>("SELECT * FROM [crm].[viewFullEmployee]"); 

vs

var person = uow.Db.Fetch<Models.fullEmployee_V>("SELECT * FROM [crm].[fullEmployee_V]"); 

Đối với các thủ tục lưu trữ tôi cảm thấy họ không cần tiền tố như "sp_" mà tôi thấy rất nhiều người làm. Bạn biết đó là một thủ tục được lưu trữ được sử dụng do preffix của EXEC, hoặc Create Procedure, hoặc Alter Procedure. Vì vậy, tôi đặt tên cho các thủ tục được lưu trữ của tôi như "addUpdatePerson", "getUserPermissions", v.v.

Nơi tôi sử dụng tiền tố có chức năng, như "fnValidateEmail" khi chúng có thể đụng độ với tên thủ tục được lưu trữ.

Các vấn đề liên quan