Relasi Table One to One Kok Pisah Table

[@gilangrakean9501]

Kapan relasi one to one diperlukan 1. Ketika column2nya opsional Cth. tidak semua user e-commerce punya wallet, jd wallet bisa dipisah sendiri 2. Ketika data sudah terlalu banyak (beresiko nge-hold transaksi ke table yg di alter) Hampir semua database RELATIONAL ketika melakukan alter table (mis. tambah kolom baru) akan nge-lock table. Ketika di lock, semua transaksi yg akses ke table tsb akan di hold sampai proses alter selesai. Bahaya jika data sudah sangat banyak. 3. Kalau kolomnya terlalu banyak Jika banyak column dalam 1 table dan pakai ORM, lalu hanya ingin ambil/update data tertentu, maka akan terambil semua data. Bisa dipisah per kategori (mis. table user, user_social_media, user_credentials)

[@melinuxid]

saya sering mmg memisahkan...walaupun one to one...pangaplikasian saya di sistem rumahnsakit misal kasus transaksi register pasien yg ada nomor registrasi..terkoneksi one to one dengan header pemeriksaaan lab...nah header pemeriksaan lab inilah yang memiilki one to many...mengingat setiap registrasi belum tentu memiliki peneriksaan lab..dan header registrasi maupun header lab memiliki atribut yg memiliki kepentingan yg berbeda

[@MargaRizaldiChannel]

"... header pemeriksaan lab inilah yang memiilki one to many..." berarti transaksi many-to-one ke header pemeriksaan lab... bukan one-to-one

[@melinuxid]

@@MargaRizaldiChannel 1 isian data register ke 1 isian header lab mas.........bukan many to one..induk dari transaksi ada di data register

[@MargaRizaldiChannel]

@@melinuxid yayayaya

[@mrh30]

ilmu mahal ini, baru dapet ilmu ini pas kuliah tapi sekarang banyak sumber yg ngasih referensi tentang ilmu kek gini

[@muhammadakbarbagaskoro2599]

Karena yang kaya gini muncul dari pengalaman

[@Lukmandst]

i see, maaci bwang nambah insight

[@YusufGhava]

Kenapa tidak kita buat tabel ditengahnya ? User. USER WALLET. Wallet

[@kidzeroll99]

Oh apakah ini yang dimaksud dengan normalisasi database?

[@miftahfaridl9850]

Sangat mencerahkan

[@nolep5555]

masih kurang paham tentang primary key join. itu berarti tidak memakai autoincrement ya untuk tablenya?

[@apisaga]

Semua table punya primery key jelas auto increment

[@nolep5555]

@@apisaga lah terus kalo primary key join misal make auto increment nanti ada kasus gak bisa sama antara table id primary key joinnya karena udah dipake angkanya misal di tb user baru mau insert make id 1 terus di media sosial gak bisa insert pake id 1 karena udah ada sebelumnya (blm kehapus) kan gak bisa dong

[@apisaga]

@@nolep5555 1. Setiap kita melakukan perintah join , kan pasti menyebutkan 2 nama table. 2. Setiap table yang mau di relasikan pasti ada foregn key Example: table user & sosial media hubunganya one to many, table user hanya punya primary key sedangnkan table sosial media punya primary dan forgn key, foregn key digunakan untuk(penanda) relasi ke user.

[@apisaga]

Saya koir herianto di table user adalah user ke 50 (primary key : 50 di table user) di aplikasi saya saya menambahkan intagram di baris ke 99 (primary key ke 99 dan foregn key : 50 di table sosialMedia) foregnkey sama dengan primary key di table user sebagai relasi

[@nolep5555]

@@apisaga maksud primary key join itu kayak di video pak eko 3:02 kalau join dengan relasi 1 to many/ many to many sih saya paham juga. jadi konteksinya itu kan dibilang pak eko harus sama primary keynya makanya saya bertanya apakah di insert menggunakan unique key yang tidak berurutan

[@kingkutub1806]

Thx mas Eko jadi lebih kebayang

[@riffki326]

pak kapan ada promo lagi hehe

[@daffa_gamink]

Terimakasih mas Eko sangat jelas bagi saya yang sedang belajar database

[@suryohastomo9439]

makasih mas eko buat materinya... mas eko mau nanya. aku baru masuk ke dunia kerja, selama ini kalo belajar database pake orm (nodejs). terus di kerjaan mereka saranin pake query sql biasa dan juga stored procedure (aku panik karena harus belajar lagi). sebenernya sepenting itukah? dan apakah orm itu menjadi suatu yang jangan di praktekan di dunia kerja? regard

