The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

simple mysql design question

Seems simple enough but I'm relatively new to db design, so I thought I'd fire it at you old hands.

Db is teh back end for a website. It has to do several things:

1: hold static multi-lingual content for the site.
2: hold info on members, payments and so on.

Is it best to create seperate (mysql) db's for these? This would have these advantages :

 - easy to update static content on prod server without affecting membership info.
 - easy to backup membership info in isolation.
 - can have different permissions for the server - RO for static data, RW for members db.

Are there any significant disadvantages to this approach? Or just better approaches?
revert my buffer
Monday, January 23, 2006
1: hold static multi-lingual content for the site.

  You could use internationalization / globalization software libraries instead unless the content is extremely different. That way you need to update the content only once for all the languages. Chances are that you'll simplify the design by n times (n = number of locales that you intend to support).

2: hold info on members, payments and so on.

  You could have a look at the analysis patterns at and the patterns and practices articles at (dont become an architecture astronaut though). Modify the established practices to suit your needs.
Vineet Reynolds Send private email
Monday, January 23, 2006
My approach is to keep everything in one DB until you have a significant reason to split it. 

A good reason might be membership information that is maintained on its own, where it being gone, does not matter to accessing the static content.  This allows the membership DB to operate autonomously.  If the membership information is required for using the static content, then splitting cost you to set up backups, maintenance, etc. on two instances.

Because you can backup at the table level and security in MySQL is granular enough, your reasons for splitting are minor.  KISS is the best principle.  When performance becomes an issue, or you have a need to extend that is prevented by a single DB, then split it.
Monday, January 23, 2006
Splitting DBs in this case would only complicate things with nothing in return.
Monday, January 23, 2006
+1 to not splitting it up until you need to.

Since you're using MySQL for a web-app, I asume you're using Apache too - are you aware that apache has a mechanism for serving the right localisation of a page based on browser-advertised preference? If you used that, there'd be no need to put both halves in the database.
R. C. James Harlow Send private email
Tuesday, January 24, 2006
my app is all about languages, the multilingual thing is part and parcel of that. So the text would end up in the db no matter what.

Also the text needs to be updated/added regularly without touching the member info. I use a script to do this right now, without too much hassle. So yes, KISS wins out, I guess. Thanks for bouncing the idea about.
revert my buffer
Tuesday, January 24, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz