MySQL - a score of things to remember
Archive - Originally posted on "The Horse's Mouth" - 2005-11-12 10:06:05 - Graham Ellis
From the initial raw mass of data through to a fully functional database application .... a long road with many things to learn. I've run two short MySQL courses this week, including some coverage of how to access the data they contain from PHP based web pages and I never cease to amaze myself at how many topics crop up as "must cover before we finish" subjects. I have a habit of writing such topics on the whiteboard during the course so that nothing gets forgotten, and I'm going to share the topics that were on the board yesterday with you to give you an idea of just how wide ranging they are.
My illustrations for this entry are from Bristol Blue Glass and show the first and last stages in the manufacturing process of a glass cat - from the first ball of molten glass to the addition of the stand.
So - what MySQL subjects did I have on my "Must Remember" list on this most recent course?
Load. How to load data that's supplied in the form of text files - perhaps tab or comma separated, and perhaps with various fields encased in quotes, into database tables. The Insert command is great for data for transactions once a system is live, but can be less than ideal for an initial population of tables with heritage data.
Dump. Backups of a database are vital - and it's vital you know how to take backups (and to ensure you know how to reload the data too if you need to, but that's another story)
Join. The linking of data that's held in more than one table in order to produce a human-readable view / report. It's also important to know how to join tables based on the contents of a particular field, and how to generate a report that tells you about orphan records in one or other table - records that won't join with just a regular join and can become lost in the system.
Order. If you select from a database, chances are you'll get more than one row in your result set - sometimes a lot more. How do you control the sequence in which the records are returned by your query (i.e. how do you sort your results?)
sc6. OK - I admit it, that's an internal code and it's not obvious what I mean by it. It's all to do with PHP programming, though, and ensuring that the programs you write in order to maintain and examine the data base are easy to maintain and robust in operation. It leads me somewhat off the MySQL topics and onto PHP, using a design model that keeps the HTML apart from the business logic, and the structure of the application apart from the "web helper" functions.
Security. Log in to a MySQL database by user name and password, and you'll find that your access rights may also be controlled by the name / IP address of the system that you're seated at. You'll be set up so that there's a whole lot of things you can do over the whole environment managed by MySQL - anything from being allowed to select records through to shutting down the server. And in addition you may be given some rights over individual databases. The further rights "per table" and finally yet more rights "per column". It's vital for the MySQL DBA (Database Administrator) who's setting these up to understand what's what in order that security is not compromised.
Table Types. Know your MyISAMs from your heaps from you InnoDb tables. Do you need transaction processing capabilities? Will table locking suffice for your needs or do you need to choose a table type with row locking?
Codd / Normalise. Codd's principles of database normalisation should be given due weight when you design a database. By ensuring that data doesn't repeat itself, that calculated data is not stored, and that no attempt is made to place two values into a single cell, you'll set yourself up for a robust, long lived and maintainable system even though it might make the tables appear to be pretty unreadable to the human eye at first.
my.cnf. Default settings for the MySQL daemon and clients can be set up so that individual users don't have to type in long access strings including host and login names each time they want to access their "home" server.
pivot tables. Where there's a many to many mapping to be defined between two tables, best design principles lead you to create a third table known as a link or pivot table.
denormalise. Having taught you how to normalise data, you may then decide that you can go one step beyond that and denormalise it. As long as you know your update rules and think things through very clearly, there can be benefits in denormalising. For example, keep a copy of the current month's data in a "now" table as well as storing the historic data in the main table, or breaking rows across two tables if you have a rarely-required column that account for the majority of the row content.
timeouts. How to handle large / complex queries from a web front end, where browsers and user's patience is likely to time out before the query is completed.
Where to select and sort If you're front ending a MySQL enquiry system through PHP, do you do your selection and sorting of data in the database, in the program, or do you use a combination?
Special Characters. Make sure that special characters such as " and ' and < entered into forms cannot be used to perform injection attacks on the database ... and that they display properly back to the browser when passed from form to variable, variable to table cell, table cell to variable, and back to the browser as part of the HTML response.
Last Insert ID. How to ensure that new data you add into your tables will join correctly between the tables - finding the automatically generated key and making use of it.
Upgrade - PHP4 to 5 and MySQL4 to 5. The new password security model in MySQL 4.1 that means that old clients may refuse to connect, and what you can do about it. The new mysqli functions in PHP5, and the unbundling of current MySQL drivers at that release. Things to be aware of in your coding and upgrade plans to make sure that what works on the systems you have today will upgrade easily to the systems you will have tomorrow.