Re: [fw-db] Zend_Db_Table and primary keys...

In general, for the longevity of the project, I would warn against a
keyless table. Its generally considered bad practice which is not an
issue now, but when the next developer wants to add features to the
project, they might find themselves in a hard time without alot of
refactoring.

Primary/Identity keys are essential to the design of Zend_Db_Table. Its
not something we came up with, its the best-practice design we used as
inspiration:

http://martinfowler.com/eaaCatalog/tableDataGateway.html

In fact, its further described as its own pattern:

http://martinfowler.com/eaaCatalog/identityMap.html

That aside, did you try using Zend_Db_Table by adding all columns as the
primary key?

for example:

class MyTable extends Zend_Db_Table_Abstract {
protected $_primary = array('ip', 'visit', ...);
}

YMMV, but it should work for basic operations like insert, and
non-find() based selects. Delete and update will be hard b/c you'll
need to supply something to act as the identity column. You might also
find problems with the row-data gateway (Zend_Db_Table_Row), since
save() and delete() will want an identity to key off of.

Hope you can use some parts of the table/row gateway to do what you want.

-ralph

william0275 wrote:
> Thanks folks.
>
> Yeah, I know about different type of primary keys (composite, etc) but as I
> explain in my example, let's say you have a table where you're logging IP
> addresses... you just can't use an type of composite keys, unless you create
> an auto increment key (datetime won't work either in cases where you're
> getting hundreds of hits per minute).
>
> I'm at the point where I need to decide if we'll simply add auto increment
> keys to tables that don't need them simply to accomodate the framework. I
> don't like it, but I don't see much other choice, and it seems I'm the only
> one who finds having to adapt your database to your framework problematic
> and bad practice.
>
>