the table so that I had a "products", "categories" and "stores" table
each with its corresponding Model. Unfortunately, I didn't have any
say in the table design, so I'm stuck with it.
In the interest of time, I may just stick with option #2 and have one
big "Prices" model with all of the table's fields.
I guess what I was hoping was that there would be some way to set up
the model/table mappings so that I could still use models that made
sense (Product, Category and Store) and were all related to each other
like they should be, but still use the "abnormal" table as it
currently is.
On Mar 27, 12:05 pm, Akeda Bagus <ad...@gedex.web.id> wrote:
> On Sun, Mar 28, 2010 at 12:33 AM, bmcelhany <bmcelh...@gmail.com> wrote:
> > Hello,
>
> > I've done some searching and can't quite seem to find what I'm looking
> > for. I have an existing php app that I've inherited that I'd like to
> > migrate to CakePHP. The problem I'm running into is that this app is
> > driven by a single un-normalized table...definitely not a db structure
> > that works well with Cake out of the box. What I'd like to know is the
> > best way to approach setting up my models for this type of situation.
> > Here are some of the fields in the table (named "Prices"):
>
> > id (int), category (varchar), item (varchar), brand (varchar), store
> > (varchar), price, size, etc ...
>
> > As it stands, I can obviously just use the "Prices" table as is and
> > have a single "Price" model in my app with all of the above fields. In
> > a perfect world, however, I'd like to be able to split everything into
> > several more logical models (i.e. Category, Brand, Store, etc), each
> > with the appropriate relationships (i.e. Category has many Products)
> > as well as refer to the main record as "Product" instead of the
> > default table name/model of "Price".
>
> > Is this type of customized table/model mapping possible in Cake? Am I
> > better off just sticking with a single "Price" model? Thanks in
> > advance for any direction you can provide!
>
> > -Brian
>
> Sure, you can still use cakePHP with your current table's structure.
> Several things to notice:
>
> 1. Sometime using abnormal table is good to gain performance,
> especially when you have bottleneck in you database.
> 2. Looking at your Prices table, you can use one Price Model, though.
> But, it sacrifices modularity in your application, you'll end up with
> Price Model getting fat as your application grows.
> 3. To expect your products tagged with defined category, you can use
> Model's callback. And you'll save having find all products that belong
> to particular category you have defined. But, this is not a good
> practice, you still have to touch Price Model again and again when
> feature is added.
>
> The abnormal table way to gain performance is so old. There are much
> better ways than abnormal table when database hit your performance
> (e.g., using memcached, static file caching, etc). I'd prefer to
> separate category and product Models so you can benefit CakePHP's
> Model association.
>
> --
> regards,
> gedex
>
> blog:http://gedex.web.id
Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions.
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
To unsubscribe from this group, send email to cake-php+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
No comments:
Post a Comment