If you have two databases on the same host, one called blog and one called forum, it seems like you can access both using only one database handle? (in PDO)
$dbh=new PDO("mysql:host=$dbHost;dbname=blog", $dbUser, $dbPassword);
This handle is for the database blog, although you can also perform operations on forum using $dbh if you write something like
SELECT website.tableName.fieldName
My questions are:
Is the only reason why you have to specify dbname in $dbh for letting you omit the blog.tableName.fieldName part?
Since my website has two databases, would there be any pros or cons of only using one database handle, rather than creating two handles (obviously one for blog and one for forum)? Possible performance difference?
Does creating a database handle consume any server resources?
It is usually good practice to keep database specific user on any app you make. I would go as far as calling it necessity. That is the reason of keeping the name of the database necessary in the connection. (Hint for reason behind this: What if someone got your dbms password for one table somehow?)
I am not very good at this but I do not think its a good idea to keep two separate databases when one can do. Like in your case, you are not using master-slave or anything. So unless you have some physical limit you are trying to make up for, make them into 1 database (use prefixes for table names to avoid name collisions)
The reason for the previous point comes with this one. Keeping one user for a database or some people even keep two for strange and to some extent justifiable reasons is a safety measure you should follow. For multiple users, you need to make multiple connections, which means for every page load you will be connecting to the dbms twice! simple math 2x load (yes, it eats resources, every single line of code does) Simplifying it, think of a man who needs to walk to the grocery store for everything you ask for, gets only 1 thing at a time. if you give him 2 different grocery stores, the man will need 2x time and energy to do the same work.
Yes, you can omit it. Or switch with running USE databasename;.
Use one handle, seems a waste to make double the connections.
Yes, hence (2).
Related
I am wanting to hear what others think about this? Currently, I make a mysql database connection inside of a header type file that is then included in the top of every page of my site. I then can run as many queries as I want on that 1 open connection. IF the page is built from 6 files included and there is 15 different mysql queries, then they all would run on this 1 connection.
Now sometimes I see classes that make multiple connections, like 1 for each query.
Is there any benefit of using one method over the other? I think 1 connection is better then multiple but I could be wrong?
Creating connections can be expensive (I don't have a reference for this statement as yet Edit: Aha! Here it is) so it seems as if the consensus is to use fewer connections. Using a single connection for all queries on a single page seems to be a better choice than multiple connections.
In PHP+MySQL usually there is no much sence to use multiple connections per page (just slower and a little more RAM consumed).
The only way it might be useful is when you alter connection paremters which might interfer with other pages (like collation). But good PHP programs usually never do that kind of stuff.
Also, it is a good idea to enable persistent connections, so that 1 MySQL connection would be reused across multiples page executions.
If really depends on the level of activity you suspect the site will generate - if it's a high traffic web site, you'll soon run out of connections (unless you set the adjust MySQLs max connections to a stupidly high level, but that'll eventually grind the server to a halt).
I'd generally recommend that the front end of a web site should use a shared database object (singleton is your friend), as it doesn't require a great deal of discipline to write with this is mind and you won't waste time making connections. If you require additional concurrent queries on the backend, it shouldn't be that much of a deal as this isn't likely to be a highly trafficked area.
Its not recommended to execute multiple small queries where the work can be done using just one query, you can use a single query to get data from multiple tables and ieven multiple databases. see the link below:
http://www.x-developer.com/php-scripts/sql-connecting-multiple-databases-in-a-single-query
I don't see any benefit of using multiple connections, I 'd rather think it is a sign of bad structure. These are the reasons I can think of against using multiple connections:
You have to initialize the database multiple times. Setting conection properties upon connection establishment (like SET NAMES UTF8) would have to be done on multiple line.
It is definitely slower than a single connection.
A non-technical reason: Someone working with your code will most probably not expect it and might spend hours debugging the connection properties he had set in another connection.
Having a global connection object (or a class providing one) is the much better approach in PHP.
Are you sure the classes that make multiple connections aren't just returning a reference to the already open connection when one is open? I've seen a lot of stuff structured that way. It really is better performance-wise to use only one connection per page.
I am currently developing a PHP website and since the website will be used by many people, I just want to know if there will be a problem if there is multiple database access at the same time from those different users, and if so how to go about it. Thanks in advance.
SIMPLE ANSWER: As long as your code is well designed, No.
Elaborating: In a MySQL server, databases are made to work very efficiently and to handle a large set of tasks. Among these tasks include the constant querying of tables inside separate databases, among which include statements that SELECT data, UPDATE data, INSERT rows, DELETE rows, etc.
There are some corner cases that can happen however. Imagine if two people are registering on your website for the first time, and both of them want to register the username Awesomesauce. Programmers often code algorithms that first check if the current username exists, and if it doesn't, INSERT a new row in the users table with the new username and all the other relevant info (password, address, etc). If both users were to click the Register button at the same time, and if your code was badly designed, what could happen is two rows could be created with the same username, in which case you would have a problem.
Luckily, MySQL as features to prevent such corner cases. A UNIQUE INDEX could be implemented on the username column, hence forcing the database not to accept one of the two users who tried to register the name at the exact time.
All in all, if your code is well designed, you shouldn't have a problem.
It all depends on how much traffic, how large your site's database is and a host of other factors.
But for starters, i'ld say there's really nothing to worry about.
I think you should go with MySQL since you are just starting out with php, but you can pretty much use whatever you want with PHP's PDO http://php.net/manual/en/book.pdo.php. There is a lot of online support for mysql with php, so I would start there.
I would suggest make multiple tables in same db rather than multiple db. Though there won't be any problem even if there are multiple db access at same time.
Refer following link to know how its done:-
How do you connect to multiple MySQL databases on a single webpage?
While your question is way too broad, if you want horizontal scaling (adding more servers) look at a PHP/NoSQL solution. Otherwise, something like PHP/MySQL will be fine.
A bit of reading for you here: Difference between scaling horizontally and vertically for databases
I'm integrating punBB into my existing site. Is it better to continue using one DB and add the new tables into my current setup or is it better to maintain a second DB for the forum. I guess my main concern is performance and maintainability. It seems easier to maintain just one DB but are there performance gains or losses with a second DB?
Assuming punbb does like every other forum and prefixes the table names (eg. punbb_users, punbb_messages, etc.) and you're not going to have any table name collisions, one database should be fine.
As far as performance, that depends on how integrated your setup is. Opening another connection to a separate database may be a little more overhead, however re-using the same connection for normal site intricacies and the forum itself would be more efficient. Once thing you may question is how big your site is and how much traffic it does as not every circumstance makes a new connection negligible.
If it makes sense logically and everything is self-contained, I would probably go with one database. it also makes database backups/restores easier as it's all one entity, but if you're on a hosted provider that may not matter as much to you.
it depends on flavor. Some will prefer same Database and put different prefixes to tables something like punbb_, joomla_ et al so that they can have single connection object and have things in place. This make centralizing login an easier task as they can somehow share one users table. However, if they don't share anything (other than being owned by same person and same server may be) I suggest you put them separate. That will easy backup and make a good organization. But as I said, preference matter.
One note though, if you share the database, be careful not to drop existing tables accidentally, so backup everything. I know it might be in your head but just a remainder!
I'm working with a programmer who doesn't want me touching his database...
I would like work with a database instead of hard coding my content but don't want the sites performance to suffer.
Is it bad practice to query two different databases on one page?
If its not a problem is there a limit to how many databases you can query per page?
PS the site is php/mysql
me touching his database
That's probably because there is a layered architecture in place and you're not supposed to be talking to the database directly.
Otherwise, if you've come already to the division - "my" database, "his" markup, it's a recipe for disaster.
Is it bad practice to query two different databases on one page?
No, if there is a real need to do it. Yes, if only because somebody declared the database their property and you've got to have your own.
No its not a problem, in some scenarios it's even a pretty good approach.
It depends on if the databases are holding related data. If they are related, it makes sense to keep them in once database. The programmer could then give you a user account with limited access so that you can't corrupt other things.
There is some cost to making a new connection, but it will likely be negligible if you are doing a number of queries.
Can you have a separate schema in his DB? If so, then you could save some connection building /destruction time.
Will you be storing data/relational data in the DB? If not, can you get away with include("file.php")
All that being said it's not a bad practice to have multiple DBs on a page you just need a good reason to do it.
i routinely hit a estimate database and a reference database aka customer live in texas, closest office is 150 miles away.
I am wanting to hear what others think about this? Currently, I make a mysql database connection inside of a header type file that is then included in the top of every page of my site. I then can run as many queries as I want on that 1 open connection. IF the page is built from 6 files included and there is 15 different mysql queries, then they all would run on this 1 connection.
Now sometimes I see classes that make multiple connections, like 1 for each query.
Is there any benefit of using one method over the other? I think 1 connection is better then multiple but I could be wrong?
Creating connections can be expensive (I don't have a reference for this statement as yet Edit: Aha! Here it is) so it seems as if the consensus is to use fewer connections. Using a single connection for all queries on a single page seems to be a better choice than multiple connections.
In PHP+MySQL usually there is no much sence to use multiple connections per page (just slower and a little more RAM consumed).
The only way it might be useful is when you alter connection paremters which might interfer with other pages (like collation). But good PHP programs usually never do that kind of stuff.
Also, it is a good idea to enable persistent connections, so that 1 MySQL connection would be reused across multiples page executions.
If really depends on the level of activity you suspect the site will generate - if it's a high traffic web site, you'll soon run out of connections (unless you set the adjust MySQLs max connections to a stupidly high level, but that'll eventually grind the server to a halt).
I'd generally recommend that the front end of a web site should use a shared database object (singleton is your friend), as it doesn't require a great deal of discipline to write with this is mind and you won't waste time making connections. If you require additional concurrent queries on the backend, it shouldn't be that much of a deal as this isn't likely to be a highly trafficked area.
Its not recommended to execute multiple small queries where the work can be done using just one query, you can use a single query to get data from multiple tables and ieven multiple databases. see the link below:
http://www.x-developer.com/php-scripts/sql-connecting-multiple-databases-in-a-single-query
I don't see any benefit of using multiple connections, I 'd rather think it is a sign of bad structure. These are the reasons I can think of against using multiple connections:
You have to initialize the database multiple times. Setting conection properties upon connection establishment (like SET NAMES UTF8) would have to be done on multiple line.
It is definitely slower than a single connection.
A non-technical reason: Someone working with your code will most probably not expect it and might spend hours debugging the connection properties he had set in another connection.
Having a global connection object (or a class providing one) is the much better approach in PHP.
Are you sure the classes that make multiple connections aren't just returning a reference to the already open connection when one is open? I've seen a lot of stuff structured that way. It really is better performance-wise to use only one connection per page.