[@johannessandjaja7630]

biasanya gara" ORM querynya lebih slow dibandingkan raw

[@danielsinaga5901]

Izin mencoba menjawab, kalo menurut pengalaman pribadi saya yang pertama masing-masing perusahaan masih punya tradisi tersendiri dalam pengembangan suatu aplikasi seperti masih nyaman menggunakan native query dikarenakan teknologi lama yang masih digunakan seperti stored procedure, create View, dll dan juga berdasarkan penggunaan memori masih lebih unggul yang native sih

[@danielsinaga5901]

yang kedua biasanya perusahaan tersebut mengira akan memakan banyak waktu dan biaya lainnya (untuk lisensi server atau cloud) sehingga muncul pemikiran akan ribet dan hemat budget capex

[@YudhaTPutra]

ikut diskusi ya, setau saya si memang itu udh jadi kebiasaan di kantor/perusahaannya yg pakai stored procedure apalagi yg db nya pakai oracle..menurut saya ORM hanya enak untuk CRUD apalagi bisa agnostik db, tapi untuk membuat laporan/untuk query2 yg lebih kompleks lebih cepat pakai raw query

[@riskeilles]

aku terbalik sih, sebelumnya pake stored procedure/query dan sekarang pake orm (entity framework/c#). saranku sih jalanin aja pake stored procedure/native query gitu, karena nantinya bakal lebih aware dgn penggunaan memory saat nge-query (itu pengalamanku sih). kalo pake orm, kadang2 method2 nya terlihat praktis padahal query yang dia jalanin di dalemnya ga seefisien itu, dan biar lebih efisien secara penggunaan memory biasanya di-tradeoff dengan code yg agak lebih panjang dan pastinya harus aware dengan apa yang dilakukan oleh method2 si orm tersebut.

[@muhammadzakaria7427]

Alhamdulillah tercerahkan

[@TriAriSetiawan]

saya mau tanya, saya bikin aplikasi mobile dengan php di severnya.. kalo saya coba query pake aplikasi navicat itu butuh waktu sekitar 40detik buat dapet datanya, tapi kalo aku panggil query pake php cuma butuh waktu 5 detik dengan query yg sama.. kok bisa gitu ya? apa di aplikasi navicat ada proses tambahan selain menampilkan di UI nya yg bikin lama..?

[@zeinadi]

Kalau lokasi database dan navicat terpisah, misal database di cloud, navicat dari laptop di rumah, maka ada proses download data, memindahkan dari db ke sql client, jadi tergantung koneksi internet juga. Sementara kalau lokasi DB dan aplikasi ada 1 server yang sama, misal aplikasi PHP tadi dan DBnya di 1 server, proses download data bisa jauh lebih cepat, bisa hampir diabaikan saja.

[@wewegomb]

Pada ga belajar normalisasi denormalisasi kah orang2

[@MuchlisNopq]

normalisasi terkadang pain buat programmer. yang harusnya 1 call bisa jadi beberapa call db.

[@sinarbaja1663]

belum tau aja kalo datanya udah gede sampe puluhan juta dengan join ke beberapa table bisa mabok dari pada select ke 1 table yang fiedlnya ada banyak.

[@wewegomb]

@@sinarbaja1663 salah satu bentuk nosql / non relational db kan big table entah itu big row atau big column. capek2 normalisasi di level desain ntar juga denormalisasi juga kok di level sistem. kayanya di kuliah emang kurang terlalu dalam topik denormalisasi dan non relational db itu optional ga wajib. tapi kalo kerjaan jaman sekarang kayanya bakal make apalagi kalo pake microservices

[@wewegomb]

@@MuchlisNopq bagus di sisi desain tapi ngga bagus di sisi implementasi. tapi jaman sekarang udah marak nosql, itu naruh data bahkan ada yang kaya main taruh aja ga ada pengaturan data dulu.

[@khairulrizqi4323]

Kak kalo script dalam controlnya gimana kak misalkkan contoh kasus User, biodata_user dan orgtua_user Mohon bantunyabkak 🙏

[@apisaga]

Jika saya punya table user dan sosialmedia (one to one) Desain table sosial medianya lebih baik punya kolom fb, ig, yt, tt yang berisi nama akun(nullabel) atau punya 2 kolom nama_social_media dan nama_akun yang bagus yang mana ya pak eko

[@TriAriSetiawan]

menurutku sih mending punya colom nama akun dan nama_sosial_media, menghindari nanti kalo ada penambahan sosial media jadi ga perlu ada perubahan kolom

[@apisaga]

@@TriAriSetiawan bener juga si, tapi bang bukanya nanti di kolom nama social media bakal berisi banyak hal yang sama ya contoh 10 user punya ig berarti di kolom nama_social_media bakal tertulis intagram 10x , bukanya itu akan buang2 storage database

[@zeinadi]

bisa juga tabel sosial medianya kolomnya jenis_sosial_media, dan nama akun. Jenis sosial media itu isinya tiny int saja, nanti di mapping di programnya, kalau 1 = fb, 2 = ig, 3 = yt Kalau pakai OOP, ini sederhana codingnya.

[@TriAriSetiawan]

@@zeinadi maping nya di program, di hardcode brarti mas.. kalo sosial medianya bertambah nanti kondisionalnya berubah lagi di kode..

[@zeinadi]

@@TriAriSetiawan bentar, tapi kan ada beberapa opsi. Tinggal ditimbang saja. 1. Dihardcode dengan pertimbangan pertambahan sosmed jarang, 1 tahun sekali muncul 1 tidak masalah. Karena kalau coding nya bener, insyaAllah tambahannya sedikit saja. Mungkin cuma 4 baris. Kalau hardcode, performa sedikit lebih cepat karena tidak baca DB. 2. Lookup diletakkan di DB, lebih fleksibel kalau perubahan data sering, misal sebulan sekali ada perubahan. Performa sedikit di bawah hardcode karena harus baca db. Kalau salah coding / query, performa bisa lambat sekali. Tinggal pilih saja sesuaikan dengan kasus nya, tidak ada 1 solusi yang paling baik untuk seluruh kondisi.

[@adenaziz3600]

kalau user profile seperti username ig, fb, twitter dll., itu dipisah juga berarti ya menjadi one-to-one?

[@lapis.lareza]

boleh tidak, karena username adalah field wajib di tabel User jadi melekat di tabel User saja. kecuali kalau kita butuh history username/password , misalnya untuk jika user tsb mau mengubah username tapi pernah menggunakan suatu username lama, jadi disarankan untuk tidak menggunakan username lama tsb.

[@abdulmalikkarim65]

Terima Kasih pak eko.

[@knobhack]

Nice topiknya

[@rudiyanto7626]

terima kasih pak ilmunya...

[@musicforsleepandwork4444]

Sering2 bang bahas kek gini...

[@nandinaulfaldy9132]

Maaf Pak mau tanya apakah benar ORM dan OOP itu membuat rendering aplikasinya jadi lebih lama? Terima kasih

[@apisaga]

Adakah yang masih buat aplikasi web php tanpa oop?

[@zeinadi]

Jelas lebih lambat karena ada penambahan kode dan proses, tapi lebih lambatnya berapa lama? Kalau lebih lambat 20 ms dengan manfaat codingnya lebih rapi, lebih mudah, bisa dikerjakan dengan tim, saya rasa masih Worth It.

[@azharlihan]

@@apisaga ada, wordpress 😄

[@FahriFirdausillah]

@@azharlihan Wordpress berbasis OOP banget sih, ya pastinya ada beberapa yang tidak, tapi mostly udah pake class yang saling terhubung.

[@nasimicin]

ORM memang lebih lambat jika dibandingkan raw query. Tapi ORM dengan query yg optimal bisa jauh lebih cepat(mungkin ndak secepat raw), tapi kasus saya jadi tidak fleksibel dan rumit.

[@marwanwae26]

Kira kira berapa kolom yaa sebuah table itu disebut terlalu banyak kolomnya?

[@abdulazizpr]

Kalo mau lebih kena coba bikin 10 kolom dan 100 baris coba cek setiap pemanggilan table brp ms emang gak terlalu mutlak hitungan ms tergantung spec arsitektur server juga, tapi bisa jadi tolak ukur dari situ nanti mungikin bisa hitung secara matriks

[@my-wz7lm]

untuk id berarti harus sama ya?

[@dimez991]

tidak harus. opsional

[@namadepan2769]

langsung ngerti, thanks min

[@rzl3284]

Apakah kalo misal kita banyak relasi table bakal lemot? Soalnya bakal join banyak

[@lukidwianto3755]

Mungkin yg dimaksud nested join yah? saya kalau nested join sdh mulai lemot querynya

[@dhoifullahluthmajied1543]

Menurut saya, table dipisah itu memudah kan untuk melakukan analisa terhadap beberapa kebutuhan seperti penggunaan statistika dasar dan menimalisir data agar tidak banyak atau berat ya Walaupun query ya agak panjang karna harus join dan menambah subquery ya.

[@daffa_gamink]

setuju mas,

[@muhammadyota7793]

makasih mas eko,, bermanfaat