Có một lý do để sử dụng tên bảng viết tắt cực kỳ?

Chúng tôi đang sử dụng một thiết lập cơ sở dữ liệu từ ứng dụng của nhà cung cấp rất khó đọc tên bảng cơ sở dữ liệu và không có tài liệu nào được lưu trữ ở đâu. Tôi có thể thấy lý do tại sao người ta có thể muốn làm xáo trộn cấu trúc bảng của họ trong một ứng dụng độc quyền, nhưng một trong những điểm bán hàng của ứng dụng này (Kế hoạch tài nguyên doanh nghiệp) là khả năng tùy biến.

Tên bảng giống như aptrx (Giao dịch phải trả tiền) và apmaster_all (thật kỳ lạ, đây là bảng nhà cung cấp). Đó là một cơ sở dữ liệu cực kỳ phức tạp, vì vậy tôi đã tự hỏi liệu có bất kỳ logic nào cho quy ước hoặc nếu nó chỉ đơn giản là bị che giấu có chủ ý hay không.

Theo hiểu biết tốt nhất của tôi, độ dài của tên bảng sẽ không ảnh hưởng đến hiệu suất đáng chú ý, đúng không? Cơ sở dữ liệu rất phức tạp (hàng trăm bảng) vì vậy việc sắp xếp có ý nghĩa, nhưng tôi không thể tưởng tượng được tại sao AccountPayableTransilities không thích hợp hơn với aptrx ....

Oracle đã có một giới hạn lâu dài về tên bảng gồm 30 ký tự. Tôi nghi ngờ đây là một vấn đề di sản dựa trên môi trường 16 bit ban đầu.
Độ dài của tên bảng có thể có một số ảnh hưởng rất nhỏ đến hiệu suất vì tất cả các tên phải được lưu trữ trong từ điển dữ liệu và cũng được phân tích cú pháp cho các truy vấn nhưng tôi không nghĩ bạn có thể đo được lần truy cập.

Một tác dụng quan trọng hơn của tên bảng ngắn là khó làm việc. Tôi cũng phải duy trì một lược đồ cơ sở dữ liệu doanh nghiệp với các tên ngắn. Không có lý do chính đáng để có tên bảng ngắn. Dễ dàng bảo trì vấp ngã obfuscation hoặc thói quen DOS cũ mỗi lần.

Tôi cảm thấy có hai điều vẫn cần phải nói hoặc xây dựng:

1. Đặt tên mọi thứ không tầm thường như nó có vẻ

   Chỉ có hai vấn đề khó khăn trong Khoa học Máy tính: vô hiệu hóa bộ đệm và đặt tên mọi thứ. Phil Karlton

2. Trong khi những cái tên vô nghĩa ngắn luôn xấu, thì những cái tên dài không phải lúc nào cũng tốt - bộ não của chúng ta có ngưỡng tl; dr thấp đến mức đáng ngạc nhiên. 30 ký tự thường là đủ nhưng tôi thích RDBMS cho phép nhiều hơn cho các trường hợp ngoại lệ khi nó không (và giống như trong ngôn ngữ, tên dài hơn sẽ hữu ích hơn cho những thứ chúng ta không nói đến thường xuyên - như tên ràng buộc và tên ngắn hơn hữu ích hơn cho các bảng chúng tôi truy vấn mọi lúc)

Tôi luôn bị cám dỗ dành quá ít thời gian để chọn tên và luôn hối hận về sau nếu tôi làm vậy - việc thay đổi tên chỉ xảy ra hiếm khi

Lười biếng. Tùy chọn IntelliSense và bên thứ 3 làm cho việc nhập một lý do khó khăn thực sự để biện minh. Tôi muốn thay vì tên có những từ có ý nghĩa và dễ đọc.

Tên bảng giống như aptrx (Giao dịch phải trả tiền) và apmaster_all (thật kỳ lạ, đây là bảng nhà cung cấp). Đó là một cơ sở dữ liệu cực kỳ phức tạp, vì vậy tôi đã tự hỏi liệu có bất kỳ logic nào cho quy ước hoặc nếu nó chỉ đơn giản là bị che giấu có chủ ý hay không.

Chữ viết tắt nổi tiếng thường được ưa thích để đánh vần mọi thứ. Khi một tên viết tắt nổi tiếng với một số người, nhưng không đủ người, chúng tôi ngừng gọi nó là viết tắt và bắt đầu gọi nó là một mã.

Chữ viết tắt bảo tồn không gian trên các nền tảng có giới hạn chặt chẽ, mặc dù điều này ít quan trọng hơn so với 30 năm trước. (Tôi dường như nhớ lại việc làm việc trên một hệ thống vào những năm 1980 đã giới hạn bạn ở mức 6 hoặc 8 ký tự cho một tên bảng.)

Chữ viết tắt thường làm cho tên bảng và tên cột dễ đọc hơn, miễn là việc viết tắt được thực hiện tốt. Nếu tôi làm việc về mã cho AP cả ngày, tôi muốn đọc các tên cột như "ap_trx.inv_num" hơn là "Tài khoản_payable_transilities.invoice_number". (Tôi thích dấu gạch dưới.) Việc gõ tên dài không phải là vấn đề với trình soạn thảo văn bản tốt.

Trong các hệ thống kế toán, cả "ap" và "trx" là các chữ viết tắt nổi tiếng. Những thứ khác bao gồm "ar", "gl" và "gj" cho các khoản phải thu, sổ cái và nhật ký chung.

