Desain database pertama kali: apakah saya overengineering? [Tutup]


246

Latar Belakang

Saya seorang siswa CS tahun pertama dan saya bekerja paruh waktu untuk bisnis kecil ayah saya. Saya tidak punya pengalaman dalam pengembangan aplikasi dunia nyata. Saya telah menulis skrip dengan Python, beberapa kursus di C, tapi tidak seperti ini.

Ayah saya memiliki bisnis pelatihan kecil dan saat ini semua kelas dijadwalkan, direkam, dan ditindaklanjuti melalui aplikasi web eksternal. Ada fitur ekspor / "laporan" tetapi sangat umum dan kami membutuhkan laporan spesifik. Kami tidak memiliki akses ke database aktual untuk menjalankan kueri. Saya diminta membuat sistem pelaporan khusus.

Ide saya adalah untuk membuat ekspor CSV generik dan mengimpor (mungkin dengan Python) mereka ke dalam database MySQL yang dihosting di kantor setiap malam, dari mana saya dapat menjalankan permintaan spesifik yang diperlukan. Saya tidak memiliki pengalaman dalam database tetapi memahami dasar-dasarnya. Saya sudah membaca sedikit tentang pembuatan basis data dan formulir normal.

Kami mungkin akan segera memiliki klien internasional, jadi saya ingin database tidak meledak jika / ketika itu terjadi. Kami juga saat ini memiliki beberapa perusahaan besar sebagai klien, dengan divisi yang berbeda (misalnya perusahaan induk ACME, divisi perawatan ACME, divisi perawatan tubuh ACME)

Skema yang saya buat adalah sebagai berikut:

  1. Dari perspektif klien:
    • Klien adalah tabel utama
    • Klien terhubung dengan departemen tempat mereka bekerja
      • Departemen dapat tersebar di seluruh negara: SDM di London, Pemasaran di Swansea, dll.
      • Departemen terkait dengan divisi perusahaan
    • Divisi terkait dengan perusahaan induk
  2. Dari perspektif kelas:
    • Sesi adalah tabel utama
      • Seorang guru terhubung dengan setiap sesi
      • Statusid diberikan untuk setiap sesi. Misalnya 0 - Selesai, 1 - Dibatalkan
      • Sesi dikelompokkan menjadi "paket" dengan ukuran sewenang-wenang
    • Setiap paket ditugaskan ke klien

Saya "mendesain" (lebih seperti mencoret-coret) skema pada selembar kertas, mencoba membuatnya tetap dinormalisasi ke bentuk ke-3. Saya kemudian menancapkannya ke MySQL Workbench dan itu membuat semuanya cantik untuk saya:
( Klik di sini untuk grafik berukuran penuh )

teks alternatif
(sumber: maian.org )

Contoh kueri yang akan saya jalankan

  • Klien dengan kredit yang masih tersisa tidak aktif (mereka yang tidak memiliki kelas dijadwalkan di masa mendatang)
  • Berapa tingkat kehadiran per klien / departemen / divisi (diukur dengan status id di setiap sesi)
  • Berapa banyak kelas yang dimiliki seorang guru dalam sebulan
  • Tandai klien yang memiliki tingkat kehadiran rendah
  • Laporan khusus untuk departemen SDM dengan tingkat kehadiran orang di divisi mereka

Pertanyaan

  • Apakah ini overengineered atau saya menuju ke arah yang benar?
  • Apakah kebutuhan untuk bergabung dengan beberapa tabel untuk sebagian besar kueri menghasilkan hit kinerja besar?
  • Saya telah menambahkan kolom 'lastsession' ke klien, karena itu mungkin akan menjadi permintaan umum. Apakah ini ide yang bagus atau haruskah saya menjaga database tetap normal?

Terima kasih atas waktunya


131
Siswa CS tahun pertama yang terhormat: silakan terus menggunakan StackOverflow. Pertanyaan Anda menarik, ditulis dengan baik dan bermanfaat. Dengan kata lain, Anda berada di atas 1% dari penanya pertanyaan.
Adam Crossland

Bisakah Divisi berisi Divisi lain? JIKA itu adalah kasus "memiliki" tabel mungkin digunakan untuk menghubungkan Divisi kembali ke Divisi yang dikandungnya.
Mark Schultheiss

