Papan buletin - Pengoptimalan basis data

.
22.3. Perlu memahami mengapa, tidak ada masalah sama sekali. Hanya anak-anak yang membabi buta mengikuti aturan sederhana, dan Anda tentu bukan salah satunya.
.
23. Dikonfirmasi:users.total_bulletins berlebihan; itu bisa diturunkan. Dihapus.
.
24. Semua PK Anda adalah Id. Apakah Anda belum bosan tersesat dalam kode? Lupakan menempelkan Id iot PK pada semua yang bergerak, mari cari tahu Bagaimana pengguna your Anda Identifikasi Entitas mereka; Entitas mana yang benar-benar Independen, dan lainnya yang bergantung pada Entitas Independen.

24.1. Jangan pernah menggunakan Id atau bentuk semacam itu. Jika ini adalah PK, gunakan formulir lengkap.

24.2. Panggil location_id, location_id, di mana pun itu, termasuk tabel PK. Pengecualiannya adalah ketika Anda perlu menunjukkan peran. Ini akan menjadi jelas dalam Model Data.
.
25. Anda tidak memiliki Integritas Referensial Deklaratif, tidak ada Ditentukan Kunci asing. Itu adalah berita buruk karena berbagai alasan. Setelah pertanyaan-pertanyaan ini diklarifikasi, silakan tambahkan. DRI berarti bahwa sebanyak mungkin, jika tidak semua, Integritas Dideklarasikan dalam SQL. Standar ISO/IEC/ANSI SQL memungkinkan untuk ini, tetapi pasar freeware tidak menyediakan standar, dan perlahan-lahan mengejar. Artinya server tidak akan mengizinkan baris dalam tabel FK untuk ditambahkan kecuali PK ada di tabel induk. MySQL baru-baru ini menyediakan DRI untuk Kunci Asing. Untuk FK, lihat ▶ artikel ini◀ .

25.1. Untuk PERIKSA batasan dan ATURAN, Anda harus mengimplementasikannya dalam kode.

kunci asing saya seperti, users-id(fk) =users.id(pk) Saya tidak yakin bagaimana menambahkannya selain apa yang telah saya lakukan tetapi pasti akan melakukannya setelah saya tahu caranya.

Dua puluh lima. Komentar Dicatat. Saya bukan spesialis MySQL. Ya, itulah masalah yang harus Anda pikirkan sendiri. Secara umum, dari penelusuran saya, MySQL tidak berkaki; untuk apa pun SQL-ish, Anda memerlukan InnoDB.

.
27. Mengingat:Saya telah memikirkan kembali persyaratan penyortiran untuk buletin. Pengguna dapat mengurutkan secara kronologis- mudah, masuk akal. Pengguna dapat mengurutkan buletin berdasarkan tanggal balasan terbaru ke buletin. Kemudian kita bisa melupakan peringkat dan seharusnya sangat mudah untuk mengurutkan buletin secara kronologis pada saat tanggapan terakhir mereka? Apa pendapat Anda.

Buka Masalah

(Nihil)

Model Data

Oke, dengan asumsi Anda tidak memiliki masalah dengan ERD, dan menerapkan semua Masalah Tertutup, saya telah membuat model data, dan menyiapkan Model Data Kelima 09 Des 10 untuk ulasan Anda. Saya pasti membutuhkan lebih banyak umpan balik, pertanyaan, dll, tentang ini. Saya mengalami kesulitan menerima bahwa hal itu dilakukan. Mungkin yang terbaik adalah mulai menulis kode nyata untuk area masalah Anda.

Tautan

▶Tautan ke Notasi IDEF1X◀ Anda benar-benar perlu membaca dan memahami ini, sebelum Anda membaca Model Data.

▶Tautan ke Data Buletin Kelima Model◀ Diagram Relasi Entitas ada di halaman pertama, diikuti oleh Model Data .

• Kuncinya cukup banyak IDEF1X lurus (kecuali untuk UserId yang saya berikan sebagai tandingan); yang berarti dompet Kunci Relasional. Tidak ditingkatkan dan tidak dioptimalkan untuk pertimbangan Fisik. Sebelum Anda menolaknya, perhatikan terlebih dahulu, daftarkan, dan evaluasi. Tentu saja kami dapat menambahkan Id kunci iot, tetapi sebelum kita melakukannya, pastikan kita memahami apa yang akan hilang dari kita.

• Perhatikan Pengidentifikasi (garis padat) sesuai dengan dokumen Notasi. Tulang belakang, tulang belakang sistem adalah Location ... Bulletin ... Response .

• Perhatikan bahwa Keys sebenarnya menerapkan banyak Aturan Bisnis.

