--- On Thu, 7/28/11, Jonathan Duncan <[email protected]> wrote: > I am creating a preferences/settings table for a project. > Assuming this project will eventually have millions of users > and possibly 50-100 preferences per user, what is the best > practice for storing this in an RDBMS? > > I have seen that WordPress does a combination of more rows and > serialized data. > > I have seen some database tables that have 100+ fields, one for > each option. > > Then there is the table with a handful of fields and then a > row of data for each option. If there are 100 users and 100 > options that means and easy 10,000 rows. > > Then again, serializing the data makes the database less > cumbersome, but puts the parsing work into the app. > > Another possibility is grouping the options into multiple > tables. > > Thoughts?
My preference in a case like this is to go either with a simple key-value table and lots of rows, or with some form of serialized data (PHP serialization works, but if storage or IO latency become a problem, something like gzipped JSON, Thrift or Google protocol buffers may be a better choice). The problem with lots of columns is that you always need to add more as your system evolves and more options are added. That can be a pain even when you've got a few users, but once you get into thousands or millions, you really want to avoid changing your table structure whenever possible. _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