Terima kasih atas komentar yang baik :) Mark saya harus memeriksa dokumentasi untuk proyek ini lagi, tapi saya rasa kami tidak mengidentifikasi kasus itu. Terima kasih telah menunjukkannya.
bob esponja

1
Saya tidak suka konveksi penamaan kunci utama Anda. tabel divisionsmemiliki kolom bernama divisionid. Apakah Anda tidak menemukan itu berlebihan? Sebut saja id. juga nama tabel Anda termasuk _has_: saya akan menghapusnya dan beri nama saja misalnya cities_departments. DATETIMEkolom Anda harus bertipe TIMESTAMPkecuali nilai input pengguna. Saya pikir itu ide yang baik untuk memiliki citiesdan countriestabel. Anda mungkin mengalami kesulitan membatasi tabel ke satu status. pertimbangkan untuk menggunakan INTdan melakukan perbandingan bitwise di atasnya- sehingga Anda dapat memiliki lebih banyak makna di sana
james

@binnyb Ada banyak argumen tentang penggunaan id sebagai nama kunci utama yang harus dipertimbangkan orang sebelum memutuskan.
Jedi

Jawaban:


42

Beberapa jawaban lagi untuk pertanyaan Anda:

1) Kamu cukup tepat sasaran untuk seseorang yang mendekati masalah seperti ini untuk pertama kalinya. Saya pikir petunjuk dari orang lain tentang pertanyaan ini sejauh ini cukup banyak membahasnya. Kerja bagus!

2 & 3) Performa hit yang akan Anda ambil akan sangat tergantung pada memiliki dan mengoptimalkan indeks yang tepat untuk pertanyaan / prosedur khusus Anda dan yang lebih penting adalah volume rekaman. Kecuali jika Anda berbicara tentang lebih dari satu juta catatan di tabel utama Anda, Anda tampaknya berada di jalur untuk memiliki desain arus utama yang memadai bahwa kinerja tidak akan menjadi masalah pada perangkat keras yang masuk akal.

Yang mengatakan, dan ini berkaitan dengan pertanyaan Anda 3, dengan permulaan yang Anda miliki Anda mungkin tidak harus terlalu khawatir tentang kinerja atau hiper-sensitivitas terhadap normalisasi ortodoksi di sini. Ini adalah server pelaporan yang Anda bangun, bukan aplikasi backend berbasis transaksi, yang akan memiliki profil yang jauh berbeda sehubungan dengan pentingnya kinerja atau normalisasi. Basis data yang mendukung aplikasi pendaftaran dan penjadwalan langsung harus memperhatikan pertanyaan yang membutuhkan waktu beberapa detik untuk mengembalikan data. Tidak hanya fungsi server laporan yang lebih toleran terhadap kueri yang rumit dan panjang, tetapi strategi untuk meningkatkan kinerja jauh berbeda.

Misalnya, dalam lingkungan aplikasi berbasis transaksi, opsi peningkatan kinerja Anda mungkin termasuk refactoring prosedur tersimpan Anda dan struktur tabel ke tingkat n, atau mengembangkan strategi caching untuk sejumlah kecil data yang biasanya diminta. Dalam lingkungan pelaporan Anda tentu dapat melakukan ini tetapi Anda dapat memiliki dampak yang lebih besar pada kinerja dengan memperkenalkan mekanisme snapshot di mana proses yang dijadwalkan berjalan dan menyimpan laporan yang telah dikonfigurasi sebelumnya dan pengguna Anda mengakses data snapshot tanpa tekanan pada tingkat db Anda pada per permintaan dasar.

Semua ini adalah kata-kata kasar yang bertele-tele untuk menggambarkan bahwa prinsip-prinsip dan trik desain apa yang Anda gunakan mungkin berbeda mengingat peran db yang Anda buat. Saya harap itu membantu.


1
1. Terima kasih, itu meyakinkan! 2 & 3. Saya masih tidak tahu bagaimana indeks bekerja, itu adalah sesuatu yang saya rencanakan untuk dibaca. Jika kita memiliki "masalah" untuk mencapai sejuta catatan, mungkin akan ada anggaran untuk mempekerjakan pengembang berpengalaman: P Terima kasih atas wawasan tentang berbagai peran db yang ada, itu semua baru bagi saya dan sangat menarik untuk diketahui. Saya akan melihat snapshot karena apa yang Anda gambarkan pada dasarnya adalah tujuan akhir dari proyek ini.
bob esponja

