Tolong pilih kategori sesuai, jenis posting (diskusi atau bukan) dan sertakan tag/topik yang sesuai seperti komputer, java, php, mysql, dll. Promosi atau posting tidak pada tempatnya akan kami hapus!
- Bagi Anda yang ingin mendaftar, baca link berikut:
http://diskusiweb.com/discussion/50491/how-to-registrasi-diskusiweb-com-baca-ini-terlebih-dahulu
- Cara menyisipkan kode program supaya tampil rapi dan terformat dengan baik di diskusiweb.com: http://www.diskusiweb.com/discussion/50415/cara-menyisipkan-kode-program-di-diskusiweb-com
- Cara posting gambar/image di post Anda: http://www.diskusiweb.com/discussion/47345/cara-menyisipkan-menyertakan-image-pada-posting/p1

[ASK] struktur tabel dan Insert data ke multi table (MySQL)

Siang master2 :),

Mau minta sarannya, saya lagi mau buat suatu aplikasi web yang isi datanya dari data excel.
Permasalahan pertama, saya masih belum tau akan seperti apa struktur tablenya jika formatnya raw datanya seperti ini:
image

Jadi kesimpulannya dari gambar diatas:
tiap part dapat dimiliki oleh 0 atau banyak model. Dan 1 model dapat memiliki/terdiri dari 1 atau banyak part. (many-to-many, CMIIW)

Struktur data yang sudah saya coba buat seperti ini:
image

Dan yang kedua, bagaimana cara memasukan data tsb kedalam database MySQL (dengan atau tanpa menggunakan PHP), dengan asumsi raw data tsb akan masuk ke 3 tabel yang saya lampirkan diatas?

Sangat berharap jika ada yang membantu, terima kasih :)

