On Apr 7, 3:46 pm, Mark Murphy <mmur...@commonsware.com> wrote: > On Thu, Apr 7, 2011 at 6:33 PM, Nathan <critter...@crittermap.com> wrote: > > Would a shopping list application only allow you to have one shopping > > list, called default? > > A lame one would, yes. > > A sensible implementation would use one database, with a "lists" table > to identify the lists, and foreign key relationships in the other > tables as needed back to the lists table. This is a fairly basic > relational database design. > OK, a shopping list is a bad example. For the record, I've never written one. In the real world, there is some retrieval overhead of having multiple virtual databases in one physical database. But this wouldn't show up in a shopping list application.
But does Excel really do that? Last I checked, I could create multiple .xls files. Each one could be considered a database, but they are stored in separate files. > > I really don't think my scenario is that outrageous. > > I would say that the code smell increases as the square of the number > of databases. So, more than one database is not necessarily stinky, > but 100 databases would certainly qualify as "outrageous" in my book. > We can agree to disagree about how stupid my implementation is. There are more details than I can share here. I do not require nor encourage users to create 100 databases, but I don't see any reason to limit them just so my code smells better. They could certainly use one database. It would be unlikely, though not impossible, that they would open and close 100 databases in one session, and not more than one open at a time - currently. Though under Diane's suggestion of never closing them, there could be many. Nathan -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