Jika Anda memahami tabel, fundamental indeks cukup mudah. Secara konseptual, indeks dapat (dan sering) diimplementasikan sebagai tabel dengan sangat sedikit kolom yang isinya disalin dari tabel utama, dan referensi kembali ke tabel utama, yang baris-barisnya diurutkan untuk aksesibilitas yang cepat. B + Tree adalah pengaturan indeks yang paling umum, tetapi optimisasi indeks adalah tempat pemain besar memiliki teknologi yang berbeda sehingga menjadi suram jika Anda mencoba menerapkan analogi terlalu dalam.
pojo-guy

14

Anda punya ide yang tepat. Namun Anda dapat membersihkannya, dan menghapus beberapa tabel pemetaan (memiliki *).

Apa yang dapat Anda lakukan adalah di tabel Departemen, tambahkan CityId dan DivisionId.

Selain itu, saya pikir semuanya baik-baik saja ...


4
Saya pikir dia perlu tabel pemetaan jika dia ingin menggunakan kembali definisi departemen di berbagai divisi atau kota.
Jacob G

1
Ya, saya setuju ..... tapi kedengarannya seperti departemen hanya bisa di satu kota / divisi. Jika tidak, maka apa yang dimilikinya benar.
Pendeta Gonzo

Saya memiliki artikel wiki yang saya tulis dengan "spec" di kantor, saya harus membacanya lagi, tetapi Jacob G benar, IIRC ada beberapa departemen yang merentang divisi. Satu departemen SDM induk ACME untuk perawatan kesehatan ACME dan perawatan tubuh ACME. Jika saya dapat menyederhanakannya meskipun saya pasti akan, terima kasih atas sarannya.
bob esponja

6

Satu-satunya perubahan yang akan saya lakukan adalah:
1- Ubah VARCHAR Anda menjadi NVARCHAR, jika Anda ingin go internasional, Anda mungkin ingin unicode.

2- Ubah id int Anda menjadi GUIDs (uniqueidentifier) ​​jika memungkinkan (ini mungkin hanya preferensi pribadi saya). Dengan asumsi Anda akhirnya sampai pada titik di mana Anda memiliki beberapa lingkungan (dev / test / staging / prod), Anda mungkin ingin memigrasikan data dari satu ke yang lain. Memiliki GUID Id membuat ini secara signifikan lebih mudah.

3- Tiga lapisan untuk Perusahaan Anda -> Divisi -> Struktur departemen mungkin tidak cukup. Sekarang, ini mungkin rekayasa berlebihan, tetapi Anda bisa menggeneralisasi hierarki sedemikian rupa sehingga Anda dapat mendukung n-level kedalaman. Ini akan membuat beberapa pertanyaan Anda lebih kompleks, sehingga mungkin tidak sepadan dengan trade-off. Lebih lanjut, bisa jadi bahwa setiap klien yang memiliki lebih banyak lapisan dapat dengan mudah "dimasukkan" ke dalam model ini.

4- Anda juga memiliki Status di Tabel Klien yang merupakan VARCHAR dan tidak memiliki tautan ke tabel Statuses. Saya berharap ada sedikit kejelasan tentang apa yang diwakili Status Klien.


1- Terima kasih, saya mengalami masalah dengan diakritik dan UTF8 yang saya akan posting pertanyaan lain. Mungkin ini masalahnya. 2 - Saya sudah membaca beberapa pertanyaan lain di sini di SO dengan banyak pendapat yang bertentangan tentang masalah ini, saya akan melakukan lebih banyak membaca tentang masalah ini. 3 - Saya akan membicarakan hal ini dengan ayah saya lagi, melihat pada "spec" yang saya tulis dan melihat apakah ini sesuatu yang harus kita perhatikan. --Komentar berikutnya berikutnya
bob esponja

4 - Saya tidak membahas pertanyaan utama untuk singkatnya: status pada klien adalah apakah mereka aktif (ada sesi yang tersisa) atau tidak aktif (tidak ada sesi yang tersisa). Dengan lebih jelas, maksud Anda nama yang lebih deskriptif untuk col? Misalnya enrolment_status? Terima kasih atas masukan Anda.
bob esponja

