Saya menonton beberapa video Brent Ozar ( seperti ini, misalnya ) dan dia menyarankan untuk tidak mengawali tabel dengan ‘tbl’atau ‘TBL’.

Di internet saya menemukan beberapa blog mengatakan itu tidak menambah dokumentasi, dan juga "butuh waktu lebih lama untuk membacanya".

Pertanyaan dan pertimbangan

• Apakah ini benar-benar masalah? Karena saya mengawali tabel dengan 'tbl' sejak pekerjaan dba pertama saya (DBA senior menyuruh saya melakukan itu untuk organisasi).
• Apakah ini sesuatu yang harus saya singkirkan? Saya membuat beberapa tes, menyalin tabel yang sangat besar dan memberinya awalan 'tbl', sambil menyimpan yang lain tanpa itu, dan saya tidak melihat adanya masalah kinerja.

Saya pernah punya meja dan itu mengkilap dan indah. Itu memegang semua transaksi keuangan untuk suatu organisasi. Dan kemudian kami mulai memuat data ke dalamnya.

Pada bulan ini, mereka dapat menyatakan dan menyatakan kembali nilai sesering yang mereka inginkan. Dalam 10 hari terakhir dalam sebulan, mereka akan menyatakan ulang angka -> menjalankan pemrosesan ETL -> meninjau laporan beberapa kali sehari. Setelah bulan selesai, maka buku-buku disegel dan mereka tidak dapat mengubah nilai.

Sungguh menakjubkan berapa banyak data keuangan yang dihasilkan sebuah perusahaan jasa keuangan ... Sesuatu yang tidak kami sadari dengan kumpulan data pengujian kami adalah volume data akan membuat prosedur akhir bulan mereka tidak dapat dipertahankan. Butuh waktu yang semakin lama untuk menghapus "data bulan ini" sebelum menggantinya dengan uji coba baru.

Kami harus melakukan sesuatu untuk membuatnya lebih cepat untuk diproses tanpa memecah daftar "siapa yang tahu apa" yang semuanya tergantung pada tabel Alokasi Bulanan. Saya memutuskan untuk bermain penyihir dan mencabut taplak meja dari bawah mereka. Saya pergi ke sekolah tua dan menggunakan Pandangan Partisi . Data sudah memiliki panji IsComplete jadi saya membuat dua tabel - masing-masing dengan kendala pemeriksaan sebaliknya: MonthlyAllocationComplete, MonthlyAllocationInComplete

Saya kemudian membuat tampilan dipartisi dengan nama yang sama dengan tabel asli: MonthlyAllocation. Tidak ada proses yang lebih bijaksana tentang perubahan fisik yang kami lakukan pada basis data. Tidak ada laporan yang rusak, tidak ada analis dengan akses langsung melaporkan masalah dengan "tabel" itu sebelum atau sesudah.

Cerita keren bro, tapi kemana kamu pergi?

Bagaimana jika mereka memiliki konvensi penamaan di sana, tbl_MonthlyAllocation? Sekarang apa? Apakah kita menghabiskan banyak waktu untuk memeriksa setiap ETL, setiap laporan, setiap spreadsheet ad-hoc dalam organisasi dan memutakhirkannya untuk menggunakan vw_MonthlyAllocation? Dan tentu saja semua perubahan itu melalui Papan Perubahan dan itu selalu merupakan proses yang cepat dan tidak menyakitkan.

Bos Anda mungkin bertanya: Apa imbalan bagi perusahaan untuk semua pekerjaan itu lagi?

Pilihan lainnya adalah kita membiarkan tampilan ini dinamai tbl_ dan tidak menghabiskan semua waktu menguji, memperbarui, dan menggunakan kode. Yang menjadi anekdot lucu yang Anda jelaskan kepada semua karyawan baru, dan mereka yang memiliki rentang perhatian pendek, yang harus bekerja dengan database tentang mengapa Anda tidak konsisten dengan penamaan objek

Atau Anda tidak menggandakan objek penyandian dengan metadata berlebihan. Basis data dengan senang hati akan memberi tahu Anda apa itu tabel, apa itu tampilan, apa fungsi yang dihargai tabel, dll.

Konvensi penamaan itu bagus, tapi jangan sampai Anda menyudutkannya.

Brent di sini (pria yang Anda maksudkan dalam pertanyaan).