• Perhatikan Hirarki Alami yang telah saya buat. Lihat apakah ada artinya bagi Anda.

• VerbFrase sangat penting; lihat apakah itu berarti.

Komentar untuk Model dan Respons Data Pertama

Satu pertanyaan yang saya miliki adalah bahwa kunci utama lokasi akan digunakan untuk membentuk kunci utama anak? (mereka digabungkan dengan garis padat) Saya tidak begitu mengerti konsep itu

• Apa Pengidentifikasi yang baik untuk Buletin ? , apa yang biasanya digunakan pengguna Anda untuk Mengidentifikasi Buletin ...
• "apakah Anda melihat buletin dari Virginia FO kemarin?",
• "Sally dari Washington pasti menulis buletin yang bagus", dll.

atau mengapa tidak ada hubungan antara pengguna dan buletin?

• Sesuai maksud yang dinyatakan lebih lanjut di atas, karena sekarang saya telah menunjukkan Peringkat sebagai tabel dan seperti apa renderingnya, sekali, saya akan menghapusnya

• Saya pikir Izin harus menjadi Entitas.

• Bulletins PK sekarang (StateCode, Town, UserId, SequenceNo) . Untuk lebih jelasnya, SequenceNo berada di dalam StateCode, Town, UserId :itu akan menjadi 5 untuk buletin ke-5 Sally tentang MO/Billngs FO.

• Perhatikan bahwa Pengaturan pengguna BulletinsPerPage ,dll, adalah 1::1 dengan User , jadi mereka berada di User; tabel anak akan salah.

• Kesalahan tipografi diperbaiki.

Komentar untuk Model dan Respons Data Kedua

• PK untuk kedua Bulletins dan Responses telah diubah untuk mencerminkan (7). BulletinNo dan ResponseNo telah diganti dengan BulletinDate dan ResponseDate (yang dulunya CreatedDate ), untuk mengizinkan beberapa balasan per User per Bulletins .

Komentar untuk Model dan Respons Data Ketiga

Percayalah Anda telah istirahat dengan baik.

1. Setidaknya 30 tahun yang lalu (yang saya ketahui), para raksasa di industri ini pernah berdebat. Nama selalu tunggal. Tabel adalah kata benda. VerbFrase adalah kata kerja. Ini tidak terbatas pada konvensi penamaan db, ini berlaku untuk dokumen, tesis, disertasi, dll. Anda mungkin memiliki 5 kesimpulan di akhir dokumen, tetapi judul bagian atau bab, baik di ToC dan bagian atas halaman adalah "Kesimpulan".

   Setelah melawan mereka sepanjang jalan melalui Uni, segera setelah saya memulai pekerjaan pemrograman berbayar pertama saya, dan melihat pentingnya aturan di dunia nyata, yang bertentangan dengan argumen teoretis yang kami miliki di perguruan tinggi, saya menyerah sebagai pemborosan. waktu. Semua waktu dan tenaga yang saya buang terbuang untuk melakukan pekerjaan yang produktif. Sejak itu, saya tidak mempertanyakan raksasa; saya terima saja. Bahwa pikiran mereka lebih besar dari saya. Ini seperti menerima Standar, atau berperilaku dalam hukum, atau Tuhan. Saya tidak punya alasan yang sangat, sangat bagus untuk melakukan sesuatu yang ilegal.

   Bagaimanapun, kemudahan bahasa (diskusi, SQL, dokumentasi) yang didukung oleh aturan tersebut tidak dapat dijelaskan secara memadai; saat Anda menulis lebih banyak dan lebih banyak kode SQL, itu akan menjadi jelas.

   Anda selalu bebas menggunakan apa pun yang Anda inginkan. Saya hanya mengirim tunggal.

2. Baik dengan saya.

   Namun perlu Anda ingat, kedua elemen tersebut, dalam urutan yang teridentifikasi (ala Non-PK Unique Index, atau Alternate Key) secara universal diperlukan untuk menetapkan Uniqueness for a Person. Menghapusnya akan menghasilkan dua hal. Pertama, Anda tidak lagi dapat mengidentifikasi keunikan di seluruh User (dan dengan demikian Anda mungkin memiliki baris duplikat). Kedua, AK menjadi tidak unik, sebuah Entri Inversi.

