Tại sao tên bảng / cột / chỉ mục của Oracle giới hạn trong 30 ký tự?

Tôi có thể hiểu rằng nhiều năm trước sẽ có loại giới hạn này, nhưng ngày nay chắc chắn giới hạn này có thể dễ dàng tăng lên. Chúng ta có các quy ước đặt tên cho các đối tượng, nhưng luôn có một trường hợp xuất hiện khi chúng ta đạt đến giới hạn này - đặc biệt là trong việc đặt tên khóa ngoại.

Có ai thực sự biết tại sao đây không phải là một kích thước lớn hơn - hoặc nó lớn hơn trong 11g?

Rõ ràng câu trả lời là nó sẽ phá vỡ các tập lệnh hiện không được mã hóa. Tôi nói đó là một điều rất đáng lo ngại, Oracle đang cố gắng trở thành cơ sở dữ liệu, chắc chắn đây là điều mà bạn phải liên tục cải thiện, nếu không sản phẩm của bạn sẽ chết vì hàng ngàn vết cắt.

Bất cứ khi nào tôi thấy loại phản đối này trong nhà, tôi nghĩ rằng đã đến lúc cắn viên đạn và phân loại nó. Nếu mọi người đang chạy các tập lệnh mà họ không kiểm tra hoặc bảo trì khi nâng cấp các phiên bản Oracle, thì hãy để họ chịu hậu quả của lựa chọn đó. Cung cấp cho họ một cờ tương thích, tăng kích thước lên tới 4000, sau đó tiết kiệm cho tôi thời gian lãng phí khi tôi tạo các đối tượng phải liên tục đếm đến 30 để kiểm tra tên là 'OK'.

Tôi tin rằng đó là tiêu chuẩn ANSI.

BIÊN TẬP:

Trên thực tế, tôi nghĩ đó là tiêu chuẩn SQL-92.

Một phiên bản mới hơn của tiêu chuẩn dường như cho phép tùy ý cho 128 tên ký tự, nhưng Oracle chưa hỗ trợ điều này (hoặc có hỗ trợ một phần cho nó, trong trường hợp nó cho phép 30 ký tự. Hmmm.)

Tìm kiếm "F391, số nhận dạng dài" trên trang này ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_stiteria_sql001.htm

(Tìm kiếm một ref)

Ngoài quan điểm của cagcowboy rằng nó xuất phát từ tiêu chuẩn SQL (về mặt lịch sử, tôi nghi ngờ rằng quyết định của Oracle dẫn đến tiêu chuẩn SQL vì Oracle đã dự đoán tiêu chuẩn hóa SQL), tôi sẽ đặt ra rằng một phần lớn sự miễn cưỡng cho phép nhận dạng dài hơn đến từ việc nhận ra rằng có hàng triệu DBA với hàng triệu tập lệnh tùy chỉnh mà tất cả đều cho rằng số nhận dạng dài 30 ký tự. Cho phép mọi dòng mã đi giống như

  l_table_name VARCHAR2(30);
BEGIN
  SELECT table_name
    INTO l_table_name
    FROM dba_tables
   WHERE ...

đột nhiên bị phá vỡ vì DBA 15 năm trước đã sử dụng VARCHAR2 (30) thay vì DBA_TABLES.TABLE_NAME%TYPEtrong kịch bản sẽ gây ra cuộc nổi loạn lớn. Tôi cá rằng một mình Oracle có hàng ngàn nơi mà loại điều này đã được thực hiện trong nhiều năm qua trong các gói và thành phần khác nhau. Retrofitting tất cả những mã để hỗ trợ định danh còn tồn tại sẽ là một dự án rất lớn mà gần như chắc chắn sẽ tạo ra cách chi phí nhiều hơn trong thời gian phát triển, thời gian QA, và lỗi mới được giới thiệu hơn nó sẽ tạo ra lợi ích.