Alasan saya memberitahu Anda untuk tidak menambahkan tbl ke depan nama tabel Anda adalah alasan yang sama saya mengatakan untuk tidak menambahkan anak ke depan nama anak Anda. Anda tidak memanggil mereka childJohn dan childJane. Tidak hanya itu tidak menambah nilai, mereka mungkin bukan anak di kemudian hari - dan objek Anda nantinya bisa menjadi pemandangan.

Ini adalah argumen yang sangat subyektif, tapi inilah pendapat saya: awalan tbl tidak berguna.

Berapa banyak skenario yang Anda lihat pada kode dan Anda tidak dapat mengetahui apakah ada tabel atau sesuatu yang lain?

Nilai apa yang tbl tambahkan kecuali bahwa ketika Anda melihat daftar tabel di Object Explorer, Anda harus melakukan lebih banyak pekerjaan untuk menemukan yang Anda cari?

Beberapa orang mengatakan ingin membuatnya jelas dalam kode mereka ketika mereka berhadapan dengan tabel atau tampilan. Mengapa? Dan jika ini penting, mengapa tidak hanya menamai tampilan dengan cara khusus? Dalam kebanyakan kasus, mereka bertindak seperti tabel, jadi saya melihat sedikit nilai dalam membedakan.

Ini adalah praktik yang mengerikan.

tbl
tbl_
Table_
t_

... melihat mereka semua dalam produksi.

Salah satu produk yang saat ini saya tangani memiliki setengah dari tabel yang disebutkan tbl_whatever, dan setengah lainnya bernama "normal" - Mereka jelas memiliki pengembang yang bekerja dengan standar yang berbeda. Salah satu kebiasaan buruk mereka adalah awalan nama kolom yang merupakan kunci asing fk, diikuti dengan nama tabel, fkkemudian nama kolom, memberikan nama kolom yang mengerikan seperti fktbl_AlarmsfkAlarmsID. Konvensi pemberian nama itu hanyalah perpanjangan logis dari keseluruhan tbl_%mantra, dan Anda dapat melihat betapa konyolnya hal itu!