Comments

  • edited October 2012
    kalo gw lebih milih pake sqlyog ...

    sqlyog punya fungsi import data XLS -> MySQL
    dan itu bisa di schedule rutin, bisa numpang di scheduler nya windows atau cron nya linux

    kalo masalah tabel ...
    ini gw malah ngeliat dari konsep datawarehouse ... XLS situ adalah FACT table nya
    dan situ mau bikin DIMENSI table nya
    atau masalah : normalisasi / denormalisasi table

    mungkin langkah yg bisa diambil :
    - import apa adanya, pake sqlyog, XLS -> MySQL, jadi table besar
    - jalankan query DISTINCT utk tiap kategori yang dimaksud

    dua tahap itu bisa dimasukan ke scheduler nya sqlyog kalo butuh

    ... atau ...

    coba review dolo : APATAR ... google ajah, gratis !
    sebenarnya ini tools nya ETL
    - bisa menerima input XLS
    - bisa langsung memanipulasi data
    - bisa di schedule juga
    - java base, butuh JRE
  • Jujur gw belom pernah make sqlyog sih, sampai saat ini, gw masih pake metode fgetcsv (dari excel ke csv dulu,*errrg) PHP yg looping itu,,agak lama sih memang kalo datanya banyak, tapi cuma itu yang gw tau saat ini, :(

    soal SQLYog, barusan googling,nemu ini (http://www.webyog.com/product/sqlyog), itu bukan mas? dia aplikasi berbayar ya,,,menarik sihh, emang rencanannya data tsb di update/truncate tiap bulan dengan yang baru. mungkin nt saya coba yg trial tsb dulu kali y mas.

    Mengenai table, intinya sih sbenernya ada data dari excel dengan format seperti itu (diatas, datanya bisa sampe seratusan ribu baris) dan saya ingin memasukannya ke database mysql. Dan kenapa saya buat normalisasi table, karena nantinya akan digunakan untuk aplikasi web mas, yang mana user nantinya bisa search by parts:
    parts apa, maka keluar model-model populer (1-15) apa saja? bisa juga search by model, maka akan keluar part-part nya..begitu mas kira2?

    Gimana mas boo? :)


  • edited October 2012
    yg sqlyog nya 'tul yg itu ...
    sqlyog ada yg versi community ... bbrp fitur dihilangkan ... ndak krusial kalo buat saya
    scheduler nya ada di versi yg community juga

    coba APATAR, fiturnya sebenernya sesuai
    butuh adaptasi ama eksperimen
    agak ribet kalo ndak biasa
    tampilan utk mapping datanya visual pake GUI
  • Iya mas, barusan cek ternyata ada versi communitynya..setelah ini saya download dan coba fitur2nya, untuk ini
    "mungkin langkah yg bisa diambil :
    - import apa adanya, pake sqlyog, XLS -> MySQL, jadi table besar
    - jalankan query DISTINCT utk tiap kategori yang dimaksud

    dua tahap itu bisa dimasukan ke scheduler nya sqlyog kalo butuh"
    ada contoh query kasarnya g mas untuk kasus saya?

    Dan kalo APATAR,, spertinya saya perlu baca2 dulu nanti, karena sepertinya ribet..kl sqlyog kan seperti phpmyadmin, jadi sepertinya tidak terlalu sulit.
  • edited October 2012
    contoh utk yg table parts, asumsi gw fact table nya sudah berhasil di import

    INSERT INTO tbl_parts (parts_no,description) SELECT DISTINCT part,description FROM big_table

    gambarannya kaya gitu, hasil SELECT langsung di INSERT ke table lain


    sebenernya bisa pake REPLACE,

    REPLACE INTO tbl_parts (parts_no,description) SELECT DISTINCT part,description FROM big_table

    http://dev.mysql.com/doc/refman/5.0/en/replace.html

    cuma saya liat ada `id_parts`
    kalo semisal parts_no itu UNIQUE, mendingan gak usah ada `id_parts`
    parts_no nya jadikan PRIMARY KEY saja, supaya bisa jadi rujukan REPLACE

    kalo pake REPLACE, jika ketemu id yg sama, value setelah id langsung di REPLACE
    jadi data gak numpuk2 seandainya big_table berubah


    * gw mo jalan-jalan dolo yo ... *
  • ok mas bo, saya coba nanti querynya meskipun saya belom ngeliat query sql seperti itu (INSERT INTO tbl_parts (parts_no,description) SELECT DISTINCT part,description FROM big_table)..hmmm *berpikir keras* :)

    kalo id_part sya buat supaya uniq, dan mungkin increment..soalnya kl parts_no dijadiin PRIMARY KEY, dia bentuknya varchar, sebab dia ga cuma angka tapi ada hurufnya (bisa liat di attachment diatas)..apa ga masalah tipe varchar dijadikan PK?

    dan data big table/raw data tiap bulannya akan diganti bukan diupdate/ditambah..mungkin nanti di truncate.

    Jalan-jalan kmana mas boo..asikk nih :D
  • edited October 2012
    query na mah standar ...

    bayangin aja query SELECT biasa ...
    hasilnya pasti suatu koleksi row
    nah bayangin langsung seluruh row itu di INSERT ke table tujuan
    biar efektif  ...
    1 perintah, sekali eksekusi query, tanpa perlu loop di script, hasil SELECT masuk semua ke table tujuan

    kagak perlu loop di php na, biar diurus mysql na aja
    yg penting testing dolo query SELECT nya bener atau salah

    biasanya gw gini :

    -- INSERT INTO tbl_parts (parts_no,description)
    SELECT DISTINCT part,description FROM big_table

    jalankan ...
    * -- itu remark SQL, kagak bakal dijalanin
    * SELECT dicoba, kalo bener, baru hapus remark INSERT
     masuk dah datanya ...




    masalah PK (PRIMARY KEY) ...
    kagak masalah varchar, yg penting UNIQUE

    kenapa `parts_no` harus jadi PK :
    - situ mau update berkala dari big_table, otomatis harus ada id penghubung yg dimengerti mysql
    - kalo bikin id baru ( id_parts ) , itu datanya gak ada di big_table
    - otomatis, REPLACE kagak bisa digunain  ... padahal ini bermanfaat banget
    - kalo maksa pake INSERT, terpaksa harus 1-1, soalnya mesti dibandingkan mana data yg sudah ada dan mana yg belum (pokoknya ribet)
    - kalo pake REPLACE, kagak perlu banding-bandingin id, sudah dilakuin sendiri oleh mysql
    - ketemu id sama = di replace , id kagak ada = INSERT

    ini contoh kasus :

    bulan lalu, di big_table ada data :
    parts_no | desc
    11111 | abc
    22222 | def
    33333 | klm

    karena data awal ... REPLACE / INSERT sama saja hasilnya

    bulan ini, di big_table ada data :
    11111 | abc
    22222 | def
    44444 | xyz

    ini bisa jadi masalah ...

    kalo pake REPLACE, parts_no PK, otomatis id 11111 & 22222 cuma di replace doang
    hasil akhir :
    11111 | abc
    22222 | def
    33333 | klm
    44444 | xyz

    kalo pake INSERT, hasilnya bisa gini :
    11111 | abc
    22222 | def
    33333 | klm
    11111 | abc
    22222 | def
    44444 | xyz

    data dobel ...
    kalo mau INSERT sambil liat id ... otomatis loop di script ... panjang lagi ceritanya

    bisa saja di TRUNCATE sebelum INSERT, tapi artinya data lama hilang semua
    hasil akhir :
    11111 | abc
    22222 | def
    44444 | xyz

    parts_no 33333 -nya kemana ?



    makanya saya saranin pake ini :

    REPLACE INTO tbl_parts (parts_no,description) SELECT DISTINCT part,description FROM big_table
  • edited October 2012
    Mas Paus,

    Terima kasih banyak atas sarannya, nanti pasti saya coba querynya..mengenai PK, saya juga pernah baca seperti itu, yang penting unik, Sip ;)
    Soal raw data tsb diatas, memang nantinya di truncate mas, karena maunya si bos tiap bulan itu data dari excel isinya pasti beda (*meskipun saya berpikir pasti ada yang sama bbrapa, tpi sperti itulah maunya) untuk part apa saja yg populer di model tertentu.

    Mengenai struktur table diatas sudah benar y mas? jadi perlu 3 table untuk mengakomodasi raw data tsb.

    yang dicontoh kan baru masuk ke 1 table ya? kalo insert ke tabel model dan tabel parts_model, berarti querynya lanjut dibawahnya kan biar sekali eksekusi, pas raw data dimasukkan dari excel ke mysql. cmiiw



  • @mas boo,

    Udah coba download & install dan jalanin sqlyog tpi fitur2 seperti import external data, sql scheduler/scheduled job ga bisa di SQLYog community, fitur2 itu cuma ada di versi enterprise/ultimated.
    apakah ada alternatif lain selain sqlyog yang support import data dari excel ke mysql dengan kasus seperti diatas mas?
  • yg masalah sqlyog ... masa sih kagak ada ? ntar gw cek ...

    kalo masalah pasti di truncate ... ya silakan

    ttg table ... kayanya yg tabel model kagak perlu, soalnya fixed 15 biji, urut
  • bah, inget gw dolo yg community bisa import

    ya, kalo yg free pilihan tinggal APATAR, atau CloverETL
    2-2 nya java, GUI

    atau kalo mau eksperimen :
    coba tools bawaan mysql sendiri, gratis : MySQL Workbench
    https://www.mysql.com/products/workbench/
    ada tools untuk import, bisa pake source RDBMS (ODBC bisa dipake)
    dan ODBC bisa mengenali file xls

    pilihan terakhir ... tetep pake csv
    dan import nya pake query : LOADFILE
  • jadi kalo table model & model_parts ga dibuat, berarti cuma 1 table parts aja dong mas? dengan table raw data mungkin ya. cmiiw
    kalo seperti itu, fitur seperti mencari search by parts atau search by model di aplikasinya ga masalah y mas?

    Udah coba mysql workbench, dia hanya support csv..yg support excel saat ini yg saya tau EMS SQL manager for MySQL mas,,meskipun trial. tpi mgkn saya pake pilihan trakhir, pake CSV saja.
  • table model nya doang yg kagak perlu

    yg parts_model gak masalah
    toh field model isinya cuma angka 1-15 doang

    kalo masalah import ..
    mending pake command line mysql saja
    pake perintah query LOADFILE

    sekalian nanti di schedule kan

    LOADFILE ...
    INSERT INTO tbl_parts ... SELECT DISTINCT ...
    INSERT INTO tbl_parts_model ... SELECT DISTINCT ... LEFT JOIN tbl_parts ON ...
  • Mas paus,

    ouh jadi data model ambil dari big data/raw data dong ya kalo kayak gitu, cuz sebelumnya saya pikir perlu buat table data model sendiri, dengan menerapkan normalisasi tadinya,:D. oke saya analisa n' liat hasil querynya seperti apa dengan metode seperti itu. Saat ini lagi cari aplikasi mysql admin yang cocok,:)
    Nanti saya laporkan hasilnya ASAP.

    Makasih mas paus :D
  • ouh jadi data model ambil dari big data/raw data dong ya kalo kayak gitu, cuz sebelumnya saya pikir perlu buat table data model sendiri,
    lha ... saya jadi binun :D

    gini aja, disamain dolo presepsinya ...

    coba sih situ rinci sebisanya, logika yg situ tangkep buat tahapan pekerjaannya kaya apa ?
  • Mas boo,

    Saya juga bingung mas tdinya.hehe

    Tapi saya sudah nangkep masukannya, awalnya saya ga terpikirkan untuk buat table big data, setelah tau ada query: insert select
  • Mas paus atau mas boo,

    mengenai tulisana dibawah ini
    table model nya doang yg kagak perlu

    yg parts_model gak masalah
    toh field model isinya cuma angka 1-15 doang

    kalo masalah import ..
    mending pake command line mysql saja
    pake perintah query LOADFILE

    sekalian nanti di schedule kan

    LOADFILE ...
    INSERT INTO tbl_parts ... SELECT DISTINCT ...
    INSERT INTO tbl_parts_model ... SELECT DISTINCT ... LEFT JOIN tbl_parts ON ...
    berarti pd saat INSERT INTO tbl_parts_model,, nge-run nya 1-1 gini dong ya:

    INSERT INTO `tbl_parts_model`(`parts_no`, `model`, 1)
    SELECT a.`parts_no`, a.`model_1` FROM `big_table` a LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no

    INSERT INTO `tbl_parts_model`(`parts_no`, `model`, 2)

    SELECT a.`parts_no`, a.`model_2` FROM `big_table` a LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no

    INSERT INTO `tbl_parts_model`(`parts_no`, `model`, 3)

    SELECT a.`parts_no`, a.`model_3` FROM `big_table` a LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no

    dst.. sampai 15

    Bener tidak? karena struktur di big_table kan seperti diatas. cmiiw
  • sementara gw jawab : YA

    ( lg gw liat kalo bisa disederhanakan pake CASE )
  • edited November 2012
    eh, salah, jumlah kolom tu gak sama ...

    asumsi gw, `tbl_parts_model` field nya :

    - `parts_no` ...
    ini mau masukin id_parts ? atau parts_no ?
    kalo parts_no kagak perlu JOIN ...
    jd gw anggep id_parts yg merujuk id di table `tbl_parts`
    jd gw ganti nama field nya : `id_parts`

    - `model`
    - `id_model`


    INSERT INTO `tbl_parts_model`(`id_parts`, `model`, `id_model`)
    SELECT b.`id_parts`, a.`model_1`, 1
    FROM `big_table` a
    LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no

    INSERT INTO `tbl_parts_model`(`id_parts`, `model`, `id_model`)
    SELECT b.`id_parts`, a.`model_2`, 2
    FROM `big_table` a
    LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no

    dst s/d 15
    ...
    ...
    ...

    ... atau ...

    INSERT INTO `tbl_parts_model`(`id_parts`, `model`, `id_model`)
    SELECT b.`id_parts`, a.`model_1`, 1
    FROM `big_table` a
    LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no
    UNION
    SELECT b.`id_parts`, a.`model_2`, 2
    FROM `big_table` a
    LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no
    UNION
    SELECT b.`id_parts`, a.`model_3`, 3
    FROM `big_table` a
    LEFT JOIN `tbl_parts` b ON a.parts_no = b.parts_no

    dst s/d 15
  • edited November 2012
    di table parts sama table parts_model, jadinya pake parts_no aja mas, karena dia sudah unik. di table big_table tidak ada yang duplicate.

    Oia penamaan nama field di big_table saya pake model_1, model_2, dst s/d model_15.. sedangkan di query mas pake 1, 2,3,dst..agar angka tsb masuk ke field model_type di table parts_model, lebih baik jangan pake model_1, model_2,dst nya ya mas?

    karena saya buatnya seperti ini:

    Struktur tabel/Field2 table big_table
    parts_no | desc | model_1 | model_2 | model_3 | dst...s/d model_15

    Struktur tabel/Field2 table parts_model
    parts_no |
    model | model_type

    Struktur tabel/Field2 table parts

    parts_no |
    desc |

    cmiiw



  • edited November 2012
    kalo pake `parts_no` cukup :

    INSERT INTO `tbl_parts_model`(`parts_no`, `model`, `id_model`)
    SELECT `parts_no`, `model_1`, 1
    FROM `big_table`
    UNION
    SELECT `parts_no`, `model_2`, 2
    FROM `big_table`
    UNION
    SELECT `parts_no`, `model_3`, 3
    FROM `big_table`

    dst s/d 15

    catetan :
    itu bakalan ada yg NULL / EMPTY , soalnya per model ada yg kosong
    butuh di filter WHERE

    INSERT INTO `tbl_parts_model`(`parts_no`, `model`, `id_model`)
    SELECT `parts_no`, `model_1`, 1
    FROM `big_table`
    WHERE `model_1` IS NOT NULL AND TRIM(`model_1`) <> ""
    UNION
    SELECT `parts_no`, `model_2`, 2
    FROM `big_table`
    WHERE `model_2` IS NOT NULL AND TRIM(`model_2`) <> ""
    UNION
    SELECT `parts_no`, `model_3`, 3
    FROM `big_table`
    WHERE `model_3` IS NOT NULL AND TRIM(`model_3`) <> ""

    dst s/d 15
  • Oia penamaan nama field di big_table saya pake model_1, model_2, dst s/d model_15.. sedangkan di query mas pake 1, 2,3,dst..agar angka tsb masuk ke field model_type di table parts_model, lebih baik jangan pake model_1, model_2,dst nya ya mas?

    penamaan field di big_table : gak masalah

    kalo penamaan field di `tbl_parts_model`
    - parts_no
    - model
    - model_type

    ya
    INSERT INTO `tbl_parts_model`(`parts_no`, `model`, `model_type`)
    SELECT `parts_no`, `model_1`, 1
    FROM `big_table`
    WHERE `model_1` IS NOT NULL AND TRIM(`model_1`) <> ""
    UNION
    SELECT `parts_no`, `model_2`, 2
    FROM `big_table`
    WHERE `model_2` IS NOT NULL AND TRIM(`model_2`) <> ""
    UNION
    SELECT `parts_no`, `model_3`, 3
    FROM `big_table`
    WHERE `model_3` IS NOT NULL AND TRIM(`model_3`) <> ""

    dst

    1, 2 & 3 itu otomatis masuk ke field model_type (saya anggep isinya numerik 1-15)
    kalo semisal mau isinya string ...

    SELECT `parts_no`, `model_1`, "model_1"
    ...
    SELECT `parts_no`, `model_2`, "model_2"
    ...
    SELECT `parts_no`, `model_3`, "model_3"

    model_type isinya jadi : model_1 , model_2 , model_3 ... s/d model_15
  • Dan untuk tbl_parts_model tidak perlu membuat primary key nya ya mas? karena kan untuk setiap parts_no memiliki beberapa model..td saya sudah sempat nyoba sih, di error duplicate kl pake PK parts_no, baru nyadar td saya. jadi saya rubah dari PK menjadi index.

    oke, saya coba query mas diatas dulu.
  • kalo rencana isinya kaya gitu : YA, tbl_parts_model gak perlu PK
  • mas boo,
    cara diatas sudah saya test dan bisa, saya test dengan 50-ratusan data.
    Tapi pada saat saya coba pake data realnya sekitar seratusan ribu, querynya lama... bisa beberapa menit.
    ada solusi yang lebih cepat selain cara diatas? atau memang cara itu yang ada? :)

  • edited November 2012
    itu satu2 nya cara ...
    kalo mau lewat script bakal lebih makan waktu lagi

    saat nya migrasi ke database server yg lebih gede :D

    emang jatahnya bikin datawarehouse itu pake db server kelas enterprise kok

    btw, coba maen-maen pake db postgre ... itu "mbah" nya oracle

    atau coba oracle yg XE, free, bisa donlot di situs oracle

    atau :D ... pake oracle yg lisence, bisa donlot di situs oracle juga
    tapi kagak usah bayar support, wal hasil gratis juga
    gw kagak penuh nyaranin, cuma cara ini bisa dipake
    ndak ngarep support oracle, paling kalo ada kesulitan share aja ... jaringannya komunitas
    ndak ngarep patch up to date (gw jg gak bisa share patch nya)

    atau coba pake SQL server expess, free

  • edited November 2012
    iya mas, berhubung sekarang aplikasinya pake PHP&MySQL, so sementara pake cara itu gpp..coz kalo mau ganti database, otomatis kan script PHP-nya juga ikut berubah dan itu "makan" waktu lagi,,mungkin kedepannya saya coba pake database lainnya.
    Thank you mas atas saran2nya :)
  • Mas boo,

    back to this topic again :)
    setelah data di-insert ke database untuk part_no yang sudah saya masukan sekitar 150ribuan (pake query yg mas saranin diatas). maka data di tbl_parts_model menjadi 2jutaan (dan ini belum semua diinsert, saya stop waktu itu).

    Terus masalahnya adalah ketika ada kebutuhan Search data, hasilnya lama sekali keluar mas.
    Pertanyaannya, bagaimana cara agar proses query menjadi cepat gimna y mas?

    CREATE TABLE `big_table` (
      `parts_no` varchar(20) NOT NULL,
      `desc` varchar(50) NOT NULL,
      `model_1` varchar(15) NOT NULL,
      `model_2` varchar(15) NOT NULL,
      `model_3` varchar(15) NOT NULL,
      `model_4` varchar(15) NOT NULL,
      `model_5` varchar(15) NOT NULL,
      `model_6` varchar(15) NOT NULL,
      `model_7` varchar(15) NOT NULL,
      `model_8` varchar(15) NOT NULL,
      `model_9` varchar(15) NOT NULL,
      `model_10` varchar(15) NOT NULL,
      `model_11` varchar(15) NOT NULL,
      `model_12` varchar(15) NOT NULL,
      `model_13` varchar(15) NOT NULL,
      `model_14` varchar(15) NOT NULL,
      `model_15` varchar(15) NOT NULL,
      PRIMARY KEY (`parts_no`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

    CREATE TABLE `tbl_parts` (
      `parts_no` varchar(20) NOT NULL,
      `desc` varchar(50) DEFAULT NULL,
      PRIMARY KEY (`parts_no`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PACK_KEYS=0;

    CREATE TABLE `tbl_parts_model` (
      `parts_no` varchar(20) NOT NULL,
      `model` varchar(20) DEFAULT NULL,
      `model_type` tinyint(4) DEFAULT NULL,
      KEY `parts_no` (`parts_no`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PACK_KEYS=0;

    Beberapa kebutuhan query saya yg sudah saya coba dan nanti akan dipake:
    Cari model:
    SELECT a.parts_no as qparts, b.desc as qdesc FROM `tbl_parts_model` a, tbl_parts b
            WHERE a.parts_no = b.parts_no AND a.model like '%$keyword%'

    Cari Parts:
    SELECT model, model_type FROM `tbl_parts_model` WHERE `parts_no` like '%$keyword%'

    Tolong dibantu masukannya lagi mas.
    Terima kasih

  • edited November 2012
    itu lah yg dibilang, saatnya anda naik tingkat mainan database dengan level enterprise
    arah pekerjaan anda sudah masuk ranah datawarehouse

    http://diskusiweb.com/discussion/38812/harga-oracle-11g/p1
    baca aja pengalaman yg di situ ... itu taon 2009
    ah, mysql...

    coba bikin table denormalisasi antara tree root 550 ribu record, di join dengan table nilai 450 ribu record...
    2 jam ditunggu gak selesai-selesai... dan trus running ntah sampai kapan...

    convert semua table ke oracle, join di oracle
    well... gak sampe 1 menit done... :)



    ...tergantung butuh...
    jangan pernah bilang suatu teknologi lebih baik dari yg lain, selama belum mengenali medan perangnya
    JOIN di mysql kalo melibatkan ribuan data emang berat, meskipun sudah pake index
    meskipun pakai relasi JOIN yg sederhana, tetep berat
  • iya mas jerapah, saya ngerti.
    Cuma saat ini saya lagi menggunakan resource yg ada dulu mas sebelum ke tahap lanjut seperti oracle atau database lain. Selain itu, pastinya saya butuh waktu lagi buat mempelajari jika integrasi dengan aplikasi php yg saya buat..mungkin pasti nanti saya akan coba tp tidak skarang,:) *mikir deadline*

    jadi mungkin pertanyaan saya lebih ke:
    metode apa buat mempercepat query dengan struktur table seperti itu (dengan menggunakan database mysql yg ada) ?
    jika tidak ada metodenya atau ada yg kurang pas dengan strukturnya, bisa kasih saran ga u/ nge-redesign struktur tablenya?
    atau mungkin ada settingan lainnya di mysqlnya gitu? seperti buffer size,cache,dll?

    Terima kasih :)
  • masalah struktur, itu sudah paling sederhana dan optimal
    index gak bakal menolong

    ya satu2 nya cara menghindari JOIN, jadi mau gak mau balik lagi
    untuk pencarian tetep pake table big_table nya
  • solusi alternatif yg saya dapet yaitu dengan LIMIT.
    barusan coba search pake table big_table pake query seperti ini:
    SELECT `parts_no`, `desc`
    FROM `big_table`
    WHERE
    model_1 like '%GS3406%' OR
    model_2 like '%GS3406%' OR
    model_3 like '%GS3406%' OR
    model_4 like '%GS3406%' OR
    model_5 like '%GS3406%' OR
    model_6 like '%GS3406%' OR
    model_7 like '%GS3406%' OR
    model_8 like '%GS3406%' OR
    model_9 like '%GS3406%' OR
    model_10 like '%GS3406%' OR
    model_11 like '%GS3406%' OR
    model_12 like '%GS3406%' OR
    model_13 like '%GS3406%' OR
    model_14 like '%GS3406%' OR
    model_15 like '%GS3406%';

    4321 rows fetched (780 ms)
    hasilnya malah lebih cepat ya, dibandingkan dengan yang saya post sebelumnya (pake JOIN)..klo gitu ga perlu table lain dong ya, cuma 1 table itu. hmm
  • edited November 2012
    kalo LIMIT itu efektif jika tampilan hasil menggunakan paging,
    jika memang membutuhkan hasil menyeluruh (misal menghitung jumlah record), ndak bisa pake LIMIT

    JOIN nya itu yg bikin lemot

    tapi kalo di area datawarehouse, ndak bisa mainan big table terus2an
    emang mesti ada dimension nya, dan itu emang harus pake JOIN
    makanya di datawarehouse mengenal materialized view (view yg diwujudkan dalam bentuk table fisik)
    materialized view itu sendiri cenderung isinya mirip big table, dengan isi sesuai kebutuhan (bentuk mirip, beda isi)

    timbang sendiri lah, yg terbaik pake mana
  • btw, tuh LIKE boros amat :))

    WHERE
    CONCAT_WS(" ", model_1, model_2, model_3, model_4, model_5, model_6, model_7, model_8, model_9, model_10, model_11, model_12, model_13, model_14, model_15) LIKE "%GS3406%"

    silakan coba, hasilnya pasti sama :D
  • Berhubung ini akan ditampilkan di aplikasi web, jadinya pake paging mas, untuk keseluruhan data yang ditampilkan nantinya pada saat export dalam bentuk excel.

    btw, materialized view itu sama dengan view di mysql kan ya mas. setau saya klo view itu, berguna jika data yang ingin ditampilkan sering digunakan, jadi membuat efisiensi untuk query selectnya tanpa membuat lagi. cmiiw

    hehe, makasih mas buat koreksi WHERE LIKE nya :D

  • edited November 2012
    bukan gitu ...
    kalo masalah paging, umumnya ada batasan page terakhir itu halaman berapa ...
    [1][2][3] ... [LAST] atau [1][2][3] ... [XXX]
    bahkan mungkin ada informasi : PAGE YY of XXX

    itu, buat dapetin LAST atau XXX nya, tetep butuh jumlah total record yg memenuhi syarat WHERE tanpa LIMIT

    pan rumusnya gini :
    xxx = jumlah total record
    nnn = jumlah record per page
    jumlah page = ceil( xxx / nnn )

    jumlah total record = 100
    jumlah record per page = 30
    jumlah page = ceil( 100 / 30 ) = ceil(3.333333) = 4

    baru bisa generate link page : [1][2][3][4]



    yg masalah materialized view >< view
    view secara on the fly di generate saat view dipake, cenderungnya juga jadi sub query (hindari kalo bisa)
    materialized view, di generate secara berjadwal, yg dibaca table fisik hasil generate nya

    kalo view,
    efisiensi dalam penulisan SQL : YA ... nulisnya jadi gak panjang
    efisiensi dalam proses query : TIDAK ... lha jadinya malah kaya sub query

    kalo dikasus situ mungkin bentuknya :
    - IMPORT csv -> mysql (big_table)
    - ETL big_table jadi dimensi dan fact table
    - generate MATERIALIZED VIEW dim + fact -> mv, terjadwal, misal tiap hari jam 01:00
    mv bentuk dan isinya bisa jadi sama dengan big_table, tapi bisa jadi beda
    tergantung butuh

    kalo semisal diketahui bakal tidak ada perubahan antara mv dan big_table
    ya, langsung aja pake big_table nya
    ndak perlu repot-repot ETL & generate mv
  • iyaa mas tidak ada perubahan, data table big_table itu diinsert cuma sekali dalam sebulan..bulan berikutnya isi datanya akan berbeda tapi format tetep sama.

    nantinya user bisa
    search berdasarkan parts atau modelnya dari data yang (sudah) ada didatabase tsb. as simple as it :)



  • ada kebutuhan lain selain search ?
  • edited November 2012
    ada mas, kalo yang sebelumnya search berdasarkan 1 keyword yang diinput. Nantinya juga user bisa search/compare/cek untuk beberapa parts_no tapi berupa file yang diupload oleh user, filenya sendiri dalam bentuk excel.

    prosedurnya kira2 seperti ini:

    1. user upload file parts list dalam format excel (isi kolom di excel: parts_no dan description)
    ket: isi parts_list mungkin ratusan baris
    2. cek/compare untuk disesuaikan dengan data yang ada di database (bisa table parts_model atau big_table)
    3. setelah dicek, nantinya tampilan output yang ditampilkan akan seperti big_table, yaitu
    parts_no (dari hasil upload file td) | desc | model 1 | model 2 | model 3, dst.. s/d 15 (yang dapat berupa excel)

    kalo seperti itu, stuktur tablenya ditambah ya mas buat nampung? atau gimana ya?
    terus
    yang saya tau kl seperti itu pasti butuh looping,cmiiw karena satu per satu parts_no dicek.
  • sori, baru balik ...

    kalo model kaya gitu :
    tetep kaya di awal,
    cuma diakhir build lagi big table lain dgn susunan data sesuai kebutuhan yg berbeda dgn big table awal

    jadi search ke big table hasil build terakhir
  • Kalo yang ini saya akhirnya, buat table baru, khusus untuk hasil upload-an ditaruh table tsb mas.. nanti saya akalin pake event buat delete isi table tsb tiap sekian waktu (contoh: 5 menit) karena user abis diupload data langsung export ke excel jadi data ga perlu lama2 di database :)
Sign In or Register to comment.