Saya sedang dalam diskusi permanen dengan pengembang perusahaan tempat saya bekerja karena mereka mengatakan lebih baik untuk menyingkirkan penegakan hubungan (melalui definisi batasan KUNCI ASING) dalam database relasional untuk mempercepat permintaan besar dan untuk mendapatkan lebih baik kinerja.

Platform yang dipertimbangkan adalah MySQL 5.x, dan tidak ada KUNCI LUAR NEGERI yang telah diatur, bahkan beberapa kendala KUNCI UTAMA dari tabel yang relevan hilang yang, setidaknya bagi saya, tidak masuk akal. Mungkin mereka benar dan saya salah, tetapi saya tidak punya cukup argumen untuk membahas tentang situasi ini.

Ini telah menjadi pendekatan yang disukai selama tiga tahun sekarang. Saya baru di perusahaan ini (hanya satu bulan) tetapi, karena produk “bekerja”, ada keraguan untuk meningkatkan basis data; Namun, hal pertama yang saya perhatikan adalah satu halaman membutuhkan waktu 1 menit untuk memuat (ya, 60 detik!).

Salah satu klaim di balik keadaan saat ini adalah bahwa database yang "didenormalisasi" lebih cepat daripada yang dinormalisasi, tetapi saya tidak percaya itu benar.

Sebagian besar pertanyaan yang relevan termasuk operasi BERGABUNG, yang membuatnya berjalan sangat, sangat, sangat lambat dengan sejumlah besar data (database berisi jutaan baris).

Umumnya, penanganan operasi "CRUD" diimplementasikan pada tingkat kode program aplikasi; misalnya, untuk MENGHAPUS beberapa data DARI, katakanlah TableA:

• perlu terlebih dahulu memeriksa dengan cepat jika ada hubungan antara baris TableAdanTableB ,
• jika hubungan tersebut “terdeteksi”, maka kode program aplikasi tidak akan memungkinkan untuk MENGHAPUS baris yang bersangkutan, tetapi
• jika karena alasan tertentu kode program aplikasi gagal, maka operasi DELETE akan “berhasil”, tidak peduli apakah ada hubungan apapun terkait dengan baris dan tabel yang terlibat.

Pertanyaan

Bisakah Anda membantu saya menguraikan jawaban yang baik, akurat, dan solid untuk memperkaya debat?

_{Catatan : Mungkin sesuatu seperti ini telah ditanyakan (dan dijawab) sebelumnya, tetapi saya tidak dapat menemukan apa pun melalui Google.}

Jika, seperti yang dinyatakan dalam posting Anda, maksudnya adalah untuk membuat relasional database yang (RDB untuk singkatnya) dan, oleh karena itu, diharapkan bahwa fungsi seperti itu, jawaban singkat adalah:

• Tidak, Anda tidak boleh mengabaikan kendala integritas data .

Tujuan utama adalah untuk mengelola data terkait sebagaimana adanya, aset organisasi yang cukup berharga, dan cara yang dapat diandalkan untuk mencapai tujuan tersebut adalah menggunakan cara teknis yang didukung oleh teori yang kuat.

Dengan demikian, sebagai profesional basis data, Anda dapat memanfaatkan mekanisme model relasional canggih dan elegan yang disediakan oleh Dr. EF Codd untuk menegakkan aturan bisnis, dan menghindari masalah yang pada akhirnya akan muncul jika tidak digunakan.

Dalam hal ini, saya akan berbagi (a) keseluruhan saya mengambil kendala dan juga (b) beberapa pertimbangan tentang keadaan urusan database dan lingkungan kerja yang dipermasalahkan sebagai berikut.

Kendala KUNCI ASING, hubungan data, dan integritas referensial

RDB harus mencerminkan karakteristik konteks bisnis yang diminati dengan akurasi tinggi, yang tentunya membutuhkan analisis level konseptual mendalam yang dipimpin oleh seorang pemodel atau desainer yang mengikuti praktik terbaik, menghitung dengan bantuan yang sangat diperlukan dari para pakar bisnis. Analisis itu harus menghasilkan identifikasi dan perumusan aturan bisnis yang berlaku .

Akibatnya, jika pemodel seperti itu telah mengidentifikasi bahwa ada keterkaitan antara data relevansi, ia harus mengkonfigurasi batasan tingkat logis yang sesuai sehingga sistem manajemen basis data (DBMS) dapat menjamin bahwa data tetap konsisten dengan karakteristik yang tepat dan aturan yang ditentukan dalam analisis yang disebutkan di atas setiap saat .

