You're right, your design doesn't feel eligant ;-) It breaks the rules of database normalisation.
Not that that is necessarily a bad thing, sometimes you have to break normal form for the sake of performance. Basically, what you are describing is: Profile -> hasMany -> Questions If the same questions are used in many profiles, you have a: Profile - > hasAndBelongsToMany -> Questions. If you are storing answers to those questions, the answers would be stored in the HABTM join table. On Sep 1, 5:52 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi all, > > I am completing a project using cake where the application requires > user profiles with several hundred, yes several hundred, questions/ > fields. However, only about 20 of these are used in searching, > sorting, etc., the rest are for display purposes only. > > So, I basically included those 20 main fields in my profiles table, > and I added a text field called non_searcable. Then I just serialize > all the other fields and store them there, unserialize them for > display. > > I have seen a design where a 2 column table is employed, field_name > and field_value, and all these fields are stored in that way. It just > seems like a slow, painful method, and you end up with text type > fields storing a string of 4 characters, storing numbers, etc. > > What do you think? For some reason my design doesn't feel 'elegant', > but it works, although is did require a little trickery on the edit > actions and view actions, bet Set::merge was awesome! > > Anyway, just curious. I put a lot of pressure on myself to come up > with super engineered solutions, when often times I think small apps > are over designed. > > TIA, > Brian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
