Hi, I would like to store possible values in a database, to make them available in a select list. The possible values consist of one ore more of the values between 1 and 100. So if I would put an example in an array, it could be [1,2,19,43,46,81,93]. I''d like to know what the best way to store this is. Is it okay to just put this as a comma- seperated value into my database? I also thought about binary coding, so 1,2,3 would be 111 (=7) and 1,3,4,6 would be 101101 (=45), which I think is nice, but could also become very heavy to dissect. However, the value would be much easier to validate in my model. How would you approach this? Thank you.
> I would like to store possible values in a database, to make them > available in a select list. The possible values consist of one ore > more of the values between 1 and 100. So if I would put an example in > an array, it could be [1,2,19,43,46,81,93]. I''d like to know what the > best way to store this is. Is it okay to just put this as a comma- > seperated value into my database? I also thought about binary coding, > so 1,2,3 would be 111 (=7) and 1,3,4,6 would be 101101 (=45), which I > think is nice, but could also become very heavy to dissect. However, > the value would be much easier to validate in my model. > > How would you approach this?I suppose some of it would depend on the following: - How many records will have this field? - How many numbers on average will be in the field? - How many inserts/selects? I wouldn''t go with a comma separated string, but I might consider using "serialize :my_field" and then simply stuffing the array into the database... all depends on the above I suppose. I''d also look into why you don''t want to make this a has_many association... -philip
> I suppose some of it would depend on the following: > > - How many records will have this field?Not too many. For the moment about 90 records.> - How many numbers on average will be in the field?At first it will probably only be 1, 2 and 3. It might grow later on however.> - How many inserts/selects?After the configuration phase almost no inserts or updates, but quite some selects. But only one per action, I think.> > I wouldn''t go with a comma separated string, but I might consider > using "serialize :my_field" and then simply stuffing the array into > the database... all depends on the above I suppose.Yes, that might be what I''m looking for. Thank you. Any pro''s and cons for this?> > I''d also look into why you don''t want to make this a has_many > association...I didn''t want to overcomplicate things by creating another HABTM association. I do see your point though. I could easily add possibilities when needed in the backend without having to change anything in the application.
On Oct 13, 2009, at 12:48 PM, jhaagmans wrote:> >> I suppose some of it would depend on the following: >> >> - How many records will have this field? > > Not too many. For the moment about 90 records. > >> - How many numbers on average will be in the field? > > At first it will probably only be 1, 2 and 3. It might grow later on > however. > >> - How many inserts/selects? > > After the configuration phase almost no inserts or updates, but quite > some selects. But only one per action, I think. > >> >> I wouldn''t go with a comma separated string, but I might consider >> using "serialize :my_field" and then simply stuffing the array into >> the database... all depends on the above I suppose. > > Yes, that might be what I''m looking for. Thank you. Any pro''s and cons > for this?Based on the above I''d serialize it and not worry about it until it becomes a performance issue. Only real issue is the data is YAML-ized in your database so if you want to get it out using something that doesn''t speak YAML you''re gonna be frustrated.>> >> I''d also look into why you don''t want to make this a has_many >> association... > > I didn''t want to overcomplicate things by creating another HABTM > association. I do see your point though. I could easily add > possibilities when needed in the backend without having to change > anything in the application. > >