3. Intinya adalah (berlawanan dengan salah satu posting), kolom apa saja yang 1::1 dengan User PK, harus berada diUser . Semua pengaturan preferensi. Karena kami membersihkanInterestedLocations danInterestedCategories , saya hanya tahuBulletinsPerPage tersisa; tapi saya yakin ada orang lain. IsPreference2 adalah misalnya. dari boolean;NumPreference3 adalah misalnya. dari sebuah bilangan bulat. Dll. Anda dapat memberi tahu saya apa itu Preferensi sebenarnya.

   (Mari kita coba dalam bentuk jamak:... kolom apa saja yang 1::1 denganUsers PK, harus berada diUsers . Hanya tidak melakukannya untuk saya, saya terpaku pada bahasa Inggris yang rusak, dan saya sedikit berharga tentang bahasa ibu saya.)

   Model Data Diperbarui.

4. Bagus sekali. Beri tahu saya ketika Anda merasa nyaman dengan itu, dan saya akan memberi Anda Model Fisik.

   Bagaimana dengan VerbFrase?

Komentar ulang 06 Des 10 20:38 EST (Pembaruan Kecil)

.
28. Dimana hanya ada satu kemunculan PK sebagai FK tentunya nama kolom FK sama dengan nama kolom PK. Namun, ketika ada lebih dari satu occ dari FK (lihat ResponseRating ), ada tiga UserIds ), kita perlu membedakannya. Dalam terminologi IDEF1X ini disebut Peran. Peran User yang mengeluarkan Bulletins adalah Issuer , dan seterusnya. Jelas lebih baik menggunakan nama itu, dan tetap konsisten di seluruh hierarki (bukan UserId di Bulletins dan kemudian ketika kita sampai ke Response , di mana ada dua, dan diferensiasi diminta, ubah ke IssuerId . Saya pikir Anda mungkin memiliki masalah dengan itu; pada tahap awal, penggunaannya adalah Issuer.UserId sehingga benar-benar jelas UserId sebagai FK, dan Perannya adalah Issuer; ketika kita sampai ke model fisik, itu disederhanakan menjadi IssuerId .

Demikian juga, kami memiliki banyak kolom DateTime (Date untuk pendek jika Anda suka; jika tidak Dtm), yang perlu dibedakan.
.
29. Apakah dokumen Notasi IDEF1X tidak masuk akal?

• PK untuk setiap tabel berada di atas garis, dalam urutan yang ditentukan.
• Ingat kita membawa PK dari tabel induk, dan jika ada artinya, menggunakan FK tersebut untuk membentuk PK anak.

• Untuk Bulletins :

  • Lokasi FK (StateCode, Town) yang dikeluarkan
  • UserId dari Emiten
  • dan DateTime diterbitkan, untuk membuatnya unik.
  • oleh karena itu (Kode Negara, Kota, IssuerId, BulletinDate)`

• Untuk menghapus semua ResponseRatings untuk Bulletins ini , gunakan WHERE = pada keempat Bulletins kolom.

.
30. Karena (State, Town) adalah PK dari Location , dibawa kemana-mana. Dan itu merupakan bagian dari Bulletin PK, jadi setiap tabel dependen membawa kolom tersebut karena mereka membawa Bulletins PK

Kami sebelumnya telah mengidentifikasi bahwa (State, Town) adalah PK, Saya akan membiarkannya apa adanya Lihat (38) untuk perubahan.

.
33. Diskusi yang layak. Ya, jika Anda akan menampilkannya saat (misalnya) menampilkan Responses , dan pengguna memahami UserName . Tidak, jika 30 byte, dan ada juga UserId 4 byte yang unik . Idenya adalah untuk membuat pilihan ini secara sadar, menyadari apa yang Anda menyerah, ketika Anda akhirnya memutuskan bahwa beberapa 6 kolom kunci 30-byte terlalu rumit untuk bermigrasi ke anak-anak.

• Saya sudah menyatakan di awal, saya akan menggunakan UserId sebagai Id typical Pk, karena dibawa/dimigrasikan ke beberapa tabel anak.
• Kita dapat meninggalkan cara pembuatannya untuk nanti. Tapi itu adalah PK Pengganti murni.

.
34. Tidak masalah. Category sudah memilikinya. Saya akan mengubah Order ke ListOrder .

.
35. Tentu. Berdasarkan apa yang saya baca dan dengar, saya cukup senang dengan itu. Tapi saya ingin lebih bolak-balik untuk mencapai kepercayaan diri, sebelum Anda menulis kode. Sebagai alternatif, lihat itu sebagai pengalaman belajar, dan terima bahwa model dan kode dapat berubah nanti. Apakah Anda ingin saya memproduksi Fisik sekarang? Jika Anda memberi saya salah satu dan semua koreksi, saya akan menerbitkan versi berikutnya. Saya mengharapkan preferensi di User . Juga, jalankan fungsi dengan cepat dan periksa apakah Anda memiliki semua kolom yang Anda butuhkan.

Lihatlah beberapa jawaban lain, untuk tujuan pembelajaran, dan minat.

.
36. Bergabung. Anda baru saja bergabung di four tiga kolom sebagai lawan satu. SQL rumit dengan gabungan, dan sintaks baru yang seharusnya membuatnya lebih mudah, sebenarnya lebih rumit. Pembuat kode saya tidak pernah menulis gabungan:kami menghemat waktu dan kesalahan ketik. Saya memiliki proc yang memberikan dua atau lebih tabel, akan menghasilkan kode dengan semua kolom dan bergabung. Saya tidak cukup tahu tentang MySQL untuk mengonversinya untuk Anda.

Model Data Diperbarui.
.

Komentar ulang 08 Des 10 20:49, Model Data Keempat dan Respons

.
Periksa bagian sebelumnya tepat di atas, ada sedikit pembaruan.

IDEF1X:Kecepatan Anda baik-baik saja.

Perhatikan anak selalu “mewarisi” PK Induk, sebagai FK (baik garis lurus maupun putus), jika tidak maka tidak ada Hubungan di antara keduanya. Dengan menggunakan kolom-kolom yang ada pada anak tersebut, untuk membentuk PK anak, kita membawa makna (dan itulah perbedaan antara padat dan rusak). Dan dengan demikian kita tidak perlu mencari Pengenal independen untuk anak tersebut. Kekuatan relasional dalam metode ini akan menjadi jelas nanti, saat Anda melakukan pengkodean.

Bagian yang kita bahas adalah tentang Identifier :alami vs tidak wajar; bermakna vs tidak berarti. Nanti Anda akan melihat bagaimana kita dapat menggunakan kemampuan Relasional dari mesin, ketika PK anak dibentuk dari PK induk. (Bukankah nama belakangmu sama dengan nama ayahmu?)

Penting juga untuk memahami database relasional dan kemampuannya. Itu hilang ketika kita mendekati database (misalnya) dari perspektif OO, dan memperlakukannya sebagai lokasi untuk membuat kelas kita "persisten". Oleh karena itu, kami akan mencoba mempelajari dan menggunakan istilah relasional. Menjadi sulit ketika Anda pergi ke Prancis dan berharap mereka berbicara bahasa Amerika, dan menggunakan mata uang yang sama; belajar berbicara 10 kata bahasa Prancis, dan mereka menyambut Anda dengan tangan terbuka, dan Anda akan memiliki pengalaman yang sangat berbeda dengan penduduk setempat.

Bagaimanapun, lanjutkan dengan menerapkan model. Sadarilah bahwa kita mungkin akan membuat perubahan di beberapa titik. Simpan semua DDL Anda. Simpan semua data pengujian Anda sebagai pernyataan penyisipan atau sebagai cadangan tabel atau ekspor format karakter (tidak tahu apa yang dapat/tidak dapat dilakukan MySQL di area ini)..
37.1. Ditangani, Hubungan n::n dengan Office &Category . Anda hanya akan "melihat" itu saat kita membahas Model Fisik.

37.2. Selesai.

37.3 Selesai.
.
38. Bagus sekali. Lebih pendek juga. Perhatikan bahwa mereka tidak akan pernah dapat memiliki dua Office dalam Kode Pos yang sama. NUMERIC(5,0) bagus, tapi saya pikir AS bergerak menuju 7 digit. Tidak masalah, Anda bisa mengetahuinya; ini adalah PK yang sangat baik untuk Office . Sekarang kolom ini, yang merupakan bagian dari Address , mungkin ZipCode , telah ditingkatkan ke tujuan yang lebih tinggi, tanpa duplikasi; karena kami membawanya dalam 5 tabel anak, dan kami ingin nama PK menjadi jelas, sesuai dengan konvensi yang dijelaskan sebelumnya, kami akan menyebutnya OfficeCode; OfficeZipCode mungkin konyol.

Kami membutuhkan Indeks Unik pada Name untuk memastikan mereka tidak menambahkan dua Office dengan nama yang sama. Catatan, untuk tujuan penjelasan, ini sebenarnya adalah kunci logis Office , menggantikan (StateCode, Town) , dan tetap demikian.

Saya masih berpikir Anda mungkin memerlukan StateCode dan Town sebagai referensi cepat (selain duduk di suatu tempat di Address )

Model Data diperbarui, Kelima sekarang tersedia untuk ditinjau. Anda tidak menyatakan preferensi Anda, untuk ...Date vs ...Dtm . Saya akan menggunakan yang terakhir, karena lebih spesifik, mengidentifikasi komponen waktu juga. Mudah diubah.

Jawaban ini telah mencapai panjang maksimum. Bersambung di "Bagian II"