kembali # 4- Selain nama Anda yang lebih jelas, jika hanya ada dua status, aktif / tidak aktif, lalu mengapa tidak membuatnya sedikit kolom?
Jacob G

3
Tidak setuju tentang GUID, bergidik. Mereka bisa mengerikan untuk kinerja. Jangan menggunakannya kecuali Anda perlu membalas.
HLGEM

1
Pertunjukan hanya berperan ketika Anda berbicara 10 dari jutaan baris dalam sebuah tabel. Jika Anda memiliki jenis struktur itu, maka Anda dapat menguranginya dengan pengurutan berurutan dan pengindeksan kreatif. Kalau tidak, "kinerja" adalah herring merah ketika mendiskontokan GUID.
Jacob G

6

Tidak. Sepertinya Anda mendesain pada tingkat detail yang baik.

Saya pikir Negara dan Perusahaan benar-benar entitas yang sama dalam desain Anda, seperti Kota dan Divisi. Saya akan menyingkirkan tabel Negara dan Kota (dan Kota_Has_Departemen) dan, jika perlu, tambahkan boolean flag IsPublicSector ke tabel Companies (atau kolom CompanyType jika ada lebih banyak pilihan daripada sekadar Sektor Swasta / Sektor Publik).

Juga, saya pikir ada kesalahan dalam penggunaan tabel Departemen Anda. Sepertinya tabel Departemen berfungsi sebagai referensi ke berbagai jenis departemen yang masing-masing divisi pelanggan dapat miliki. Jika demikian, itu harus disebut DepartmentTypes. Tetapi klien Anda (yang saya anggap sebagai peserta) bukan milik TYPE departemen, mereka milik instance departemen aktual di perusahaan. Seperti yang ada sekarang, Anda akan tahu bahwa klien yang diberikan milik departemen SDM di suatu tempat, tetapi bukan yang mana!

Dengan kata lain, Klien harus ditautkan ke tabel yang Anda panggil Divisions_Has_Departments (tapi yang saya sebut hanya Departemen). Jika demikian, maka Anda harus merobohkan Kota ke Divisi seperti yang dibahas di atas jika Anda ingin menggunakan integritas referensial standar dalam database.


Tabel negara adalah untuk jika / ketika kita memiliki klien yang beroperasi di lebih dari satu negara dan memiliki departemen SDM yang berbeda untuk masing-masing negara. Dengan begitu kami dapat membuat laporan dengan data dari negara tempat departemen yang kami tangani beroperasi. Sama untuk departemen dan kota, saya pikir kami memiliki klien yang memiliki dept SDM yang terpisah. untuk dua kota di mana mereka memiliki kantor utama. Atau setidaknya itulah alasannya, saya akan duduk dan memikirkan kembali untuk melihat apakah mereka benar-benar diperlukan. Belum memikirkan CompanyType, saya akan mencari tahu apakah itu sesuatu yang perlu kita lacak.
bob esponja

RE: depts table, jalur pemikiran awal saya adalah menggunakannya sebagai departemen aktual, dengan nama departemen sebagai tipe. Tidak terpikir oleh saya untuk hanya memiliki jenis departemen, yang tampaknya lebih logis. Tentang mengetahui departemen mana dan di mana seseorang berasal, saya berpikir bahwa memiliki departemen yang terhubung dengan kota dan divisi (yang terkait dengan perusahaan) akan berhasil. Apakah saya salah? Untuk memecah Kota menjadi Divisi, beberapa Divisi menjangkau beberapa kota, dan saya pikir mungkin bahkan negara. Saya akan memeriksanya lagi. Terima kasih atas masukan Anda.
bob esponja

5

Omong-omong, perlu dicatat bahwa jika Anda sudah menghasilkan CSV dan ingin memuatnya ke dalam database mySQL, LOAD DATA LOCAL INFILE adalah teman terbaik Anda: http://dev.mysql.com/doc/refman/5.1/ id / muat-data.html . Mysqlimport juga layak untuk dilihat, dan merupakan alat baris perintah yang pada dasarnya pembungkus yang bagus untuk memuat data infile.


3

Sebagian besar hal telah dikatakan, tetapi saya merasa bahwa saya dapat menambahkan satu hal: cukup umum bagi pengembang yang lebih muda untuk khawatir tentang kinerja sedikit terlalu banyak di muka, dan pertanyaan Anda tentang bergabung dengan tabel tampaknya mengarah ke arah itu. Ini adalah anti-pola pengembangan perangkat lunak yang disebut ' Premature Optimization '. Cobalah untuk mengusir refleks itu dari pikiran Anda :)