Mengenai database yang sedang dibahas, orang dapat menyimpulkan bahwa hubungan timbal balik yang relevan telah diidentifikasi, karena Anda menyebutkan bahwa ada upaya prosedural (dan mudah untuk menghindari) untuk menegakkan mereka dari luar fasilitas DBMS, dengan kode program aplikasi (yang adalah pendekatan pra-relasional) yang dalam hal apa pun harus "menyentuh" ​​database untuk mencoba memvalidasi keutuhan hubungan timbal balik tersebut.

Namun, seperti yang Anda ketahui, itu bukan teknik yang optimal untuk melindungi integritas referensial , karena ilmu pengetahuan relasional telah menetapkan instrumen yang sangat kuat untuk tujuan ini, yaitu kendala FOREIGN KEY (FK). Kendala ini sangat mudah dibuat (melalui pendekatan deklaratif superior) karena merupakan kalimat tunggal yang menghindari penggunaan prosedur ad hoc yang tidak perlu dan rawan kesalahan. Sangat berguna untuk mencatat bahwa kecepatan pelaksanaan kendala FK telah sangat dioptimalkan oleh programmer khusus (dan vendor platform utama telah bekerja di dalamnya selama beberapa dekade sekarang).

Selain itu, karena RDB harus merupakan komponen perangkat lunak independen (proteksi diri, menggambarkan sendiri, dll.) Yang dapat diakses oleh beberapa program aplikasi (desktop, otomatis, web, seluler, kombinasi daripadanya), RDB tidak boleh "Ditambah" dengan kode dari salah satu aplikasi ini.

Demikian juga, data — yang menjadi sumber daya organisasi yang signifikan — secara alami cenderung hidup lebih lama dari program aplikasi, pemrogram aplikasi, platform pengembangan aplikasi dan paradigma pemrograman.

PRIMARY KEY kendala dan implikasi dari baris duplikat

Ketika -conceptually berbicara-tertentu jenis hal telah dianggap penting dalam lingkungan bisnis, pembuat model database memiliki untuk (1) menentukan karakteristik yang relevan -yaitu, properties- nya, konfirmasi kata semacam itu sebagai contoh entitas prototipe - yaitu, tipe entitas— dan (2) melambangkannya dengan cara tabel yang diintegrasikan oleh satu atau lebih kolom dalam desain logis.

Kemudian, sama pentingnya untuk membedakan setiap instance individu dari tipe entitas yang diberikan di dunia nyata, setiap baris yang dilampirkan dalam tabel juga harus dibedakan secara unik. Jika sebuah tabel tidak memiliki KEY yang dideklarasikan, pada akhirnya akan mempertahankan duplikat, dan jika ada dua atau lebih baris yang mempertahankan nilai yang persis sama, maka mereka semua membawa makna yang sama , mereka semua mewakili fakta yang sama .

Pada titik itu, baris duplikat harus dibuang karena beberapa alasan. Dari perspektif teoretis, perancang harus memastikan bahwa setiap baris selalu unik untuk tujuan memiliki tabel yang bekerja sama eratnya dengan izin sub-bahasa data SQL (memiliki dampak penting pada operasi manipulasi data). Selain itu, dari perspektif informasi, jika beberapa baris mewakili fakta yang sama, rekaman mereka tidak hanya berlebihan tetapi juga berbahaya , seperti yang dicontohkan di bawah ini:

• Misalkan seseorang telah menyisipkan dua baris identik dalam tabel tertentu.
• Kemudian, orang lain datang dan memperbarui hanya satu kejadian duplikat. Akibatnya, kejadian lainnya tidak mutakhir lagi.
• Secara berturut-turut, orang lain memperbarui kejadian yang belum dimodifikasi sejauh ini. Dengan cara ini, kedua duplikat telah mengalami perubahan yang berbeda pada titik waktu yang berbeda.
• Setelah itu, ketika seseorang tertarik untuk memilih informasi yang disampaikan oleh baris yang bersangkutan, ia dapat menemukan dua "versi" yang berbeda.

Lewat sini:

• "Versi" mana yang bisa dianggap benar dan andal?
• Mana yang mencerminkan dunia nyata secara akurat?

