PHP and variable scope

For some historical reason, ostensibly to do with the design philosophy, PHP
can store data in the user session, but can't store data with application
scope.

ASPs can do it, JSPs can do it, but PHP doesn't, and has no plans to any
time in the future.

For this application, it means that every single user is going to have to
grab hold of a copy of the database schema every time they start their
session. When we reach the point of tens of thousands of hits per second, we
are going to need far more power in the database than would otherwise be the
case. As it happens, this particular application is designed such that users
of a particular size are going to be happy to pay for their own, uncontended
database instance, and no single company is ever going to grow to a size
where they would need anything more.

It is the principle which counts, though.

You could simply write stuff to disk, and put up with the performance
overhead, but then you might as well use a federated or replicated MySQL
instance. A better solution is to use Memcached. It is a highly scaleable
cacheing tool with a handy PHP interface called Memcache. Install the
package, start the daemon, and throw objects at it. For private objects, use
a name prepended to the session id. For public objects like the schema, just
use a common name. Although it isn't a straightforward install, we
essentially have application scope objects.

To use the memcache interface, I would need to rewrite some code. The code
is going to first check for object existence in memcache, then read from DB
and put into memcache if it isn't already there. I probably wouldn't
normally use the options, but it is possible to put objects into memcache
with a limited time, and to restrict the memory usage of the daemon.

Not something I need to worry about yet (the apps are lightning-fast), but
good to know there's a solution when I need one.

PHP - Mysql vs Mysqli vs open database conns

There is an ongoing question over what database the application should use,
and indeed whether it should be database independent.

My view on this is that there is pretty much only MySQL. It is free, fast,
scalable, widely used and easy to find support for. Beyond MySQL, there is
Oracle which isn't free, but is more scalable for certain types of
application. Importantly, if it is being used in a site with expertise in
some other database, MySQL really can be left alone, and it will work away
happily without needing maintenance.

Of course MySQL won't be free forever now that Sun own it, and upgrades are
likely to be sporadic with the best features being a cost option.

MySQL also has two distinct php interfaces. MySQLI, and the older MySQL. The
uptake of MySQLI has been relatively poor even though it has been out for a
few years, possibly because there isn't currently an implementation for a
persistent connection.

As a consequence of all this, there are a few design philosophies:

- All database connections are controlled through a single include.php, the
class needs to be extended in order to be used.
- All SQL outside the class needs to be ANSI-99.
- Accomodating a new database should only need a quick whip through the
parent class. An hour or so's work.
- I am using MySQLI as an interface, although it should be a simple matter
to revert to MySQL, or indeed implement memcache within the parent if
necessary.

...job done, and I am not giong to even bother with the complexities of user
configured database connections. In practise, the configuration of DB
connections gives rise to at least 50% of all installation problems anyway.

Quotation Creation

I've spent some time going through all of the bugs in the quotation creation program this week and have arrived at the point where I can't find any more to fix!

The program emails PDFs, or prints from emails, allows for the entry of notes against both the line or header, maintains details of GST numbers etc.

I'm now at the stage where I can go in one of two directions. Either :

- I expand functionality to allow for multi-currency, variable GST rates, complex formatting against notes and optional quote layouts etc.
- I expand breadth to encompass invoicing, ordering, stock control, credit control etc.

Every step in additional functionality is also a direction toward complexity, so I'm going to head down the latter of the two options above.
With an architecture painfully assembled around the quotes, adding new form types should be straightforward. We'll see, as I start on sales orders.

Example of PDF attached.