Satu hal lagi: Apakah Anda percaya Anda benar-benar membutuhkan tabel 'kota' dan 'negara'? Tidakkah memiliki kolom 'kota' dan 'negara' di tabel departemen cukup untuk kasus penggunaan Anda? Misalnya apakah aplikasi Anda perlu membuat daftar departemen menurut kota dan kota demi negara?


1
Berusaha sekuat tenaga, itu terus mengambil perhitungan besar helloworld.c, mengoptimalkan tabel kota-kota dan negara-negara hanya semacam menelurkan diri ketika saya mengikuti langkah-langkah untuk mendapatkan database 3NF. Saya kira keuntungan yang mereka tawarkan adalah koherensi untuk nama kota / negara. Seperti jika kita mendapatkan klien di Munich dan untuk beberapa alasan siapa pun yang memasukkan siswa baru ke dalam sistem penjadwalan memutuskan untuk menyebutnya München daripada Munich seperti untuk siswa sebelumnya. Juga kita mungkin perlu daftar departemen menurut kota, aku harus memeriksa. Terima kasih.
bob esponja

2
Mengoptimalkan dalam fase desain database sangat penting! Ini bukan optimalisasi prematur karena database secara signifikan lebih sulit untuk refacotr ketika mereka memiliki jutaan catatan.
HLGEM

1
Saya tidak mengatakan dia tidak boleh menguji-coba desainnya :)
Hans Westerbeek

3

Berikut komentar berdasarkan peran sebagai spesialis Intelijen / Pelaporan Bisnis dan manajer strategi / perencanaan:

  1. Saya setuju dengan arahan Larry di atas. IMHO, Ini tidak terlalu banyak direkayasa, beberapa hal hanya terlihat sedikit tidak pada tempatnya. Untuk membuatnya tetap sederhana, saya akan menandai klien langsung ke ID Perusahaan, Deskripsi Departemen, Deskripsi Divisi, ID Jenis Departemen, ID Jenis Divisi. Gunakan ID Jenis Departemen dan ID Jenis Divisi sebagai referensi untuk tabel pencarian dan bidang pelaporan / analisis internal untuk konsistensi jangka panjang.

  2. Tabel paket berisi kolom "Kredit", bukankah seharusnya itu benar-benar diikat ke tabel basis Klien sehingga jika mereka banyak paket, Anda dapat melihat berapa banyak utang kredit yang tersisa untuk kelas mendatang? Aplikasi dapat menangani calc dan menyimpannya secara terpusat di tabel Klien.

  3. Info perusahaan dapat menggunakan lebih banyak bidang, termasuk alamat yang jelas / telepon / dll. informasi. Saya juga akan siap untuk menambahkan kolom D & B "DUN" (Situs / Cabang / Ultimate) jangka panjang, Dun dan Bradstreet (D & B) memiliki katalog besar perusahaan dan Anda akan menemukan kemudian jalan informasi mereka sangat membantu untuk pelaporan / analisis. Ini akan menangani masalah beberapa divisi yang Anda sebutkan, dan memungkinkan Anda untuk menggulung hierarki mereka untuk sub / divisi / cabang / dll. korps besar.

  4. Anda tidak menyebutkan berapa banyak catatan yang akan Anda kerjakan yang bisa menyiratkan pengaturan diri Anda untuk inisiatif pengembangan besar yang bisa dilakukan lebih cepat dan jauh lebih sedikit sakit kepala dengan perangkat lunak "pelaporan" yang telah dikemas. Jika Anda tidak berurusan dengan database yang besar (<65000) baris, pastikan MS-Access, OpenOffice (Base) atau solusi laporan / pengembang aplikasi terkait tidak bisa melakukan trik. Saya menggunakan perangkat lunak APEX Oracle gratis sedikit sendiri, ia datang dengan database gratis mereka Oracle XE hanya mengunduhnya dari situs mereka.

  5. FYI - Wawasan pelaporan: untuk basis data besar, Anda biasanya memiliki dua contoh basis data a) basis data transaksi untuk merekam setiap catatan terperinci. b) pelaporan basis data (data mart / data warehouse) yang ditempatkan pada mesin terpisah. Untuk informasi lebih lanjut cari google Skema Bintang dan Skema Snowflake.