Seperti yang Anda ketahui, fenomena ini bahkan dapat memiliki implikasi hukum, suatu keadaan yang tentunya sangat penting.

Selain itu, waktu dan upaya yang harus digunakan untuk menangani kontradiksi semacam itu (mungkin melalui semacam "pembaruan sinkronisasi") harus lebih baik digunakan untuk tugas-tugas yang benar-benar menghasilkan nilai bagi organisasi Anda. Jadi, mempertahankan baris yang kontradiktif harus dihindari dengan desain untuk menjaga konsistensi database tetap utuh.

Itulah mengapa identifikasi KUNCI UTAMA (PK) dan pernyataan batasan masing-masing harus selalu dilakukan oleh perancang basis data. Tetapi harus disebutkan juga bahwa sebuah tabel dapat memiliki lebih dari satu kolom atau kombinasi kolom yang memiliki nilai yang secara unik mengidentifikasi setiap baris; sebagai konsekuensinya, selain menetapkan batasan PK (idealnya ditetapkan sebagai PRIMER karena alasan pragmatis), perancang harus juga mendeklarasikan satu atau lebih KUNCI ALTERNASI (biasanya didefinisikan melalui satu atau lebih kendala UNIK dan BUKAN NULL) ketika berlaku (yang merupakan cukup umum).

Properti lain yang menguntungkan dari PK adalah bahwa, ketika "bermigrasi" ke meja lain untuk mengambil bagian dalam FK tunggal atau komposit, mereka dapat membantu untuk menegakkan rasio kardinalitas dari hubungan yang ada di antara data. Semua ini, ya, melalui pengaturan deklaratif yang sederhana dan efisien, dijamin oleh DBMS.

(Saat ini) PERIKSA kendala dan validasi baris tunggal

Mari kita tidak melupakan relevansi dari batasan (saat ini) PERIKSA yang, membatasi secara deklaratif set nilai kolom yang valid dari suatu baris (yang mungkin tampak sederhana, tetapi sebenarnya merupakan fitur mendasar dari DBMS relasional), membantu juga membuat yakin bahwa aturan konteks bisnis tercermin dengan presisi setiap saat.

Ketika Anda menandai pertanyaan Anda dengan tag MySQL, harus disebutkan bahwa, sayangnya, platform semacam itu mengizinkan pernyataan semacam kendala tetapi, pada saat yang sama, mengabaikan penegakannya! , situasi yang, dapat dimengerti, dilaporkan sebagai bug sejak 2004 .

Dalam hal ini, Anda harus menjaga faktor ini dengan cara lain, misalnya, TRANSAKSI ASAM , PEMICU, atau metode lain di dalam DBMS itu sendiri (lihat jawaban ini oleh @ ypercubeᵀᴹ untuk informasi tentang hal ini) sehingga data terus berlanjut. konsistenlah.

Batasan ASSERTION: menyiapkan aturan bisnis multi-baris dan multi-tabel lebih lanjut secara deklaratif

Salah satu aspek yang karena alasan apa pun sangat kurang didukung - jika sama sekali - oleh SQL DBMSs yang berbeda, termasuk MySQL, adalah memungkinkan multi-baris dan multi-tabel kendala secara deklaratif - di luar PK dan FK, jelas-.

Untuk bagiannya, standar SQL tidak menyertakan ASSERTIONs dari bertahun-tahun sekarang. Saya tidak tahu aturan apa dari lingkungan bisnis Anda yang akan mendapat manfaat dari pendekatan validasi tingkat logis itu, tetapi, sebagai perancang basis data, saya menganggap bahwa akan sangat berguna untuk membatasi data dengan satu atau lebih ASSERTIONs, walaupun saya harus menyebutkannya dari Dari sudut pandang pengembang DBMS, alat terpenting ini sulit diterapkan pada tingkat fisik abstraksi.

Tampaknya vendor dan / atau pengembang Oracle sedang mengevaluasi dukungan ASSERTION sejak 2016, dan itu akan membuat DBMS lebih patuh-hubungan dan, karenanya, lebih kuat dan kompetitif. Saya kira, jika (i) konsumen mereka terus mendorong dan (ii) Oracle berhasil dalam implementasi, maka (iii) vendor / komunitas DBMS lainnya harus memungkinkan mereka juga, dan penggunaannya akan mulai menyebar. Tentu saja, itu akan menjadi kemajuan besar dalam bidang manajemen basis data, dan menjadi salah satu alat paling khas yang dibayangkan oleh Dr. Codd, saya pribadi berharap bahwa kita akan segera melihat hal itu terjadi.

