Hi all,

I'm designing a hosted application that many clients will access. I've got all sites running off one PHP code base quite nicely, and now I'm hoping to reduce the multiple databases down to just one shared DB.

(Note: at this stage, all accounts are fictional, so there's no legacy data to worry about).

So instead of each account have it's own database and autonomous tables, I'd like all accounts to share one database. This will:

- make updates easy
- allow each account to be "group aware"
- allow a parent website easy access to all account data

I've added client_id columns to all tables, and things are working fine, with the following exception...

I'm worried about the primary keys (IDs) for each table growing to an unmanageable size pretty quick... 50 accounts * 500 forum posts = 25000 IDs pretty quickly. 50 sites * 5000 members = 250,000 members.

I'm sure this isn't much of a technical/performance issue (with proper indexing), but it's just strikes me as a little strange that the first news post for an account could have an ID of '502846', rather than '1'.

So, I was hoping I might be missing something in regards to primary keys...

Can a primary key (or unique key) be established on two columns (eg primary key = client_id + post id)?
Can an auto-increment column only increment in relation to the client id?


Or am I expecting *way* too much out of MySQL and relational data design?

---
Justin French
http://indent.com.au


-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]



Reply via email to