I think it's ok if its solves your problem. Just cosider that probably you will not be able to query in SQL that serialized data, and maybe it can't be accessed from any language other than PHP, But if that is ok for you then go wifth it. Anyway consider XML, it is slower but it can be accessed from any decent language.
On Sep 4, 7:47 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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 [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 -~----------~----~----~----~------~----~------~--~---