Konsistensi data dan proses pengambilan keputusan

Sebagaimana dibahas di atas, salah satu aspek terpenting dari RDB adalah menjamin RDB dengan sendirinya konsistensi data yang disimpan, dan mengatakan konsistensi hanya terpenuhi ketika RDB mematuhi batasan integritas yang dinyatakan oleh pemodel.

Dalam hal ini, adalah wajib untuk memiliki tabel dasar (yang dibuat dalam struktur DDL) yang integritasnya dilindungi untuk dapat membuat tabel turunan (misalnya, pernyataan SELECT atau tampilan yang mengambil kolom dari beberapa tabel) yang dapat dipercaya. , karena tabel turunan harus diproduksi dalam hal tabel dasar.

Sudah diketahui umum bahwa orang menggunakan informasi sebagai alat utama dalam proses pengambilan keputusan organisasi (dan dalam biasa). Kemudian, jika informasi yang disajikan oleh database tidak koheren dan akurat, keputusan berdasarkan informasi tersebut tidak akan masuk akal (untuk sedikitnya). Itulah sebabnya RDB harus dirancang dan diimplementasikan dengan hati-hati: RDB harus dibangun untuk menjadi sumber daya yang andal yang dapat membantu penggunanya untuk membuat keputusan yang beralasan.

"Denormalisasi"

Sayangnya, "database yang 'didenormalisasi' lebih cepat daripada yang dinormalisasi" adalah kesalahpahaman yang tersebar luas, meskipun juga merupakan argumen yang dapat disangkal berdasarkan alasan logis, fisik dan pragmatis.

Pertama, denormalisasi menyiratkan bahwa tabel dasar sebelumnya telah dinormalisasi ( berdasarkan prosedur formal , berbasis sains, dipenuhi pada tingkat logis abstraksi dari database).

Jadi, dengan asumsi bahwa tabel tersebut dalam kenyataannya sebenarnya dinormalisasi dengan benar, "denormalized" itu (yang, berbeda dengan makna formal kata itu, melibatkan menambahkannya kolom yang termasuk dalam, dan juga merupakan bagian dari, tabel lain dalam iklan mode hoc ) dapat membantu, misalnya, untuk mempercepat (pada tingkat fisik) pemrosesan hanya satu atau beberapa pernyataan SELECT tertentu, sementara tindakan seperti itu mungkin, pada saat yang sama, akan merusak pelaksanaan banyak data terkait lainnya operasi manipulasi (misalnya, beberapa pernyataan INSERT, UPDATE, DELETE, dan SELECT, atau kombinasi dari keduanya terlampir dalam satu atau beberapa TRANSAKSI ASAM).

Selain itu, denormalisasi (baik formal maupun informal) akan memperkenalkan anomali pembaruan / modifikasi yang memperburuk koherensi basis data, masalah yang "mungkin" ditangani oleh prosedur yang rumit, mahal dan rawan kesalahan, ketika semua ini dapat dicegah dari sangat awal.

Perancah tingkat fisik mendukung tabel yang dinormalisasi dan "dinormalisasi"

Tata letak logis (abstrak) (desain SQL-DDL) yang dimaksudkan untuk digunakan di dunia nyata jelas memiliki dampak fisik (konkret) yang harus dipertimbangkan.

Dengan cara ini, tabel "dinonormalisasi" akan selalu "lebih luas" (memegang kolom tambahan) yang berarti bahwa barisnya akan lebih berat (membutuhkan komponen tingkat fisik yang lebih banyak dan lebih besar), sehingga itu berarti bahwa proses komputasi yang mendasarinya (misalnya , yang ada hubungannya dengan hard drive atau memori) dapat dengan mudah berubah lebih lambat.

Sebaliknya, tabel yang dinormalisasi yang tentu saja "lebih sempit" (memiliki lebih sedikit kolom) akan menjadi elemen "lebih ringan" (dilayani oleh komponen fisik yang lebih sedikit dan lebih kecil) yang "berperilaku lebih cepat", yang akan mempercepat serangkaian tindakan terkait dengan , misalnya, penulisan dan pembacaan data.

