In general, I agree, but here is where my break-down occurs: 1) The fields/questions are not really every used to search or find records 2) The client eventually wants a web-based tool to add/delete questions at any time
Rather than building a table with 200+ fields that are not always used AND a web app that lets them run 'alter table' commands, I chose my odd method. Also, I didn't like the 2 column approach to storing the field name and answer, this is the most common way I have seen people solve the problem. I view this extra information as a "document" rather than fields, almost like storing a Word document they have composed that shows extra information about the profile. Brian On Sep 3, 4:14 am, RichardAtHome <[EMAIL PROTECTED]> wrote: > 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 cake-php@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
