Good one Hector, thanks. Regards, Saša Stamenković
On Tue, Sep 22, 2009 at 5:12 PM, Hector Virgen <djvir...@gmail.com> wrote: > I can't agree with the "expensive process" reasoning. Generally, the values > of the enums will not change unless a new feature is rolled out that needs a > new enum value or if the table gets restructured completely. In most tables, > neither of the above scenarios take place very often (if at all). > That's like saying "adding an index is an expensive process so don't do > it". > > There are some benefits to enums: > > - Enforcement of accepted values at the db level. This is useful for > "status" enums like pending, approved, rejected, denied. > - Enums are ordered by their index, not their string value. So sorting > by status would return rows that are pending, followed by approved, > rejected, and then denied. You can use this order to easily create > paginated > lists ordered in a way that is meaningful to the user. > > When it comes to translating the enum strings to human-readable labels, you > can store the labels in your DbTable class for that table. If the labels are > static, it shouldn't be a problem to add a static method to the DbTable that > accepts the enum string and returns the label (wihout HTML). > > $row = $table->find(1)->current(); > $label = $table->getStatusLabel($row->status); > // or > $label = MyTable::getStatusLabel($row->status); > > A class constant isn't suggested because it can be difficult to access that > constant with a variable. For example: > > $row = $table->find(1)->current(); > $row->status; // 'approved' > echo MyTable::$row->status; // I don't think this works. > > -- > Hector > > > > On Tue, Sep 22, 2009 at 4:06 AM, Саша Стаменковић <umpir...@gmail.com>wrote: > >> Didn't know that really. I'm working on pretty large project and there are >> enums all over tables, works fine. Will check ;) >> >> Regards, >> Saša Stamenković >> >> >> >> On Tue, Sep 22, 2009 at 1:04 PM, till <klimp...@gmail.com> wrote: >> >>> On Tue, Sep 22, 2009 at 12:56 PM, Саша Стаменковић <umpir...@gmail.com> >>> wrote: >>> > You mean dynamic modeling (DESCRIBE TABLE and load in PHP), no need, I >>> think >>> > I'll just have class with constants and one method to return them as >>> array >>> > (using reflection) and thats it. Not really an enum, but will do the >>> job. >>> > >>> > Regards, >>> > Saša Stamenković >>> >>> No, I meant, changing the ENUM - e.g. adding a value to it - is >>> expensive. >>> >>> Zend_Db_Table does a DESCRIBE TABLE anyway, so you can use the data >>> and if you apply the meta cache, it's even faster. >>> >>> Till >>> >> >> >