Saya hampir lupa tentang database lain yang membuat saya menangis setiap hari. Datatypes nama kolom awalan ... dtPaymentDate, karena nama tersebut benar-benar membutuhkan dtawalan? `

com. Jangan verListen persiapan. Mengeset. Mengesetnya. Tidak ada orang lain. proYou auxShould Advallways verUse nouPrefixes prepWith proNour adjTable nouNames. proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting.

comLihat advIktifitas proI verIs adjEffective? nouPeople auxCan verUnderstand proYou nouWriting adjBetter!

Menggunakan awalan seperti ini dikenal sebagai Notasi Hongaria . Premisnya sederhana: Anda dapat menentukan apa sesuatu dengan bagaimana namanya. Ini khususnya umum dalam bahasa pemrograman, terutama ketika pengembang menulis fungsi monolitik yang menjangkau puluhan halaman, baik karena kurangnya keterampilan atau kurangnya fitur bahasa. Ini adalah bantuan mnemonik yang membantu pengembang menjaga tipe data tetap lurus.

Secara umum, gaya penamaan ini mungkin digunakan dalam kode yang benar-benar lama, atau oleh pengembang yang baru belajar (dan kebetulan mempelajari kebiasaan ini), atau telah melakukannya selama mereka dapat mengingatnya. Dalam pengalaman saya, saya telah mengamati bahwa relatif jarang untuk melihat notasi Hungaria bermunculan secara spontan dengan pengembang yang tidak berpengalaman jika mereka tidak diperkenalkan dengan kursus pemrograman atau tutorial; mereka lebih cenderung menggunakan nama variabel seperti i atau x atau acct .

Selain melukis diri sendiri ke sudut, ini benar-benar hanya pengisi. Sintaks SQL cukup tepat sehingga pengembang harus selalu tahu jika mereka berbicara tentang bidang, catatan, atau kumpulan data (yang mungkin berupa tabel, tampilan, dll.). Meskipun ini bisa menjadi alat bantu mengajar yang hebat, sintaksis ini biasanya tidak seharusnya ada dalam database produksi. Ini dapat merusak keterbacaan, dan membuatnya lebih sulit untuk menemukan tabel yang Anda cari, terutama jika beberapa tema alternatif penamaan muncul, seperti tbl vs. table vs. tab , dll.

Basis data tidak terlalu peduli apa yang Anda sebut tabel, bidang, dll. Itu hanya byte data yang diatur dalam urutan tertentu oleh operator manusia atau skripnya. Namun, manusia yang harus menjaga data ini akan menghargai nama yang bermakna, seperti "pengguna", "pesanan", dan "akun". Ini juga lebih praktis jika Anda menggunakan kueri SQL, seperti "tampilkan tabel seperti 'a%'". Menggunakan awalan dan sufiks dapat menyulitkan pemeliharaan yang tidak perlu.

Saya telah membaca beberapa posting blog seperti ini atau ini (ada beberapa) setelah saya mewarisi SQL Server Instance pertama saya dan melihat banyak objek di mana diawali, saya ingin mulai mengembangkan yang baru dengan pendekatan yang kurang verbose dan konvensi penamaan tunggal ( jauh lebih mudah bagi saya untuk [ dan mungkin pengembang lain ] bekerja pada Pemetaan Relasional Objek).

Salah satu awalan yang paling banyak digunakan adalah Tblatau tbl, tapi kemudian aku punya TBLdan tbl_bahkan*TableName*_Tbl

Saat mencoba melakukan query dan bekerja dari Visual Studio ini hanya neraka, saya tidak masalah memiliki seluruh set tabel yang diawali, tbltapi tolong tetap seperti itu untuk seluruh Database, setidaknya.

Jadi pada akhirnya saya akan mengatakan adalah masalah preferensi pribadi tetapi juga banyak hubungannya dengan konsistensi dan jika Anda menyusuri jalan itu, banyak orang akan senang setidaknya Anda tetap sama di sepanjang perkembangan Anda.

... Di sisi lain saya hanya ingin mengatakan, jika Anda mengambil pendekatan lain dan menggunakan tabel non-awalan, nama tunggal, Anda akan membuat pengembang senang di masa depan, dan apa yang lebih penting daripada kebahagiaan?

Ya, menambahkan awalan yang menunjukkan jenis objek adalah masalah, dan tidak perlu . Karena,

1. Terkadang objek memulai kehidupan sebagai sesuatu tetapi akhirnya akan menjadi sesuatu yang lain . (mis. tabel tblXxxdipecah menjadi tblXxxYdan tblXxxZuntuk beberapa alasan dan diganti dengan tampilan yang menggabungkan dua tabel baru. Sekarang Anda memiliki tampilan yang disebut tblXxx).
2. Saat Anda mengetik tbldi editor, fitur AutoComplete-nya hang selama 45 detik dan kemudian menunjukkan daftar 4000 entri.

Tapi...

Aku akan berperan sebagai advokat iblis dan mengatakan sesuatu yang secara langsung dinasihati oleh orang lain. Ada beberapa kasus langka yang sufiks / awalan bisa berguna, dan inilah contoh dari organisasi tempat saya bekerja.

Kami memiliki sistem ERP berbasis entitas, di mana logika bisnis ditulis dalam Oracle PL / SQL. Sudah hampir dua dekade, namun sistem yang sangat stabil (Ini bukan sistem warisan. Kami terus mengembangkannya).

Sistem berbasis entitas, dan setiap entitas mengaitkan tabel, banyak tampilan, beberapa paket PL / SQL, dan sejumlah objek database lainnya.

Sekarang, kami ingin objek milik entitas yang sama memiliki nama yang sama tetapi belum dapat dibedakan dari tujuan dan jenisnya. Jadi, jika kita memiliki dua entitas yang dinamai CustomerOrderdan CustomerInvoice, kita akan memiliki objek berikut:

1. Tabel untuk menyimpan data [ TABsuffix]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Tampilan yang digunakan oleh klien [Tanpa akhiran]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Antarmuka untuk operasi dasar; (Paket PL / SQL) [ APIakhiran]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Laporkan generator; (Paket PL / SQL) [ RPIakhiran]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Indeks untuk kunci primer [ PKakhiran]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Indeks sekunder [ IXakhiran]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(di mana XXXmenggambarkan penggunaan indeks).
7. ... dan seterusnya.

Ini memang bentuk Aplikasi Hungaria (perhatikan bahwa jenis objek yang sama dapat memiliki akhiran yang berbeda tergantung pada tujuannya). Tapi, dengan akhiran bukan awalan. Saya tidak bisa memberi tahu Anda cukup bagaimana sistem ini begitu mudah dibaca. IntelliSense sebenarnya berfungsi karena alih-alih mengetik TBLdan mendapatkan 4000 hasil, saya bisa mengetik Customerdan mendapatkan semua objek milik entitas yang bernama Customer*.

Jadi, di sini saya telah menunjukkan kepada Anda bagaimana metadata dapat bermanfaat. Tujuannya adalah untuk memiliki satu set objek database terkait yang dapat diidentifikasi dengan satu nama, namun membedakannya berdasarkan tujuannya .

Karena itu, jika Anda tidak memiliki sistem semacam ini, tidak ada penggunaan awalan atau akhiran jenis objek .

Perhatikan bahwa kita tidak menggunakan akhiran seperti _table, _package, atau _view(yaitu jenis objek). Sebagai contoh, keduanya (3) dan (4) adalah paket PL / SQL, namun menggunakan akhiran yang berbeda. Sama untuk (5) dan (6), keduanya merupakan indeks. Jadi sufiks didasarkan pada tujuan dan bukan tipe .

tl; dr It (sangat mungkin) menambahkan informasi yang berlebihan, yang mengarah ke overhead kognitif, dan karenanya harus dihapus.

Konteks adalah hal yang luar biasa, terutama dalam sistem komputer. Di luar konteks Anda tidak mungkin mengetahui apakah sesuatu yang dipanggil usersadalah tabel, tampilan, prosedur tersimpan atau sesuatu yang lain sama sekali. Sistem dan bahasa Warisan (atau ditulis dengan buruk) seringkali menyulitkan untuk memahami konteksnya saat membaca kode. Misalnya, di Bash, Anda tidak dapat mengetahui apa yang function usersdilakukannya tanpa setidaknya membaca konten fungsi. Di Jawa, Map<Uid,UserDetails> users()cukup transparan, dan Anda dapat menggali detailnya dengan mudah.

Mengambil argumen ini ke tabel SQL, kapan akan berguna bagi konsumen usersuntuk mengetahui apakah itu tabel atau tampilan? Dengan kata lain, apakah tblawalan akan memberi tahu salah satu konsumen sesuatu yang tidak mereka ketahui dan perlu ketahui?Semoga sebagian besar konsumen akan menulis permintaan DML dan DQL menentangnya. Bagi mereka itu harus hanya sumber data lain, dan apakah itu tampilan atau tabel harus sama relevannya dengan apakah itu dipartisi, disimpan dalam HDD atau SSD, atau detail teknis lainnya. DBA tentu saja perlu mengetahui detail ini untuk menjalankan beberapa permintaan DDL / DCL yang jarang, tetapi tampaknya kontraproduktif untuk mencemari namespace demi minoritas yang benar-benar tahu cara menavigasi skema dan mendapatkan semua detail teknis.

Salah satu fitur dari sistem manajemen basis data relasional adalah bahwa ia memisahkan penyajian informasi secara logis kepada klien dari penyimpanan fisik. Yang pertama adalah kolom dalam rowset. Yang terakhir adalah sebagai file pada volume penyimpanan. Adalah tugas DBMS untuk memetakan satu ke yang lain. Ini hanya masalah DBA atau sysadmin yang perangkat kerasnya mendukung kebutuhan informasi. Konsumen tidak perlu, memang tidak seharusnya, menyadari kekhawatiran tersebut.

Klien juga tidak perlu khawatir tentang bagaimana rowset dibangun. Tabel dasar, tampilan atau fungsi semuanya, dalam hal ini, identik. Masing-masing hanya menghasilkan satu set baris dan kolom yang dikonsumsi klien. Bahkan skalar sederhana dapat dianggap sebagai tabel satu baris, satu kolom. Model baris / kolom adalah kontrak antara klien dan server.

Dengan mengawali nama artefak dengan jenis implementasinya, pemisahan masalah ini terputus. Klien sekarang sadar dan tergantung pada internal server. Perubahan dalam pengkodean server mungkin membutuhkan klien untuk bekerja kembali.

Ada banyak jawaban di sini yang saya setuju dengan yang memberi tahu Anda bahwa ini bukan konvensi penamaan yang sangat berharga. Bagi orang-orang yang tidak yakin dengan jawaban lain, saya akan mencoba menunjukkan apa yang dikatakan oleh banyak jawaban lain.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

Dalam pernyataan di atas saya memilih tiga kolom dari sesuatu yang bernama dbo.foo. Salah satu keluhan inti dari awalan adalah bahwa mereka tidak tahu apakah dbo.fooitu tabel atau tampilan. Tentu saja itu adalah salah satu kekuatan pandangan sebagai abstraksi, tetapi saya ngelantur. Mereka mengatakan kita harus mengawali objek seperti ini dbo.tblFoo. Sekarang mereka dapat melihat bahwa objeknya adalah sebuah tabel (mungkin) dalam kueri di atas. Namun jika kita menulis fungsional yang setara dengan tujuan itu akan terlihat seperti ini.

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

Saya menduga bahwa komentar terlihat kurang berguna meskipun itulah yang secara efektif diperdebatkan oleh para awalan. Untuk menyoroti kebisingan yang tidak berguna, komentar data meta ini menyuntikkan mempertimbangkan pertanyaan yang lebih rumit.

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;

Apakah komentar tambahan membuat kueri itu lebih mudah untuk dipikirkan atau mereka hanya menambahkan suara tambahan? Menurut pendapat saya mereka hanya menambah noise ekstra dan menambahkan nilai nol. Itulah yang ingin dikatakan oleh para anti-awalan. Lebih jauh lagi menggunakan awalan sebenarnya lebih buruk daripada komentar itu karena biaya memperbarui komentar jauh lebih rendah daripada memperbarui nama tabel awalan jika model data Anda perlu disesuaikan. Karena awalan-awalan ini berbiaya dan tidak memberikan informasi yang berharga, mereka harus dihindari.

Keuntungan lain dari awalan yang dikutip beberapa orang adalah dapat memberikan semacam pengelompokan atau pemesanan di lingkungan pengembangan Anda. Karena kita menghabiskan banyak waktu untuk mengedit kode, ini bisa menjadi argumen yang menggoda bagi sebagian orang. Namun dalam pengalaman saya, lingkungan pengembangan modern memberikan opsi yang setara atau unggul yang tidak membuang kode Anda dengan data meta yang tidak berguna dan membatasi fleksibilitas Anda.

Ini telah dibahas berulang kali, tetapi mungkin yang paling terkenal adalah Joe Celko , seorang ahli SQL Amerika dan basis data relasional. Saya pribadi berada di ujung penerima salah satu kata-katanya secara online (merasa terhormat), dan dia berbicara tentang awalan-awalan ini sebagai "omong kosong", atau lebih tepatnya digambarkan sebagai " skeuomorphism ".

Gagasan umum adalah bahwa awalan-awalan ini adalah praktik pengkodean dari dulu (mungkin karena batasan penamaan, seperti batas 8 byte untuk nama-nama objek), diturunkan dari generasi programmer tanpa alasan yang jelas berguna, selain itu hanya "jalan" itu selesai ".

Perusahaan, blogger, dan pemrogram menyampaikan informasi dengan gaya pengkodean mereka sendiri, dan beberapa gaya mungkin sedikit lebih "Frankenstein" daripada yang lain. Sebuah perusahaan mungkin memiliki "gaya rumah", dan programmer dipaksa untuk mempelajari praktik ini.

Seiring waktu hal-hal tetap, bahkan jika alasan mereka digunakan awalnya sekarang sudah usang. "Tibbling" adalah salah satu contoh paling terkenal dari hal ini dalam manajemen basis data relasional.

Untuk mengumpulkan: itu tidak menambah nilai, itu menambahkan tepat 4 byte ruang penyimpanan pada setiap nama tabel tanpa alasan selain karena itu ada di sana. Ini tidak menawarkan apa pun untuk sistem SQL Server modern, tetapi jika itu membuat Anda merasa lebih baik memilikinya di sana, silakan dan gunakan.

Saran saya adalah agar Anda segera berhenti melakukan ini. Jika ini membuat Anda merasa tidak nyaman untuk maju, tambahkan "_tbl" di akhir nama tabel Anda. Tentu saja karena alasan yang telah disebutkan, tidak perlu melakukan itu juga. Orang yang semula menyuruh Anda melakukan itu memberi Anda beberapa nasihat buruk. Ini mungkin buruk "ini masuk akal dalam hal sistem pengaturan organisasi kami yang buruk", tetapi dalam kasus itu adalah tugasnya untuk memperbaikinya. Saran yang masih buruk.

Apakah "Jangan awali meja Anda dengan tbl" benar-benar masalah?

Mengenai sistemnya? Tidak. Mengenai orang lain? Mungkin. Anda dapat menghasilkan banyak kebencian.

Saya pribadi tidak membuat awalan tabel tetapi melakukannya pada objek lain seperti tampilan, prosedur tersimpan, fungsi, dll.

Saya harus mengatakan tolong berhenti melakukan ini. Itu telah terjadi di masa lalu, tetapi dengan terus melakukan ini Anda mendorong orang-orang baru yang datang ke lingkungan Anda untuk berpikir itu adalah konvensi lokal dan berlanjut. Tetapi mereka tidak akan hanya melanjutkan, mereka akan melakukannya sedikit berbeda

Ketika mengambil db untuk item tertentu, dan saya bukan satu-satunya yang akan membuka objek explorer dan hanya berpikir saya akan gulir ke sana, Anda tahu itu abjad. Itu sampai awalan mulai mengeruhkan air, dan saya punya tblname, tbl_name, tbname, t_name, dan seribu variasi lainnya, menjadi sangat sulit untuk menemukan tabel yang Anda tahu sudah berupa tabel

Demikian juga awalan segala sesuatu vw_ atau sp_, seseorang akan masuk dan Anda akan mendapatkan SPname, spname, s_p_name. Hapus semua awalan, perangkat lunak tahu item apa itu, jika Anda benar-benar perlu tahu, gunakan sufiks sebagai gantinya. NameOfMyView_v, NameOfMyProc_sp. lebih mudah untuk mencari secara visual

Tetapi bagaimana jika Anda menjepret proc yang sudah lama disimpan dan tidak bisa dengan mudah mengatakan apa itu view proc atau tabel? Yah kemungkinannya adalah bahwa ini akan tetap alias, dan bahkan jika tidak sufiks datang untuk menyelamatkan Anda

Jangan takut mengubah apa yang Anda lakukan, dan jika Anda berjalan ke lingkungan di mana konvensi penamaan sudah siap, jangan takut untuk mengimplementasikan sendiri, dan mulai mengubah hal-hal menjadi lebih baik. Dengan mencocokkan kekacauan yang ada, tidak ada kesempatan untuk membuatnya tidak membingungkan, hanya membuatnya lebih jadi

Jika saya harus memikirkan keuntungan memiliki awalan 'tbl', itu adalah bahwa dalam SSMS saat ini, dengan intellisense, saya cukup mengetik

select * from tbl

dan kemudian menemukan nama tabel yang saya butuhkan (dengan asumsi saya tidak tahu tentang nama tabel yang tepat). Ini adalah pekerjaan satu langkah. Tentu saja, kita selalu dapat mengetahui nama tabel melalui langkah-langkah tambahan, tetapi saya akan mengatakan bahwa dengan awalan 'tbl', ini adalah SATU langkah kerja, dan itulah sebabnya saya selalu lebih memilih awalan (tidak harus 'tbl') di proyek pekerjaan rumah saya sendiri.

Sunting : (Setelah begitu banyak suara turun, saya masih berpikir ada baiknya menunjukkan beberapa keunggulan ceruk memberikan awalan spesifik untuk kategori objek tertentu di server sql). Tampaknya tidak ada yang mengeluh memiliki awalan untuk prosedur / fungsi / tampilan tersimpan, tetapi selalu ada argumen tentang melakukannya dengan tabel. (Bagi saya, di dunia nyata saya tidak peduli apakah kita memberikan awalan atau tidak ke tabel).

Saya ingat di sql server 2005 hari, ada persyaratan untuk menemukan tabel apa yang digunakan di mana disimpan prosedur / tampilan, dengan nama tabel diawali, itu adalah pekerjaan yang mudah dengan Regular Expression / C #. (Ya, saya tahu ada cara lain, tidak ada argumen di sini).

Karier saya tumbuh dengan banyak membaca makalah / artikel "praktik terbaik", tetapi saya juga telah melihat cukup banyak pengecualian untuk hampir setiap "praktik terbaik" dengan berbagai cara dalam skenario yang berbeda. Jadi, saya selalu berkata pada diri sendiri dan rekan-rekan DBA saya, membuat penilaian sesuai dengan persyaratan bisnis, "praktik terbaik" pasti ada tempatnya, tetapi hanya dapat dipertimbangkan dalam konteks lingkungan kita sendiri.

Pertimbangkan dbo.Uservs dbo.tUser. Sekarang bayangkan Anda ingin menemukan semua tempat dalam kode yang digunakan tabel ini. Versi mana yang membuat ini lebih mudah (atau bahkan mungkin?) Kata "pengguna" cenderung memiliki banyak positif palsu, seperti nama variabel, dalam komentar, dll.

Itu adalah sesuatu yang belum saya lihat di jawaban lain mana pun, tapi saya adalah pengembang-cum-DBA, jadi mungkin orang lain tidak harus mengerjakan kode warisan, di mana kueri dapat dimasukkan ke dalam aplikasi, dan tidak semua kueri sepenuhnya memenuhi syarat referensi dengan skema, dan hal-hal seperti itu. (Bahkan jika semuanya sepenuhnya memenuhi syarat, Anda perlu menemukan dbo.Userdan [dbo].[User]dan dbo.[User]dan sebagainya). Atau versi database di mana "informasi ketergantungan" menjadi basi dan tidak akurat (misalnya versi MS-SQL yang lebih lama)

Jadi, pada beberapa proyek yang saya kerjakan, yang dicampur seperti itu, saya mengamanatkan tatau vawalan (tbl_ menjadi konyol), hanya untuk membuatnya menjadi istilah pencarian yang lebih selektif.

Dalam proyek selanjutnya, dengan hal-hal seperti Alat Data SQL Server (halo, Temukan Semua Referensi), dan akses database secara eksklusif melalui lapisan ORM, tidak ada utilitas, karena menemukan semua penggunaan tabel itu sepele (seperti menamai ulang itu!)

Masing-masing pihak memiliki kelebihan dan kekurangannya. Terserah pimpinan tim atau perusahaan Anda untuk memutuskan konvensi untuk diikuti.

Kami, misalnya, menggunakan tblkonvensi. Alasan utamanya adalah bahwa kita tahu dalam skrip apa yang bisa dan tidak seharusnya kita lakukan. Kami memiliki beragam proyek dan orang-orang yang melompat masuk tanpa mengetahui skema tersebut. Tabel kami memiliki nama logis, sehingga mudah untuk menemukan jalan Anda saat menulis skrip. Saat melakukannya, ketika kami menemukan sebuah meja, kami segera tahu (melalui IntelliSense) bahwa itu adalah sebuah meja. Orang bisa berpendapat bahwa menambahkan awalan tidak menambah banyak konteks. Namun, menghapusnya berarti tidak ada konteks.

Satu-satunya keuntungan nyata dari tidak menggunakan awalan adalah pertukaran. Namun, saya berpendapat ini adalah situasi yang berpotensi berbahaya. Tentu, skrip dan kueri Anda tidak akan rusak, tetapi mungkin Anda mulai terlalu mengandalkan fakta itu, sementara beberapa hal tidak berfungsi dengan pandangan atau tidak disarankan.

Pada akhirnya itu hanya bermuara pada apa yang tim Anda sukai dan bagaimana ia menulis kode / skrip.

Saya dulu punya alasan untuk awalan nama tabel dengan "tbl". Jika Anda melihat daftar objek database, Anda dapat menjalankan kueri ini:

select * from sysobjects

Jika Anda hanya ingin mendapatkan tabel, Anda bisa melakukan ini:

select * from sysobjects where type = 'U'

Siapa yang bisa mengingat itu? Jika semua nama tabel Anda dimulai dengan "tbl", Anda dapat menggunakan kueri ini yang tidak mengharuskan Anda untuk menghafal nilai-nilai kolom tipe:

select * from sysobjects where name like 'tbl%'

Karena Anda menandai SQL Server 2014, ini tidak berlaku untuk Anda karena pada SQL Server 2005, Anda dapat melakukan ini sebagai gantinya:

select * from sys.tables

Saya tidak bisa memikirkan alasan lain untuk awalan nama tabel.