Multiple Database

[GreatEngine]

Dear all,

Saya sedang membuat aplikasi yang terbilang cukup besar, aplikasi tersebut memiliki feature multiple client dengan product yang bebeda - beda ( menuntut dinamis apps ). Planing saya adalah membuat 1 database untuk setiap 1 product / client dikarenakan nama field yang akan dipakai akan dibuat dinamis tergantung kebutuhan client.

pertanyaannya apakah ada solusi yang lebih baik dari planing saya tersebut atau apa kekurangannya jika memkai 1 engine mysql dengan multilpe database ( asumsi database yang akan di create > 100 ).

Thank's

[Aris Setyawan]

Apakah antar client, design schema databasenya berbeda2?

Jika tidak cukup menggunakan sati database saja. Dan untuk membedakan
antar client, maka gunakanlah foreign key client_id pada setiap tabel
pada database tersebut.

> --
> Untuk memposting, kirim email ke mysql-i...@googlegroups.com |
> Untuk unsubscribe, kirim email ke
> mysql-indones...@googlegroups.com | Arsip milis :
> https://groups.google.com/d/forum/mysql-indonesia?hl=id
>
>
>

[Natali Ardianto]

Dulu ada pernah perusahaan besar pakai cara ini (create database baru untuk user baru), dan akhirnya FLOP.

Yang harus anda perhatikan:

• very basic, jumlah open tables. The more databases, the more tables, the more open tables needed, which in return more memory resources.
• scalability in term of product development. Jika ada penggantian satu desain database, maka anda harus menyebarkannya ke multiple databases.
• amount of database connections. Please be aware that accessing different part of databases required new resources (handshake, authenthication, dns, those stuff).
• hard disk seek time lebih tidak efisien ketika disimpan di database terpisah, karena ya tidak berkaitan satu dengan lainnya.

With respect,
 
Natali Ardianto
http://tiket.com

nat...@ardianto.com
twitter blog linkedIn

2012/10/17 Aris Setyawan <aris...@gmail.com>

[Didin Komarudin]

My SQL merupakan database yg cukup powerfull termasuk jika kita gunakan utk level enterprise ( database yang sangat besar dan kompleks). kuncinya adalah design skema database dan metode refereces yg tepat.Tidak perlu database  di pisahkan sampai ke level client karena ini akan sangat boros resource  dan menyulitkan anda sendiri pada saat harus melakukan konsolidasi.

mungkin utk level enterprise cukup split database menjadi 3 saja: masterdata, transaction dan report db

create view master table di db transaction sehingga memudahkan reference key.

misalnya utk skema spesifikasi ClientProduct jadi: ClientID, ProductID, Price,......

tabel client dan product ada di db master.

semoga ada idea yg lebih baik :)

 

salam

dk

 

2012/10/17 Natali Ardianto <nat...@ardianto.com>

[GreatEngine]

Schema databasenya berbeda2 seperti yang mas Aris bilang ( baik master dan transaction ).

[GreatEngine]

schema databasenya berbeda mas baik master maupun transaction.

[Aris Setyawan]

> Schema databasenya berbeda2 seperti yang mas Aris bilang ( baik master dan
> transaction ).

Boleh beda2 database, asalkan JOIN antar tabel antar database, tidak terjadi.
Kalau banyak join antar database, lebih baik gunakan prefix pada nama
tabel saja, misalnya: pln_account dan pgn_account. Ini untuk
menghindari performance yg lambat, karena biasaynya kalau beda
database, maka letak sector disk-nya pasti akan jauh, yang menyebabkan
biaya DISK IO.

[GreatEngine]

Kalo join antar database kemungkinan besar tidak ada karena, karena sewaktu user login apps langsung memilih 1 database yang akan digunakan pada session user tsb, sehingga apps tidak mengakses db yang lainnya.

[Aris Setyawan]

> Kalo join antar database kemungkinan besar tidak ada karena, karena sewaktu user login apps langsung memilih 1 database yang akan digunakan pada session user tsb, sehingga apps tidak mengakses db yang lainnya.

Kalau ini menurutku memang dipisahkan saja antar client satu dengan yg
lainnya. Disatukan jg gpp asalkan setiap table dikasih prefix, nama
client, supaya ketika mencari table yg anda inginkan, tidak makan
waktu lama.

On 10/18/12, GreatEngine <greate...@gmail.com> wrote:
> Kalo join antar database kemungkinan besar tidak ada karena, karena sewaktu
>
> user login apps langsung memilih 1 database yang akan digunakan pada
> session user tsb, sehingga apps tidak mengakses db yang lainnya.
>
> On Thursday, October 18, 2012 2:45:34 PM UTC+7, Aris Setyawan wrote:
>>
>> > Schema databasenya berbeda2 seperti yang mas Aris bilang ( baik master
>> dan
>> > transaction ).
>>
>> Boleh beda2 database, asalkan JOIN antar tabel antar database, tidak
>> terjadi.
>> Kalau banyak join antar database, lebih baik gunakan prefix pada nama
>> tabel saja, misalnya: pln_account dan pgn_account. Ini untuk
>> menghindari performance yg lambat, karena biasaynya kalau beda
>> database, maka letak sector disk-nya pasti akan jauh, yang menyebabkan
>> biaya DISK IO.
>>

>> On 10/18/12, GreatEngine <greate...@gmail.com <javascript:>> wrote:
>> > Schema databasenya berbeda2 seperti yang mas Aris bilang ( baik master
>> dan
>> > transaction ).
>> >
>> > On Tuesday, October 16, 2012 10:22:29 PM UTC+7, GreatEngine wrote:
>> >>
>> >> Dear all,
>> >>
>> >> Saya sedang membuat aplikasi yang terbilang cukup besar, aplikasi
>> tersebut
>> >>
>> >> memiliki feature multiple client dengan product yang bebeda - beda (
>> >> menuntut dinamis apps ). Planing saya adalah membuat 1 database untuk
>> >> setiap 1 product / client dikarenakan nama field yang akan dipakai akan
>> >>
>> >> dibuat dinamis tergantung kebutuhan client.
>> >> pertanyaannya apakah ada solusi yang lebih baik dari planing saya
>> tersebut
>> >>
>> >> atau apa kekurangannya jika memkai 1 engine mysql dengan multilpe
>> database
>> >>
>> >> ( asumsi database yang akan di create > 100 ).
>> >>
>> >> Thank's
>> >>
>> >
>> > --
>> > Untuk memposting, kirim email ke

>> > mysql-i...@googlegroups.com<javascript:>|

>> > Untuk unsubscribe, kirim email ke

>> > mysql-indones...@googlegroups.com <javascript:> | Arsip milis :
>> > https://groups.google.com/d/forum/mysql-indonesia?hl=id