Trong một hệ thống được thiết kế tốt, nếu tôi tìm thấy các tài khoản giao dịch phải trả trong một bảng có tên là "aptrx", tôi hy vọng sẽ tìm thấy các tài khoản giao dịch phải thu trong artrx, giao dịch sổ cái chung trong gltrx, v.v. Tôi thấy "apmaster_all" hơi khó hiểu, nhưng nếu tôi cũng tìm thấy "armaster_all", tôi cho rằng người đầu tiên nắm giữ tất cả các nhà cung cấp (trái ngược với các nhà cung cấp đang hoạt động hoặc không hoạt động), và thứ hai tương tự giữ tất cả các khách hàng.

Trong các lĩnh vực vấn đề khác, bạn tìm thấy các chữ viết tắt nổi tiếng khác. Khi đánh địa chỉ, bạn sẽ tìm thấy các chữ viết tắt như "addr" cho địa chỉ, "st" cho đường phố, "usps" cho Dịch vụ Bưu chính Hoa Kỳ, "up" cho United Parcel Service, "cty" cho quận, "zip" cho Cải thiện Khu vực Mã, và như vậy.

Tôi sẽ không gọi đây là sự xáo trộn. Nếu các tài khoản giao dịch phải trả được lưu trữ trong một bảng có tên "cdrs21", tôi sẽ gọi đó là sự xáo trộn. (Mặc dù tôi đã từng làm việc cho một công ty đặt tên cho tất cả các mô đun trình biên dịch máy tính lớn của họ theo cách đó. Giới hạn ký tự, không làm xáo trộn.)

Nhưng cơ sở dữ liệu hữu ích phát triển và bạn gặp vấn đề khi cơ sở dữ liệu trở nên lớn. Khi bạn thêm các miền vấn đề vào cơ sở dữ liệu của mình, bạn sẽ gặp phải các tình huống viết tắt nổi tiếng va chạm. Nếu bạn giao dịch với các phương tiện truyền thông, thì "ap" cũng có thể viết tắt "Associated Press", "báo chí thay thế" hoặc "vị trí trước". Khi điều đó xảy ra, đã đến lúc từ bỏ chữ viết tắt hoặc chuyển sang mã. Tổ chức càng lớn (và cơ sở dữ liệu càng lớn), tôi càng tìm thấy mã thường xuyên hơn.

Chỉ cần nói chuyện với "chúa ơi, kính bảo hộ họ không làm gì cho câu chuyện quy ước đặt tên khủng khiếp này". Nhóm quản lý dữ liệu ở môi trường cuối cùng của tôi đã nêu lý do sử dụng tên bảng viết tắt là giới hạn của DB2 (chúng tôi có DB2 trên z / os và SQL Server) gồm 18 ký tự cho các bảng và cột. Tôi đã kịp thời chỉ ra điều này là không chính xác với tài liệu từ trang web của IBM. Sau đó, họ tuyên bố đó là một vấn đề về COBOL (vâng, họ đã tích cực phát triển COBOL) trong trường hợp cần nói chuyện với cơ sở dữ liệu mà sau đó đã bị các jockey MF từ chối. Cuối cùng, phản hồi của họ là tiêu chuẩn xuất bản của chúng tôi.

Chúng tôi đã kiến ​​nghị với ủy ban tiêu chuẩn để tăng độ dài từ 18 lên 32 ký tự và nhận giới hạn 30 ký tự. Điều đó dẫn đến các bảng đi từ các tên vô dụng của 'SR_M_DLY_ADV_PRD_S' sang 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML

Vì vậy, trong hàng chục năm kinh nghiệm của tôi, các tên bảng rút ngắn không mang lại lợi ích hữu hình nào và dẫn đến chi phí phát triển và bảo trì cao hơn vì tôi luôn phải tham khảo từ điển dữ liệu để dịch rác trên màn hình sang một định danh có ý nghĩa. Điều này có thể tương phản với các thực thể có tên logic mà tôi đã làm việc và chủ yếu có thể tạo lại từ bộ nhớ vì chúng được đặt tên theo trực giác.

Đó là một thói quen (tôi đồng ý với Kevinsky). Đó là phản ứng đối với một số vấn đề cũ (có thể tồn tại) đối với hạn chế (độ dài tên, khoảng cách giữa các từ của tên phức tạp, đa ngôn ngữ, v.v.) của hệ điều hành (ví dụ như DOS, Windows) và một số phần mềm không xử lý tên đó. Những người có kinh nghiệm cho biết: "Làm như vậy (sử dụng ngắn và tách biệt với tên gạch chân) và tất cả sẽ ổn."

Tôi thích sử dụng cách đặt tên mô tả cho các lý do đã nói ở trên bởi các áp phích.

Nhưng cũng có một lợi ích khác. Chẳng hạn, với cách đặt tên mô tả, nó cho phép bạn sử dụng các tên lồng nhau. Giả sử bạn có một bảng gọi là Nhân viên. Nếu bạn có mối quan hệ với một bảng khác, nó có thể được gọi là EmployeeAddress. Hoặc Nhân viên. Với mật mã, việc đặt tên bị loại bỏ điều này gần như là không thể.

Phụ thuộc vào mức độ phức tạp của các định nghĩa cơ bản của mỗi cột. Tôi nghĩ mọi người trở nên lười biếng với việc quản lý siêu dữ liệu khi họ nhìn thấy các loại tên cột rất mô tả này và thậm chí chúng còn là những mô tả không đầy đủ. Bạn cũng có thể hỏi tại sao viết tắt bất cứ điều gì.