Karena itu, sangat nyaman untuk (a) menormalkan tabel yang relevan secara formal dan hati-hati, menjaganya seperti itu, dan kemudian (b) memanfaatkan sumber daya level fisik apa pun yang dapat mengoptimalkan pengambilan data dan kecepatan modifikasi, misalnya, menerapkan strategi pengindeksan yang cermat dan efisien, memungkinkan konfigurasi perangkat lunak dan server perangkat keras yang tepat, meningkatkan kemampuan bandwidth jaringan, dll.

Berfungsinya basis data dalam pertimbangan

Paragraf berikut dari pertanyaan Anda berkaitan dengan kecepatan pengambilan data:

[A] s produk "berfungsi", ada keraguan untuk meningkatkan database; namun, hal pertama yang saya perhatikan adalah satu halaman membutuhkan waktu 1 menit untuk memuat (ya, 60 detik!).

Jika memuat halaman tertentu mengambil banyak, jelas bahwa pengguna sistem tidak menerima layanan yang baik; oleh karena itu, bahkan ketika "bekerja", fungsinya tampaknya tidak optimal sama sekali, titik yang menunjukkan bahwa niat Anda untuk membuat seluruh lingkungan (database dan aplikasi) lebih efisien dipertahankan dengan baik, dan menunjukkan sikap yang sangat konstruktif.

Kemudian, bahkan ketika ilmu pasti mendukung Anda dan karenanya Anda harus mempertahankan postur yang tegas, saya sarankan mendekati situasi dengan cara diplomatik, karena pada akhirnya, majikan, kolega, dan Anda sendiri sedang BERGABUNG upaya untuk membuat seluruh organisasi lebih sukses. Dengan demikian, itu adalah salah satu argumen yang harus Anda tekankan, bahwa, sementara mereka melakukan hal-hal lain lebih baik, meningkatkan praktik manajemen data umum dan spesifik dapat sangat membantu dalam menghasilkan lebih banyak pertumbuhan organisasi dan individu.

Sebagian besar pertanyaan yang relevan termasuk operasi BERGABUNG, yang membuatnya berjalan sangat, sangat, sangat lambat dengan sejumlah besar data (database berisi jutaan baris).

Perlu dicatat bahwa operator JOIN adalah elemen penting dan kuat yang berkaitan dengan manipulasi data relasional. Kemudian, meskipun platform yang lebih tangguh menyajikannya dengan eksekusi yang relatif lebih cepat, keadaan yang Anda gambarkan kemungkinan besar adalah gejala dari desain yang tidak efisien (pada tingkat abstraksi konseptual, logis, dan fisik). Jadi, perkiraan penglihatan pertama saya adalah:

• Pengaturan INDEX mungkin memerlukan peningkatan.
• Definisi tipe dan ukuran kolom PK dan FK perlu ditinjau (dan saya sepenuhnya setuju dengan @Rick James mengenai pertimbangan PK-nya , karena KEY komposit cenderung jauh lebih efisien daripada pengganti pengganti dalam kasus-kasus yang sesuai).
• Normalisasi lebih lanjut (formal, berbasis sains) dapat membantu meringankan masalah-masalah ini, karena fakta bahwa, dalam keadaan yang tepat (yaitu, dilakukan dalam RDB yang dirancang dengan baik), GABUNGAN dijalankan dengan sangat cepat .

Selain itu, ya, seperti @TommCatt menyebutkan dalam jawabannya , kadang-kadang penulisan ulang (logis) kueri memodifikasi rencana pelaksanaannya (fisik) yang mempercepat pembacaan / penulisan data, yang merupakan faktor yang harus diperhitungkan dengan jelas.

Premis dasar pengembang Anda sama sekali salah. Kunci asing akan sedikit berdampak pada kinerja DML sistem Anda. Mereka tidak digunakan sama sekali dalam permintaan sehingga tidak berpengaruh pada kinerja mereka. Jadi pengembang Anda tidak tahu apa yang mereka bicarakan dan orang terakhir yang harus Anda pertimbangkan untuk menerima saran.

Kunci asing memainkan peran penting dalam menjaga integritas data Anda. Ini jauh lebih penting daripada peningkatan kinerja kecil yang diperoleh dengan menghapusnya (meskipun itu benar).

Dalam kondisi apa pun , jangan hapus FK dari database OLTP.

Juga, denormalisasi terkadang akan mempercepat beberapa permintaan. Itu, seperti kata mereka, tergantung. Namun, bahkan jika ada peningkatan kecepatan, umumnya tidak sepadan dengan upaya ekstra untuk menjaga integritas data.

