Hey all, I'm currently working on another internal flask app for work that's in active development with a full user base. My current system has a MySQL table that contains user records, and I'm facing an issue. There's a set of features to be rolled out incrementally, but some of them introduce new user setting that will require entries in that table. Is there a smarter alternative for storing those variables other than adding new columns to the table? I'd rather not have to take the app down to update the MySQL schema for every update. The user base is small (~20 people), so one idea I had was to create a settings table where each record represented a setting with id, keyword, and value columns. Using foreign keys I could then relate them to a user via a one-to-many relationship. Any thoughts? Thanks, Anthony Ford, KF5IBN, Research Assistant, Center for Advanced Radio Astronomy, University of Texas at Brownsville ford.anthonyj@gmail.com
Why do you have to take the app down to update the schema? With only 20 users, updates should be pretty much instantaneous. Also, using key-value stores is usually not a good idea in mysql On Mon, Oct 29, 2012 at 5:54 AM, Anthony Ford <ford.anthonyj@gmail.com>wrote: > Hey all, > I'm currently working on another internal flask app for work that's in > active development with a full user base. My current system has a MySQL > table that contains user records, and I'm facing an issue. There's a set of > features to be rolled out incrementally, but some of them introduce new > user setting that will require entries in that table. Is there a smarter > alternative for storing those variables other than adding new columns to > the table? I'd rather not have to take the app down to update the MySQL > schema for every update. > > The user base is small (~20 people), so one idea I had was to create a > settings table where each record represented a setting with id, keyword, > and value columns. Using foreign keys I could then relate them to a user > via a one-to-many relationship. Any thoughts? > > Thanks, > Anthony Ford, > KF5IBN, > Research Assistant, > Center for Advanced Radio Astronomy, > University of Texas at Brownsville > ford.anthonyj@gmail.com > >
On 29 Oct 2012, at 08:50, Live Flex wrote: > Why do you have to take the app down to update the schema? With only 20 users, updates should be pretty much instantaneous. > > Also, using key-value stores is usually not a good idea in mysql You 20-user logic also applies to bastardising MySQL into a key-value store. Anthony - the long and short of it is that I don't think it really matters whether you add feature-flags to the user table or have a separate settings table. Usually you will scale much faster in users than features, so feature flags in a user table will make sense. If you're changing your application, whatever's serving your application will have to reload etc - as Live Flex notes, changes to your schema will be faster than that process anyway! Cheers, Edd http://eddrobinson.net > On Mon, Oct 29, 2012 at 5:54 AM, Anthony Ford <ford.anthonyj@gmail.com> wrote: > Hey all, > I'm currently working on another internal flask app for work that's in active development with a full user base. My current system has a MySQL table that contains user records, and I'm facing an issue. There's a set of features to be rolled out incrementally, but some of them introduce new user setting that will require entries in that table. Is there a smarter alternative for storing those variables other than adding new columns to the table? I'd rather not have to take the app down to update the MySQL schema for every update. > > The user base is small (~20 people), so one idea I had was to create a settings table where each record represented a setting with id, keyword, and value columns. Using foreign keys I could then relate them to a user via a one-to-many relationship. Any thoughts? > > Thanks, > Anthony Ford, > KF5IBN, > Research Assistant, > Center for Advanced Radio Astronomy, > University of Texas at Brownsville > ford.anthonyj@gmail.com > >