Salam.


1. Maksud Anda menambahkan semua kolom itu ke tabel klien? Saya pikir itu akan merusak normalisasi, dan juga membuatnya sulit untuk tetap konsisten, saya tidak yakin saya mengerti dengan benar. 2. Paket bersifat berurutan, hanya paket terbaru yang dapat memiliki kredit terutang, jadi tidak perlu melacak beberapa paket. Apakah Anda masih merekomendasikan menyimpannya di tabel klien dalam kasus ini? 3. Ini sepertinya akan sangat membantu mencari tahu struktur perusahaan klien, saya akan memeriksanya terima kasih.
bob esponja

4. Saya harus memeriksa jumlah klien dan sesi yang kami harapkan untuk tahun berikutnya, tetapi tampaknya layak bagi saya untuk tabel sesi untuk mencapai banyak baris dalam satu tahun atau lebih. Saya akan memeriksa perangkat lunak pelaporan, itu tidak terpikir oleh saya. 5. Sepertinya itulah situasi yang saya alami secara kebetulan; aplikasi web akan menjadi "database transaksi" kami dan proyek ini "database perbaikan" kami :) Terima kasih atas masukan Anda.
bob esponja

1. Ya menambahkan "ID Perusahaan, Deskripsi Departemen, Deskripsi Divisi, ID Jenis Departemen, ID Jenis Divisi" ke tabel klien. Klien milik satu perusahaan, jenis departemen yang berbeda (IT / Ops / Admin / dll.) Dalam suatu perusahaan dan jenis divisi yang berbeda (Penjualan / SDM / Jalur pemasaran bisnis). 2. Saya hanya berpikir Kredit dikaitkan dengan klien atau perusahaan dan bukan dengan Paket sesi. Ini adalah keputusan bisnis yang dapat Anda ambil.
Will

Larry juga menyebutkan menggabungkan Perusahaan dan Negara. Saya sepenuhnya setuju dan kembali ke titik mengenai referensi D&B. Saya akan menggunakan SiteID atau sesuatu yang unik untuk memungkinkan beberapa lokasi di perusahaan yang sama dan kemudian menautkan Departemen ke salah satu SiteID unik.
Will

2

Saya ingin membahas hanya kekhawatiran bahwa bergabung dengan tabel mutiple akan menyebabkan hit kinerja. Jangan takut untuk menjadi normal karena Anda harus bergabung. Bergabung adalah normal dan diharapkan dalam basis data relasional dan mereka dirancang untuk menanganinya dengan baik. Anda perlu mengatur hubungan PK / FK (untuk integritas data, ini penting untuk dipertimbangkan dalam mendesain) tetapi dalam banyak basis data, FK tidak secara otomatis diindeks. Karena mereka akan digunakan dalam bergabung, Anda akan ingin mendaftar dengan mulai mengindeks FKS. PK umumnya mendapatkan indeks pada penciptaan karena mereka harus unik. Memang benar bahwa desain datawarehouse mengurangi jumlah gabungan, tetapi biasanya seseorang tidak sampai ke pergudangan data sampai seseorang memiliki jutaan catatan yang perlu diakses dalam satu laporan. Bahkan hampir semua gudang data mulai dengan database transaksional untuk mengumpulkan data secara real time dan kemudian data dipindahkan ke gudang sesuai jadwal (malam atau bulanan atau apa pun kebutuhan bisnis). Jadi ini adalah awal yang baik bahkan jika Anda perlu merancang data warehouse nanti untuk meningkatkan kinerja laporan.

Saya harus mengatakan desain Anda sangat mengesankan untuk siswa CS tahun pertama.


1

Ini bukan rekayasa berlebihan, ini adalah bagaimana saya akan mendekati masalah. Bergabung dengan baik-baik saja, tidak akan ada banyak hit kinerja (itu benar-benar diperlukan kecuali Anda mende-normalisasi database yang tidak direkomendasikan!). Untuk status, lihat apakah Anda dapat menggunakan enum datatype sebagai gantinya untuk mengoptimalkan tabel itu.


enum itu jahat. Setiap kali Anda perlu memperpanjang enum, Anda harus membangun kembali meja Anda - yang OK sampai ukuran meja Anda menjadi banyak GB.
Martin

