There's no specific support for DDL (create/alter/drop) statements in
Zend_Db. In particular, MySQL doesn't like it when you try to run a DDL
statement in a prepared query, and the Zend_Db query() method always
uses prepared statements. So you have two options:
1. Use the direct query execution method of the underlying connection
object:
Mysqli:
$db = Zend_Db::factory('mysqli', ...);
$db->getConnection()->query('CREATE ...');
Pdo_Mysql:
$db = Zend_Db::factory('pdo_mysql', ...);
$db->getConnection()->exec('CREATE ...');
2. Do your schema changes outside of PHP code. I don't like to write
apps that make DDL statements. I write SQL scripts for DDL and run these
scripts with MySQL's tools like MySQL Query Browser or the 'mysql' CLI.
Regarding best practices of defining models, this is a frequently asked
question. It's hard to make a one-size-fits-all solution for this,
because application requirements vary so much. In some cases, you can
define a model class that extends Zend_Db_Table_Abstract or
Zend_Db_Table_Row_Abstract. But it's my belief that most apps have
requirements for business logic that make this an ill fit. You'll soon
find cases where you need to write a model class that extends nothing
(i.e. your model is itself a base class) and it may _use_ one or more
Table or Row objects, in addition to other resources.
Both simple and complex cases exist, so don't feel constrained to define
models in a particular way in every case. Step back and do the analysis
necessary to find the best OOP solution. Also keep in mind that there's
no requirement for a given controller action to use only one model
object. It's okay for a controller to create instances of multiple
models. So let the OO analysis determine which code belongs in which
class.
Regarding tree structures and databases, there are several solutions for
representing trees in a relational database using standard SQL.
- path enumeration
- nested sets
- adjacency lists
Here are a few articles that describe how to use these techniques:
http://www.onlamp.com/pub/a/onlamp/2004/08/05/hierarchical_sql.html
<http://www.onlamp.com/pub/a/onlamp/2004/08/05/hierarchical_sql.html>
http://www.intelligententerprise.com/001020/celko.jhtml?_requestid=32751
7
<http://www.intelligententerprise.com/001020/celko.jhtml?_requestid=3275
17>
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
<http://dev.mysql.com/tech-resources/articles/hierarchical-data.html>
http://www.dbazine.com/oracle/or-articles/tropashko4
<http://www.dbazine.com/oracle/or-articles/tropashko4>
http://www.dbmsmag.com/9603d06.html
<http://www.dbmsmag.com/9603d06.html>
Also see the book "Trees and Heirarchies in SQL for Smarties" by Joe
Celko.
http://www.amazon.com/Hierarchies-Smarties-Kaufmann-Management-Systems/d
p/1558609202/
Regards,
Bill Karwin
________________________________
From: Matt M. [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 21, 2007 7:00 AM
To: [email protected]
Subject: [fw-general] Going to start using ZF
Hi,
I'm going to start integrating some of the components into an
application I'm building. Specifically, the DB components.
I'm using MySQL.
If I define my schema using a string, is there an easy/built in
way to create the table or update the schema if it's changed?
Is there a best practice when it comes to defining models on top
of the Zend_Db_Table_Row class? My most complicated model is a tree
based product category. I've been using my own generic non-db tree
handling class but would love to see other Zend-ish example. Is there a
tree component floating around or an example?
Matt
p.s. I noticed the Zend_View_Helper_Uri class requires the zend
front controller. Are there plans to make these view helpers more
generic and re-usable with different frameworks? Why not have the Zend
controller class inject the base url into the view, and then the view
inject it into the uri helper instead of hard coding it into the helper
itself?
