David Blomstrom <[EMAIL PROTECTED]> wrote on 10/07/2004 05:37:08 PM:
> I'm working on several websites that will be driven > primarily by two databases - Geography and Animals. > The Geography database will feature information about > nations, provinces and states, such as capitals, > population, etc. The Animals database features lots of > taxonomic tables (orders, families, species, etc.), > along with information about diet, distribution, etc. > > I would guess each database could ultimately have as > many as two dozen tables or more. Some of my sites > will need a third database (or extra tables in one of > the existing databases). For example, I'm working on a > big Symbols database table. > > Anyway, I thought I was getting to the point where I'd > better split all of my tables into two or more > databases to help me keep organized. Then I realized > that it could be a lot of trouble figuring out how to > connect to and manipulate two or three databases. In > the long run, it might be easier to just dump > everything into one big database. > > It occurred to me that as I learn more about MySQL, > there may be database-wide operations I'll want to > perform on all my Animals tables, but not on my > Geography tables. If I do put everything in one table, > is there some naming scheme I could use to facilitate > this? In other words, if all my Animals tables feature > the same prefix or suffix, would it help me perform > operations that affect only the Animals tables? Specific names (or name prefixes) are a common technique in organizing the lists of tables in larger databases into some kind of coherent order. Depending on what you want to do to your tables (you weren't very specific) you could leave them all in the same database and just operate on them by specific name. Some commands do take wildcards. If you did preface each table with something that identified which dataset that table belonged to (like a_genera, g_country) then those batch commands would be able to tell one set of tables apart from another. As you decide between one database and two, look at the pros and cons of each scheme compared to the other. For example: Two databases may mean that you can store them on separate drives (increasing throughput). However cross-database queries require extra maintenance. Get in the manuals and search the forums until you think you have identified all of the pros and cons for your situation. Then you can make an informed decision. Shawn Green Database Administrator Unimin Corporation - Spruce Pine