Terima kasih atas masukan dan saran Chris, saya khawatir saya akan menciptakan monster yang terlalu kompleks. Martin, statusnya cukup jelas dan statis: pada dasarnya kelas 0-Lengkap, 1-Kelas dibatalkan, 2-Tidak muncul. Saya pikir ketiganya mencakup kemungkinan hasil suatu kelas. Apakah masih merupakan ide yang buruk untuk menggunakan enum dalam kasus ini?
bob esponja

Ini sepertinya sempurna untuk enum, dalam pikiranku. Semua hasil yang mungkin dipenuhi sebelumnya. Int juga baik yang dapat Anda wakili dengan enum atau statis di aplikasi Anda. Tidak masalah :) Enums lebih baik untuk dilihat jika Anda mengedit database menggunakan beberapa alat.
Chris Dennett

enum bisa bermasalah (mungkin kata jahat terlalu kuat) ketika Anda memiliki tabel besar yang harus online 24x7 dan enum perlu diubah. Mengingat bahwa Anda mengisi ulang tabel dari awal - jangan khawatir. Diberikan set data yang cukup kecil, Anda mungkin juga hanya menggunakan string.
Martin

1

Saya telah bekerja di domain pelatihan / sekolah dan saya pikir saya akan menunjukkan bahwa pada umumnya ada hubungan M: 1 antara apa yang Anda sebut "sesi" (contoh dari kursus yang diberikan) dan kursus itu sendiri. Dengan kata lain, katalog Anda menawarkan kursus ("Spanyol 101" atau apa pun), tetapi Anda mungkin memiliki dua contoh yang berbeda selama satu semester (Tu-Th diajarkan oleh Smith, Wed-Fri diajar oleh Jones).

Selain itu, sepertinya ini awal yang baik. Saya yakin Anda akan menemukan bahwa domain klien (grafik yang mengarah ke "klien") lebih kompleks daripada yang Anda modelkan, tetapi jangan berlebihan dengan hal itu sampai Anda memiliki beberapa data nyata untuk memandu Anda.


Jika saya mengerti Anda dengan benar, itu tidak sepenuhnya benar. "Kursus" hanyalah kelompok sesi berikutnya. Ini bukan sistem berbasis semester tradisional. Saya tidak dapat memikirkan hal lain yang dapat ditambahkan ke domain klien, apakah Anda punya contoh? Juga saya khawatir saya sudah berlebihan dengan kompleksitasnya, senang bukan itu masalahnya :) Terima kasih atas masukan Anda.
bob esponja

0

Beberapa hal muncul dalam pikiran:

  1. Tabel-tabel itu tampaknya cocok untuk pelaporan, tetapi tidak benar-benar menjalankan bisnis. Saya akan berpikir ketika klien mendaftar, pada dasarnya ada pesanan yang ditempatkan untuk klien menghadiri daftar sesi, dan pesanan itu mungkin untuk beberapa karyawan di satu perusahaan. Tampaknya tabel "pesanan" akan benar-benar berada di pusat sistem Anda dan mendorong pengambilan data dan pelaporan akhirnya. (Bandingkan dokumen kertas yang telah Anda gunakan untuk menjalankan bisnis dengan desain database Anda untuk melihat apakah ada kecocokan logis.)

  2. Perusahaan seringkali tidak memiliki divisi. Karyawan terkadang mengubah divisi / departemen, bahkan mungkin pertengahan sesi. Perusahaan terkadang menambah / menghapus / mengganti nama divisi / departemen. Pastikan kemungkinan perubahan konten waktu nyata dari tabel Anda tidak mempersulit pelaporan / pengelompokan berikutnya. Dengan begitu banyak data kontak yang terbagi atas begitu banyak tabel, Anda mungkin harus menerapkan validasi entri data yang sangat ketat untuk menjaga laporan Anda bermakna dan inklusif. Misalnya, ketika klien baru ditambahkan, pastikan perusahaan / divisi / departemen / kotanya cocok dengan nilai yang sama dengan rekan kerjanya.

  3. Konsep "paket" tidak jelas sama sekali.

  4. Karena Anda mengindikasikan itu adalah bisnis kecil, akan mengejutkan jika kinerja akan menjadi masalah, mengingat kecepatan dan kapasitas mesin saat ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.