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

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.

Ralph Schindler-2 wrote:
>
> Generally speaking, your database tables should have a primary key of
> 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.
>
>

--
View this message in context: http://www.nabble.com/Zend_Db_Table-and-primary-keys...-tp25117083p25119438.html
Sent from the Zend DB mailing list archive at Nabble.com.