$tbl_people = ‘my_people’;
$fld_firstname = ‘first_name’;

and for the queries:

mysql_query(”SELECT $fld_firstname FROM $tbl_people WHERE “)

That way I can type and edit the query where it’s used in the code, and still have some more central control over the table and field names.

PS: Could you add some padding on your comments pages’ body? It’s a bit hard to read when the page is in a fullscreen tab or window.

As an example, say you had a table called ‘users’ that has the fields you described. Now imagine for whatever obscure reason you broke this into two separate tables — users_brief and users_details. You import your old data into these two tables, then delete your old users table. Now you define the ‘users’ VIEW, which for all intents and purposes you can use as another table in your query. A view basically allows you to define a “virtual table” that is defined as an SQL query — so you could have a query that does a SELECT * FROM users_brief LEFT JOIN user_details USING (user_id), or something to that effect, and present that as the ‘users’ table. Rename fields, whatever is necessary, and your underlying application will never know the difference.

You can then update your application to the new code (if you even want to) at your leisure - there’s no critical rush to get all the queries changed over while users are clammouring at you about not being able to access the system…..

Because the view is defined within the actual DBMS, the query planner should have the smarts to optimise it and ensure the performance difference between the view and the regular table is minimal.

If you want any more information/help drop me an email
Nothing stops you from updating your code to the new

I cut my teeth on MySQL many years ago, but after running into some of its limitations around the same time I was studying database theory and design made me search around for other options. I decided to give Postgresql a try and have never looked back.

Answering the original question, I do a couple of things:

I have a home grown PHP database wrapper class that handles all my required functionality.. if I ever switch DBMSes, I have a single place to go and change the database specific functions (things in queries is a different story — for that you probably want to look at ADODB or something that attempts to isolate differences in SQL implementations). If I want to debug an application, I can set a flag to output the queries and/or results to follow whats going on. Really handy.

In my queries, I make sure I’m only SELECTing the fields I need. Performance aspects aside, think of security. If you’re pulled every bit of data from the database and the user finds a way to display it, you’re screwed. If you only pull out information you were planning on using, the impact is dramatically reduced. If I ever have some reason to change the underlying database structure, I know I can always emulate the old table using a view.

It all depends on just how many queries you’re going to have. If you’re going to be reusing a lot of the same queries, you might even be worth looking at a 3 tier design:

DBase Business Logic/Rules UI

That way, you can isolate your queries in the database tier, your checks and manipulation in the business logic tier, and your main PHP does the UI. All you need to do is create an instance of your business logic class and use the data provided by it in whatever way you desire in the UI.

On the downside, you add overheads - it takes time to design in a tiered approach rather than an ad-hoc amalgamated design, and in any form of abstraction you add processing overheads. In the end its a tradeoff between maintainability and separation between your functional areas and getting things done in a hurry
On the issue of logic/UI separation, I’ve found Smarty (http://smarty.php.net/) to be absolutely superb. Having all my HTML and other display tucked away in a separate file and leaving the PHP code to do all the logic and input handling really makes things cleaner to work with.