On Thu, Jan 8, 2015 at 1:03 PM, Collin Anderson <cmawebs...@gmail.com> wrote: > 2) Also keeping all the experiments data in only one table and getting all > the information for one experiment by finding all the row with the same uid > looks a little bit a time consuming process but for now we used the > bureaucracy plugin for the last six month and it doesn't look like it is > slowing down too much the response of the wiki so it might not be so > inefficient after all. Maybe it will scale badly. Here again any advice is > welcomed. > > Databases are usually good at this sort of thing. It shouldn't be a problem, > but might require some database tuning.
this is what _relational_ databases are built for. if you have two tables, one for the description of the experiment (one record per experiment), and another for the statistics (one record per data sample, with a foreign key to the experiment record); then fetching the description of the experiment, plus all the related data will be much faster, simpler, more compact and all-around more efficient than having one table per experiment. databases aren't flat files, use them as designed and they'll perform very well. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSM-Q1Jec_2tE4zyhwt8s0x0-jwpNZCj8mCMVfV_fsgtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
