 |
09-10-2006, 02:04 AM
|
#1 (permalink)
|
|
Junior Member
Join Date: 09-07-06
Posts: 17
Latest Blog: None
|
One Database As Oppose to 8 (Speed effected?)
Well, it's starting to get hard for me to manage my websites and I am trying to clean up. One of my websites is using 8 Databases (one for every script) and I was wondering if I combind all those databases into one would it slow down my sites time to retrieve data? Any input would be great.
|
|
|
09-10-2006, 03:06 AM
|
#2 (permalink)
|
|
Senior Member
Join Date: 09-09-06
Posts: 273
Latest Blog: None
|
I guess it will be slower but it depends on the size of your databases doens't it?
p.l.u.r.
|
|
|
09-10-2006, 03:15 AM
|
#3 (permalink)
|
|
Junior Member
Join Date: 09-07-06
Posts: 17
Latest Blog: None
|
oh, ok thanks, is 7 megs too much? it use to be like a bunch of 200kb databases
|
|
|
09-10-2006, 04:11 AM
|
#4 (permalink)
|
|
Senior Member
Join Date: 09-09-06
Posts: 273
Latest Blog: None
|
Don't ask me, ask someone more into databases  . I'm only here to write my opinion...
p.l.u.r.
|
|
|
09-11-2006, 09:08 AM
|
#5 (permalink)
|
|
Junior Member
Join Date: 09-07-06
Posts: 17
Latest Blog: None
|
thanks, but does anyone really know?
|
|
|
09-11-2006, 10:06 AM
|
#6 (permalink)
|
|
Junior Member
Join Date: 09-07-06
Posts: 17
Latest Blog: None
|
i found the answer, it matters how many querys not how many things are in there.
more queries at a time = more load on server = slow down
size doesnt matter (no pun intended), thanks all
|
|
|
09-12-2006, 01:58 AM
|
#7 (permalink)
|
|
Super Moderator
Join Date: 01-11-04
Location: Sacramento
Posts: 1,539
|
Well if you are querying a DB with 1,000,000 records it will be slower than a DB with 10 records. So technical size does matter. But more importantly is how the db is setup and indexed 
__________________
Learn about Bear Grylls, Les Stroud, Man Vs. Wild & SurvivorMan at Survival TV Shows where Survival comes to life!
|
|
|
09-12-2006, 01:59 AM
|
#8 (permalink)
|
|
Super Moderator
Join Date: 01-11-04
Location: Sacramento
Posts: 1,539
|
And to answer your question combining them wouldn't speed them up since they are operated independently.
__________________
Learn about Bear Grylls, Les Stroud, Man Vs. Wild & SurvivorMan at Survival TV Shows where Survival comes to life!
|
|
|
09-13-2006, 06:08 AM
|
#9 (permalink)
|
|
Senior Member
Join Date: 03-29-06
Posts: 395
Latest Blog: None
|
it will be far quicker to access One database, as opposed to 8, as you can use persistent connections (mysql_pconnect in PHP for example). You only have to select the initial database, and username/password.. and can use that connection then for the rest of the queries.
|
|
|
09-13-2006, 05:14 PM
|
#10 (permalink)
|
|
Super Moderator
Join Date: 01-11-04
Location: Sacramento
Posts: 1,539
|
Quote:
|
Originally Posted by Mrblogs
it will be far quicker to access One database, as opposed to 8, as you can use persistent connections (mysql_pconnect in PHP for example). You only have to select the initial database, and username/password.. and can use that connection then for the rest of the queries.
|
The scripts are not related. Script B wont be using data in Script A so in reality they don't need to be combined because they use COMPLETELY seperate data.
Am I looking at this wrong?
__________________
Learn about Bear Grylls, Les Stroud, Man Vs. Wild & SurvivorMan at Survival TV Shows where Survival comes to life!
|
|
|
09-13-2006, 10:32 PM
|
#11 (permalink)
|
|
Junior Member
Join Date: 09-07-06
Posts: 17
Latest Blog: None
|
Nah, I didn't do this in an attempt to speed it up, I did it in an attempt to organize my databases, I had like 6 different databases for one site and I combined them. I plan on making many more sites and if each of them have 6 databases, then I will be very confused.
|
|
|
09-23-2006, 02:57 PM
|
#12 (permalink)
|
|
Contributing Member
Join Date: 05-30-06
Location: Canada
Posts: 671
|
I suggest you to have a single database per site and all tables in it to have own prefixes. if you are unable to use different databases you may use two prefixes: 1 for the site and one for the project that uses the table.
e.g.: tables for domain: domain.com
domain_pld_links
domain_pld_users
other_domain_pld_links
other_domain_pld_users
I would add the option for using
Pear's cache package at http://pear.php.net/package/Cache/redirected
Svet
|
|
|
09-24-2006, 09:18 AM
|
#13 (permalink)
|
|
Senior Member
Join Date: 06-20-04
Location: Ontario
Posts: 1,758
Latest Blog: None
|
For a 7 MB database I see no reasons whatsoever to split it into multiple databses. 7MB is not even small, it's puny.
Both approaches have pros and cons, and it's not really about which one is better but rather about tradeoffs. A single database you will have a benefit of easier management, backup and more efficient use of cache. When your db grows to a few gigabytes then you may want to consider a bit more advanced configurations. After you have made sure your hardware can keep up of course.
|
|
|
09-24-2006, 10:22 AM
|
#14 (permalink)
|
|
Junior Member
Join Date: 09-21-06
Posts: 19
Latest Blog: None
|
After reading this thread... I too agree this is an over paranoid question... no need to worry unless we all misunderstood the question...
|
|
|
09-25-2006, 03:18 PM
|
#15 (permalink)
|
|
Contributing Member
Join Date: 05-30-06
Location: Canada
Posts: 671
|
did you use the same connection when using different databases
or you're connecting with different users ?
I heard that if you're using a limited user for example user is able to only select and another user to insert,select,update etc. for example in the admin panel this would give some speed.
check this url:
http://www.devshed.com/c/a/MySQL/Enh...ry-Efficiency/
Svet
|
|
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
|
|
|
| Thread Tools |
|
|
| Display Modes |
Hybrid Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 03:24 AM.
© Copyright 2008 V7 Inc Powered by vBulletin Copyright © 2000-2009 Jelsoft Enterprises Limited.
|
|