Mengapa nama tabel / kolom / indeks Oracle dibatasi hingga 30 karakter?

Saya bisa mengerti bahwa bertahun-tahun yang lalu akan ada batasan semacam ini, tetapi saat ini pasti batas ini dapat dengan mudah ditingkatkan. Kami memiliki konvensi penamaan untuk objek, tetapi selalu ada kasus yang muncul di mana kami mencapai batas ini - terutama dalam penamaan kunci asing.

Adakah yang benar-benar tahu mengapa ini bukan ukuran yang lebih besar - atau lebih besar dalam 11g?

Tampaknya jawabannya adalah bahwa itu akan merusak skrip yang saat ini tidak memiliki kode pertahanan. Saya mengatakan bahwa adalah hal yang sangat mengkhawatirkan, Oracle sedang mencoba untuk menjadi yang basis data, pasti ini adalah jenis hal yang Anda harus terus-menerus meningkatkan, jika produk Anda akan mati kematian seribu luka.

Setiap kali saya melihat keberatan semacam ini di rumah, saya pikir sudah waktunya untuk menggigit peluru dan mengatasinya. Jika orang menjalankan skrip yang tidak mereka periksa atau pelihara ketika mereka memutakhirkan versi Oracle, maka biarkan mereka menderita konsekuensi dari pilihan itu. Memberi mereka flag kompatibilitas, naik ukuran hingga 4000, lalu menyelamatkan saya waktu terbuang ketika saya membuat objek karena harus terus-menerus menghitung hingga 30 untuk memeriksa nama apakah 'OK'.

Saya percaya itu adalah standar ANSI.

EDIT:

Sebenarnya, saya pikir itu standar SQL-92.

Versi standar yang lebih baru tampaknya secara opsional memungkinkan untuk 128 nama karakter, tetapi Oracle belum mendukung ini (atau memiliki dukungan parsial untuk itu, sejauh memungkinkan 30 karakter. Hmmm.)

Cari "F391, Long identifiers" di halaman ini ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(Mencari ref)

Selain poin cagcowboy yang berasal dari standar SQL (secara historis, saya menduga bahwa keputusan Oracle mengarah ke standar SQL sejak Oracle mendahului standardisasi SQL), saya akan bertaruh bahwa sebagian besar keengganan untuk mengizinkan pengidentifikasi yang lebih lama berasal dari kesadaran bahwa ada jutaan DBA dengan jutaan skrip khusus yang semuanya menganggap bahwa pengidentifikasi memiliki panjang 30 karakter. Mengizinkan setiap baris kode seperti itu

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

untuk tiba-tiba pecah karena DBA 15 tahun yang lalu menggunakan VARCHAR2 (30) daripada DBA_TABLES.TABLE_NAME%TYPEdalam naskah akan menyebabkan pemberontakan besar-besaran. Saya berani bertaruh bahwa Oracle sendiri memiliki ribuan tempat di mana hal semacam ini telah dilakukan selama bertahun-tahun dalam berbagai paket dan komponen. Memperbaiki semua kode yang ada untuk mendukung pengidentifikasi yang lebih lama akan menjadi proyek luar biasa yang hampir pasti akan menghasilkan biaya yang jauh lebih banyak dalam waktu pengembang, waktu QA, dan bug yang baru diperkenalkan daripada yang akan menghasilkan manfaat.

Saya mencari ini dan menemukan pertanyaan ini melalui Google, tetapi juga menemukan bahwa pada Oracle 12c Release 2 (12.2), ini tidak lagi menjadi masalah. ( https://oracle-base.com/articles/12c/long-identifiers-12cr2 )

Pada titik tertentu setiap DBA atau pengembang akan mencapai titik di mana batas 30 karakter untuk nama objek telah menyebabkan masalah. Batas ini bisa sangat menyakitkan ketika melakukan proyek migrasi dari SQL Server atau MySQL ke Oracle. Dalam Oracle Database 12cR2, panjang maksimum dari kebanyakan pengidentifikasi sekarang 128 karakter.

Ini adalah fitur baru dalam 12.2, menurut ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ). Menurut posting itu, 12.1 masih terbatas hingga 30 karakter.

Sunting: Berikut ini tautan ke dokumentasi Oracle resmi yang menjelaskan perubahan tersebut. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

Dimulai dengan Oracle Database 12c Release 2 (12.2), panjang maksimum nama pengidentifikasi untuk sebagian besar jenis objek basis data telah ditingkatkan menjadi 128 byte.

Mengingat kebutuhan praktis dari batas panjang pengidentifikasi, desain yang baik membatasi panjang nama sebenarnya untuk menghindari memukul langit-langit ketika nama-nama tersebut digabungkan satu sama lain dan dengan awalan dan sufiks.

Misalnya, konvensi penamaan batasan kunci asing

FK_<table1>_<table2> 

membatasi nama tabel hingga 13 karakter atau kurang; kebanyakan database akan membutuhkan lebih banyak awalan dan sufiks, yang selanjutnya membatasi panjang nama tabel.

Pelanggaran kendala dapat dilaporkan dalam SQLERRM yang dibatasi hingga 255 karakter, dan yang digunakan sebagian besar klien untuk membuat kesalahan terlihat. Saya menduga meningkatkan ukuran nama kendala yang diijinkan secara signifikan akan berdampak pada kemampuan untuk melaporkan pelanggaran (terutama di mana pelanggaran kendala telah digelembungkan melalui beberapa lapisan kode PL / SQL).

