Tryangled Solutions web designing tips tricks

In order to do some of our tutorials (or program with PHP and MySQL in general) you need to be able to run PHP and MySQL. Although most free hosts do not have PHP and MySQL support there are some that do, and there are also many low cost hosting options available. If you already have hosting and are unsure if you have PHP and MySQL support you should contact your host directly. If you are shopping for hosting be sure that they support PHP and that your package includes at least one MySQL database.

Another option is to install PHP and MySQL directly onto your Windows computer. If you are a Mac user you already have the capability and just need to activate PHP and MySQL.

PHP and MySQL compliment each other to do with neither can do alone. PHP can collect data, and MySQL can in turn store the information. PHP can create dynamic calculations, and MySQL can provide it with the variables it uses. PHP can create a shopping cart for your web store, but MySQL can then keep the data in a format PHP can use to create receipts on demand, show current order status, or even suggest other related products.

Although PHP and MySQL can each be used independently, when you put them together it opens up countless possibilities for your site. As the internet progresses, it becomes more and more necessary to deliver dynamic content to keep up with the demands of web surfers and their desire to have information instantly delivered to them online. By learning to use PHP and MySQL you can deliver this information to them on demand.

MySQL is a relational database system that is used to store information. MySQL can store many types of data from something as tiny as a single character to as large as complete files or graphics. Although it can be accessed by most programing languages, it is often coupled with PHP because they work together with ease.

Information stored in a MySQL database hosted on a web server can be accessed from anywhere in the world with a computer. This makes it a good way to store information that needs the ability to change over time, but also needs to be accessed over the net. Some examples that can utilize MySQL are a web message board or a customer’s shipping status.

PHP and MySQL combine to be an easy yet powerful way to create dynamic web pages that actually interact with your visitors. HTML can create useful and well formatted web pages. With the addition of PHP and MySQL you can collect data from your users, create specific content on the fly, and do many other things that HTML alone can’t do.

The beauty of PHP as a language is that it is designed to be used along with HTML. You can use PHP right inside your already existing HTML content, or put HTML tags right inside your PHP coding. When learning PHP you are not making your existing HTML knowledge obsolete, you are instead adding to it to give it more functions and abilities.

MySQL is a relational database management system (RDBMS) based on SQL (Structured Query Language). First released in January, 1998, MySQL is now one component of parent company MySQL AB’s product line of database servers and development tools.

Many Internet startups became interested in the original open source version of MySQL as an alternative to the proprietary database systems from Oracle, IBM, and Informix. MySQL is currently available under two different licensing agreements: free of charge, under the GNU General Public License (GPL) open source system or through subscription to MySQL Network for business applications.

MySQL runs on virtually all platforms, including Linux, Unix, and Windows. It is fully multi-threaded using kernel threads, and provides application program interfaces (APIs) for many programming languages, including C, C++, Eiffel, Java, Perl, PHP, Python, and Tcl.

MySQL is used in a wide range of applications, including data warehousing, e-commerce, Web databases, logging applications and distributed applications. It is also increasingly embedded in third-party software and other technologies. According to MySQL AB, their flagship product has over six million active MySQL installations worldwide. Customers include Cisco, Dun & Bradstreet, Google, NASA, Lufthansa, Hyperion, and Suzuki.

MySQL provides many extentions to SQL which help performance in many common use scenarios. Among these are INSERT … SELECT, INSERT … ON DUPLICATE KEY UPDATE, and REPLACE.

I rarely hesitate to use the above since they are so convenient and provide real performance benefits in many situations. MySQL has other keywords which are more dangerous, however, and should be used sparingly. These include INSERT DELAYED, which tells MySQL that it is not important to insert the data immediately (say, e.g., in a logging situation). The problem with this is that under high load situations the insert might be delayed indefinitely, causing the insert queue to baloon. You can also give MySQL index hints about which indices to use. MySQL gets it right most of the time and when it doesn’t it is usually because of a bad scheme or poorly written query.

MySQL has two primary storange engines: MyISAM and InnoDB. Each has its own performance characteristics and considerations. In the broadest sense MyISAM is good for read-heavy data and InnoDB is good for write-heavy data, though there are cases where the opposite is true. The biggest gotcha is how the two differ with respect to the COUNT function.

MyISAM keeps an internal cache of table meta-data like the number of rows. This means that, generally, COUNT(*) incurs no additional cost for a well-structured query. InnoDB, however, has no such cache. For a concrete example, let’s say we’re trying to paginate a query. If you have a query SELECT * FROM users LIMIT 5,10, let’s say, running SELECT COUNT(*) FROM users LIMIT 5,10 is essentially free with MyISAM but takes the same amount of time as the first query with InnoDB. MySQL has a SQL_CALC_FOUND_ROWS option which tells InnoDB to calculate the number of rows as it runs the query, which can then be retreived by executing SELECT FOUND_ROWS(). This is very MySQL-specific, but can be necessary in certain situations, particularly if you use InnoDB for its other features (e.g., row-level locking, stored procedures, etc.).

Often your choice of indices will make or break your database. For those who haven’t progressed this far in their database studies, an index is a sort of hash. If we issue the query SELECT * FROM users WHERE last_name = ‘Goldstein’ and last_name has no index then your DBMS must scan every row of the table and compare it to the string ‘Goldstein.’ An index is usually a B-tree (though there are other options) which speeds up this comparison considerably.

You should probably create indices for any field on which you are selecting, grouping, ordering, or joining. Obviously each index requires space proportional to the number of rows in your table, so too many indices winds up taking more memory. You also incur a performance hit on write operations, since every write now requires that the corresponding index be updated. There is a balance point which you can uncover by profiling your code. This varies from system to system and implementation to implementation.

Artificial primary keys are nice because they can make the schema less volatile. If we stored geography information in the US based on zip code, say, and the zip code system suddenly changed we’d be in a bit of trouble. On the other hand, many times there are perfectly fine natural keys. One example would be a join table for many-to-many relationships. What not to do:
CREATE TABLE posts_tags (
relation_id int UNSIGNED NOT NULL AUTO_INCREMENT,
post_id int UNSIGNED NOT NULL,
tag_id int UNSIGNED NOT NULL,
PRIMARY KEY(relation_id),
UNIQUE INDEX(post_id, tag_id)
);

Not only is the artificial key entirely redundant given the column constraints, but the number of post-tag relations are now limited by the system-size of an integer. Instead one should do:
CREATE TABLE posts_tags (
post_id int UNSIGNED NOT NULL,
tag_id int UNSIGNED NOT NULL,
PRIMARY KEY(post_id, tag_id)
);

Often you have a table in which only a few columns are accessed frequently. On a blog, for example, one might display entry titles in many places (e.g., a list of recent posts) but only ever display teasers or the full post bodies once on a given page. Horizontal vertical partitioning helps:
CREATE TABLE posts (
id int UNSIGNED NOT NULL AUTO_INCREMENT,
author_id int UNSIGNED NOT NULL,
title varchar(128),
created timestamp NOT NULL,
PRIMARY KEY(id)
);

CREATE TABLE posts_data (
post_id int UNSIGNED NOT NULL,
teaser text,
body text,
PRIMARY KEY(post_id)
);

The above represents a situation where one is optimizing for reading. Frequently accessed data is kept in one table while infrequently accessed data is kept in another. Since the data is now partitioned the infrequently access data takes up less memory. You can also optimize for writing: frequently changed data can be kept in one table, while infrequently changed data can be kept in another. This allows more efficient caching since MySQL no longer needs to expire the cache for data which probably hasn’t changed.