Data and Object Modeling: The Schema and the Package

When generating object models, I prefer to package related classes together. For instance, a Calendar would have the following classes:

Since my controller or view will never invoke methods on my CalenderDAO or CalendarGateway directly, I can secure the methods in those classes by setting access="package". Another subtle benefit is that the component files are organized in a single folder...

Now, in my data model I would obviously have a Calendar table, but I might also have related tables like CalendarType and CalendarStatus.

At the risk of labeled a flake, I think it would be interesting to group related tables by schema in my data model like so:

The downside to using a schema to group related tables is that you are thereafter forced to prefix you table names with the schema (SELECT * FROM calendar.Calendar). With all database access managed by a DAO, this isn't a show stopper for me, but if I were to pepper my site with query calls in multiple cfm templates, I would probably curse every extra keystroke. To mitigate this, I could also shorten the package and schema namespace to "cal.", since "calendar." is rather verbose.

Another (small) downside is that MySQL does not support schemas, so I would have to use MSSQL, Postgresql or any other RDBMS that supports schemas.

The question for me is, "if a schema is to a data model what a package is to an object model, does it make sense to use schemas?". Does anyone out there ever use schemas? If so, to what effect?