Saya percaya bahwa panjang 30 karakter pengidentifikasi berasal dari COBOL yang distandarisasi pada akhir 1950-an. Karena program COBOL adalah pengguna utama SQL (dan SEQUEL sebelum itu (dan QUEL sebelum itu)), ini pasti tampak seperti angka yang masuk akal untuk panjang pengidentifikasi.

Semua 'kendala' ini merupakan tanggapan atas batasan yang diberlakukan oleh arsitektur prosesor yang berasal dari tahun 70-an. Sejak saat itu prosesor telah berevolusi ke titik bahwa batasan ini tidak lagi diperlukan; mereka hanya tersisa. Namun, mengubah mereka adalah masalah besar bagi para penulis RDBMS. Karena batasan panjang ini memengaruhi segalanya di hilir, maka tidak perlu lagi untuk mengakomodasi, katakanlah nama prosedur yang lebih panjang dapat dan mungkin akan memecah banyak hal lain seperti pelaporan eksekusi, kamus data, dll., Seterusnya dan seterusnya. Saya akan membutuhkan penulisan ulang Oracle RDBMS.

Jawaban langsung untuk pertanyaan ini adalah bahwa gaya Oracle diwarisi dari ide-ide lama di mana 30 tampaknya banyak, dan lebih banyak lagi akan meningkatkan risiko melepaskan pin cache kamus dari memori nyata dalam database biasa.

Sebaliknya, namespace ODBC berasal dari tempat yang sangat berbeda, di mana set data diekstraksi dengan cepat dengan menguraikan tabel dalam lembar Excel dan secara otomatis membangun tabel database dengan nama kolom yang diambil dari judul tabel lembar. Berpikir seperti itu menuntun Anda untuk memungkinkan pengidentifikasi yang bahkan mengandung carriage return yang dikembalikan, dan tentu saja karakter khusus dan case campuran. Ini adalah abstraksi yang masuk akal karena memodelkan cara berpikir analis data saat ini.

Tidak masalah SQL92, kepatuhan ODBC yang benar-benar penting untuk database universal saat ini, dan vendor lain telah mengatasi ini lebih baik daripada Oracle. Bahkan Teradata, misalnya, yang tidak dilihat oleh banyak orang sebagai pemain luas, melayani untuk dua ruang nama, dengan dan tanpa tanda kutip, yang pertama dengan batas 30 char, yang terakhir implementasi ODBC penuh di mana pengidentifikasi panjang yang aneh dipenuhi .

Bahkan di arena basis data besar tradisional, 30 karakter sering menjadi masalah di mana nama tetap bermakna, konsisten, dan mudah diingat. Setelah Anda mulai merancang struktur khusus dengan pewarisan peran-peran, Anda mulai menyingkat singkatan, dan konsistensi segera mati, karena misalnya pengidentifikasi akar yang sama yang dirender sebagai nama tabel atau nama kolom dalam satu kasus akan memerlukan singkatan lebih lanjut dan yang lain tidak . Jika pengguna nyata dalam jumlah yang signifikan diundang ke lapisan seperti itu konsekuensinya adalah kegunaan yang sangat buruk, dan untungnya untuk setiap basis data penuaan, drive utama sekarang adalah untuk memisahkan pengguna dari basis data melalui lapisan objek dan alat BI.

Ini meninggalkan lapisan basis data untuk DBA dan tim arsitek data, yang mungkin tidak terlalu peduli. Mengerjakan skema singkatan masih merupakan pekerjaan seumur hidup, tampaknya.

Bahwa Oracle belum mengatasi batasan lama ini mungkin sebagian besar mencerminkan fakta bahwa ia belum (belum) kehilangan banyak bisnis karena pesaingnya ketika tidak dapat secara langsung mem-porting desain basis data yang dibangun menggunakan pengidentifikasi yang lebih lama.

Semua komentar di atas benar, TETAPI Anda perlu mengingat biaya kinerja dari nama yang lebih panjang. Pada awal 1990-an, ketika Informix membuat papan iklan besar "Informix Faster Than Oracle!" pada rute 101 di sebelah kantor pusat Oracle, Informix mengizinkan nama tabel hanya lebih pendek dari 18 karakter! Alasannya jelas - nama tabel dalam bentuk literal mereka (yaitu sebagai nama sebenarnya daripada 't138577321'atau sesuatu seperti itu) disimpan dalam Kamus Data. Nama yang lebih panjang sama dengan Kamus Data yang lebih besar, dan karena Kamus Data dibaca setiap kali kueri membutuhkan parse keras, kamus data yang lebih besar sama dengan kinerja yang buruk ...

ok, batasannya ada ....

tetapi apakah Anda benar-benar MEMBUTUHKAN lebih dari 30 karakter untuk memberi nama tabel / indeks / kolom ??

saat menulis pertanyaan, dengan batasan itu saya MASIH menemukan beberapa nama kolom / tabel yang mengganggu. Jika batasnya lebih tinggi saya mungkin mengalami tabel yang membutuhkan kueri seperti:

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.

Saya minta maaf atas kata-kata besar: P