Tôi đã tìm kiếm câu hỏi này và tìm thấy câu hỏi này thông qua Google, nhưng cũng phát hiện ra rằng kể từ phiên bản Oracle 12c Phiên bản 2 (12.2), đây không còn là vấn đề nghiêm trọng nữa. ( https://oracle-base.com/articles/12c/long-identifier-12cr2 )

Tại một số điểm, mọi DBA hoặc nhà phát triển sẽ đạt đến điểm giới hạn 30 ký tự cho tên đối tượng đã gây ra sự cố. Giới hạn này có thể cực kỳ đau đớn khi thực hiện các dự án di chuyển từ SQL Server hoặc MySQL sang Oracle. Trong Cơ sở dữ liệu Oracle 12cR2, độ dài tối đa của hầu hết các mã định danh hiện là 128 ký tự.

Đây là một tính năng mới trong 12.2, theo ( http://blog.dbi-service.com/oracle-12cr2-long-identifier/ ). Theo bài đăng đó, 12.1 vẫn bị giới hạn ở 30 ký tự.

Chỉnh sửa: Đây là một liên kết đến tài liệu chính thức của Oracle giải thích về sự thay đổi. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htmlm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

Bắt đầu với Cơ sở dữ liệu Oracle 12c Phiên bản 2 (12.2), độ dài tối đa của tên định danh cho hầu hết các loại đối tượng cơ sở dữ liệu đã được tăng lên 128 byte.

Do sự cần thiết thực tế của giới hạn độ dài định danh, thiết kế tốt sẽ hạn chế độ dài của tên thực để tránh chạm trần khi các tên được kết hợp với nhau và có tiền tố và hậu tố.

Ví dụ: quy ước đặt tên ràng buộc khóa ngoại

FK_<table1>_<table2> 

giới hạn tên bảng từ 13 ký tự trở xuống; hầu hết các cơ sở dữ liệu sẽ cần nhiều tiền tố và hậu tố hơn, hạn chế hơn nữa độ dài của tên bảng.

Vi phạm ràng buộc được báo cáo trong SQLERRM, giới hạn ở 255 ký tự và hầu hết các máy khách sử dụng để hiển thị lỗi. Tôi nghi ngờ việc tăng kích thước cho phép của các tên ràng buộc sẽ ảnh hưởng đáng kể đến khả năng báo cáo về các vi phạm (đặc biệt là khi vi phạm ràng buộc đã được đưa lên qua một vài lớp mã PL / SQL).

Tôi tin rằng độ dài nhận dạng 30 ký tự đến từ COBOL đã được chuẩn hóa vào cuối những năm 1950. Vì các chương trình COBOL là người dùng chính của SQL (và SEQUEL trước đó (và QUEL trước đó)), nên đây có vẻ như là một con số hợp lý cho độ dài định danh.

Tất cả những 'ràng buộc' này đều là những phản hồi còn sót lại đối với các giới hạn được áp đặt bởi các kiến ​​trúc bộ xử lý xuất phát từ những năm 70. Vì thời gian đó bộ xử lý đã phát triển đến mức những hạn chế này không còn cần thiết nữa; họ chỉ còn lại Tuy nhiên, thay đổi chúng là một thỏa thuận LỚN cho các tác giả của RDBMS. Vì các giới hạn độ dài này ảnh hưởng đến mọi thứ ở hạ lưu, nên nó sẽ thay đổi thành một tên thủ tục dài hơn và có thể sẽ phá vỡ rất nhiều thứ khác như báo cáo thực thi, từ điển dữ liệu, v.v. Tôi sẽ yêu cầu viết lại chính RDBMS của Oracle.

Câu trả lời trực tiếp cho câu hỏi là phong cách Oracle được kế thừa từ những ý tưởng cũ hơn trong đó 30 dường như rất nhiều, và nhiều hơn nữa sẽ làm tăng nguy cơ bỏ ghim bộ đệm từ điển từ bộ nhớ thực trong cơ sở dữ liệu thông thường.

Ngược lại, không gian tên ODBC đến từ một nơi rất khác, nơi các bộ dữ liệu được trích xuất nhanh chóng bằng cách phân tích một bảng trong một bảng Excel và tự động xây dựng các bảng cơ sở dữ liệu với các tên cột được lấy từ các tiêu đề của bảng. Suy nghĩ như vậy dẫn bạn đến việc cho phép các định danh thậm chí có chứa lợi nhuận vận chuyển nhúng, và tất nhiên là các ký tự đặc biệt và trường hợp hỗn hợp. Đó là một sự trừu tượng hợp lý bởi vì nó mô hình hóa cách suy nghĩ của các nhà phân tích dữ liệu ngày nay.

Đừng bận tâm đến SQL92, việc tuân thủ ODBC thực sự quan trọng đối với cơ sở dữ liệu phổ quát ngày nay và các nhà cung cấp khác đã giải quyết vấn đề này tốt hơn Oracle. Ví dụ, ngay cả Teradata, không được nhiều người xem là người chơi phổ biến, phục vụ cho các không gian tên TWO, có và không có dấu ngoặc kép, trước đây có giới hạn 30 char, sau đó là một triển khai ODBC đầy đủ trong đó các định danh dài kỳ lạ được phục vụ cho .

Ngay cả trong lĩnh vực cơ sở dữ liệu lớn truyền thống, 30 ký tự thường là một vấn đề trong đó các tên phải duy trì ý nghĩa, nhất quán và đáng nhớ. Khi bạn bắt đầu thiết kế các cấu trúc chuyên biệt với sự kế thừa tên vai trò, bạn bắt đầu viết tắt các chữ viết tắt và tính nhất quán sẽ sớm chết, vì ví dụ, cùng một mã định danh gốc được hiển thị dưới dạng tên bảng hoặc tên cột trong một trường hợp sẽ không cần viết tắt và trong trường hợp khác thì không viết tắt . Nếu người dùng thực sự với số lượng đáng kể được mời vào các lớp như vậy thì hậu quả là khả năng sử dụng rất kém, và may mắn thay cho bất kỳ cơ sở dữ liệu cũ nào, ổ đĩa chính bây giờ là tách người dùng khỏi cơ sở dữ liệu thông qua các lớp đối tượng và công cụ BI.

Điều này để lại lớp cơ sở dữ liệu cho DBA và các nhóm kiến ​​trúc sư dữ liệu, những người có lẽ không bận tâm lắm. Làm việc ra các kế hoạch viết tắt vẫn là một công việc cho cuộc sống, dường như.

Việc Oracle không giải quyết được giới hạn cũ này có lẽ phản ánh chủ yếu về thực tế rằng nó vẫn chưa (chưa) mất đi nhiều lợi thế cạnh tranh khi không thể trực tiếp thiết kế cơ sở dữ liệu được xây dựng bằng cách sử dụng các định danh dài hơn.

Tất cả các ý kiến ​​trên là đúng, NHƯNG bạn cần ghi nhớ chi phí hiệu suất của tên dài hơn. Đầu những năm 1990, khi Informix thành lập bảng quảng cáo khổng lồ "Informix nhanh hơn Oracle!" trên tuyến đường 101 bên cạnh trụ sở chính của Oracle, Informix chỉ cho phép tên bảng ngắn hơn 18 ký tự! Lý do rất rõ ràng - tên bảng ở dạng nghĩa đen của chúng (nghĩa là tên thực tế thay vì 't138577321' hoặc một cái gì đó giống như vậy) được lưu trữ trong Từ điển dữ liệu. Tên dài hơn bằng với Từ điển dữ liệu lớn hơn và vì Từ điển dữ liệu được đọc mỗi lần truy vấn yêu cầu phân tích cú pháp cứng, từ điển dữ liệu lớn hơn tương đương với hiệu suất kém ...

ok, giới hạn tồn tại ....

nhưng bạn có thực sự CẦN hơn 30 ký tự để đặt tên cho bảng / chỉ mục / cột không ??

khi viết truy vấn, với giới hạn đó, tôi VẪN thấy một số tên cột / bảng gây phiền nhiễu. Nếu giới hạn cao hơn, tôi có thể chạy vào các bảng yêu cầu truy vấn như:

select unique_identifier_column, 
time_when_the_user_remembered_to_change_the_row_in_the_receipt_table, 
foreign_key_to_the_ap_invoice_distributions_history_table_related_to_the_all_rows_table 
from ap_invoices_really_really_all_all_rows_present_in_this_ebs_table.

Tôi xin lỗi vì những từ rất lớn: P