Sangat jarang ketika penyetelan sederhana tidak bisa membuat Anda lebih banyak meningkatkan kecepatan daripada melakukan denormalisasi. Di sinilah DBA yang baik dapat (akhirnya) mendapatkan gajinya. Anda juga dapat menyetel kueri Anda. Saya pernah mengambil kueri yang mengembalikan jawaban dalam waktu kurang dari 30 menit dan membuatnya berfungsi dalam waktu kurang dari 8 detik. Tidak ada perubahan pada database, cukup tulis ulang kueri. Memang, ini adalah catatan terbaik pribadi saya, jadi jarak tempuh Anda mungkin berbeda, tetapi denormalkan seharusnya menjadi hal terakhir yang Anda coba.

Anda mungkin juga ingin menjaga agar pertanyaan yang lebih rumit tidak ditulis oleh pengembang. Tanyakan kepada mereka data apa yang mereka inginkan dan dalam format apa mereka menginginkannya. Kemudian berikan pandangan untuk diberikan kepada mereka. Kueri yang rumit akan menjadi tampilan. Pengembang hanya perlu menulis:

select <something> from <SomeView> where <whatever>;

Saya juga mengasumsikan bahwa basis data Anda dirancang dengan baik. Desain database yang buruk, atau bahkan sebagian kecil dari itu, dapat benar-benar memperlambat segalanya. Saya sering bekerja dengan Tabel Sangat Besar (masing-masing miliaran catatan) dengan kueri yang menyatukan mereka ke kiri dan kanan dan mengharapkan (dan mendapat) jawaban dalam sepersekian detik. Ukuran tabel tidak menentukan kecepatan kueri.

Saya benar-benar ngeri ketika seseorang berkata, "karena produk 'berfungsi' ada keraguan untuk meningkatkan basis data." Jika "keragu-raguan" ini lebih seperti "tidak ada di jam tanganku, kawan!" maka Anda bahkan mungkin ingin mulai memperbarui resume Anda. Tidak ada hal baik yang datang dari lingkungan seperti itu dan Anda akan disalahkan untuk setiap kegagalan di masa depan meskipun Anda mungkin telah melobi selama berjam-jam untuk membuat perubahan yang akan mencegah kegagalan tersebut. Anda akan mendengar, "Sekarang bukan waktu yang tepat untuk melakukan perubahan" berulang-ulang. Baik. Semoga berhasil.

Mengubah judul mengubah pertanyaan. FOREIGN KEYsadalah opsional. Mereka melakukannya:

• Sebuah FK secara implisit membuat sebuah INDEXdi salah satu tabel. Indeks semacam itu dapat ditambahkan secara manual. (Jadi FK tidak diperlukan untuk ini.)
• Seorang FK memeriksa integritasnya. Ini adalah klaim utama FK untuk terkenal. FK tidak diperlukan karena aplikasi Anda dapat melakukan pemeriksaan serupa, atau memutuskan bahwa pemeriksaan tidak diperlukan. Begitu...
• Pemeriksaan integritas membutuhkan sesuatu dalam kinerja; sehingga memperlambat pemrosesan. (Ini biasanya bukan masalah besar.)
• FK tidak melakukan semua yang diinginkan semua orang; forum ini dipenuhi dengan pertanyaan "mengapa FK tidak bisa melakukan X". Secara khusus CHECKopsi tidak ditindaklanjuti.
• FK dapat melakukan banyak CASCADEhal. (Secara pribadi, saya lebih suka tetap memegang kendali, dan tidak menganggap bahwa FK akan 'melakukan hal yang benar'.)

Intinya untuk FK: Beberapa orang bersikeras pada FK; beberapa produk hidup dengan baik tanpa mereka. Kamu putuskan.

Menyingkirkan PRIMARY KEYInnoDB adalah kesalahan besar. Di sisi lain, menyingkirkan pengganti AUTO_INCREMENTdan menggunakan PK "alami" yang terdiri dari satu (atau lebih) kolom seringkali merupakan hal yang tepat untuk dilakukan. Kasus sederhana, umum, banyak: banyak tabel pemetaan, seperti yang dibahas di sini .

Berdasarkan pengalaman pribadi, saya sarankan topi 2/3 dari tabel lebih baik menggunakan 'alami' daripada auto_inc PK.