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.