some sort- this is both a best practice as well as a requirement for
some vendor-based systems to internally manage row data.
In Zend_Db, since its considered a best practice, you should have a
primary key. This can be:
* surrogate key aka an autoincrement key
(http://en.wikipedia.org/wiki/Surrogate_key)
* a natural key
(http://en.wikipedia.org/wiki/Natural_key)
* OR even a composite key
(http://en.wikipedia.org/wiki/Composite_key)
but in general, you should have a key of some sort :) Even when you
work with a spreadsheet, the rows are identified by a number of some sort.
-ralph
william0275 wrote:
> I sometimes have tables that don't have primary keys, for example a table
> where you have a site_id and an ip address that will be processed by a cron
> later to protect the site from shared accounts, etc etc... There is no
> primary key possible, because even a timestamp could break with more than
> one IP inserted in the same second.
>
> Am I the only one who thinks Zend_Db_Table suffers from trying to do too
> much, or at least forcing you into something you might not need or want? The
> documentation states the class is an implementation of the Table Data
> Gateway pattern, but the class is clearly more specific than the pattern.
>
> Anyway, I guess this will end up being a random rant, but the way I see it,
> Zend_Db_Table should be allowed to be used without a primary key, as you see
> fit, but should throw exceptions when you're trying to use functionality
> that requires a primary key, like find(). I would still use insert and
> delete methods (you never need the update method with tables without a
> primary key, or I think your database design is faulty, unless you want to
> mass update).
>
> Also, bypassing Zend_Db_Table to handle these exceptions is a source of
> problem in projects where Zend_Db_Table is the main gateway for data access.
没有评论:
发表评论