changing the database for a different country.

[ajoo]

Hi all !

 

Is it good practice to a have a separate database for a different group of people, say people in a different country. 

 

For e.g. If I run a franchisee business model in different countries, would it be a good thing to have a separate database based on the country?  I was thinking of naming the database prepended by country name like USA_mydatabase, Canada_mydatabase and so on.

Would that be ok ? What is the best practice in such cases.

 

 

Thanks all !

 

[requinix]

Unless there are legal reasons you must observe (like data protection laws? I don't know) then no, don't do that. It'll be a huge headache. Spend some time thinking about it.

[ajoo]

Hi requinix, 

 

Thanks for the reply. Do you suggest using the same database for all sets of people?

 

Won't there be operational issues with that and won't that make querying the database very difficult ? Let me know your views. 

 

 

I have another, maybe unrelated, question question and that is how to handle the superuser for a database?

 

I have a hierarchical structure of users who can access the database. There is however a superuser that supersedes them all. Initially I created the superuser directly into the database while all other users were created using the forms. Is that how a superuser is normally created ? Also the position of the superuser in the database is obviously 1. I was wondering if it is possible to change that id to something else like say 100 or XXXX for security reasons? However that would also conflict with the normal users when that many number of users are added. 

 

So what's the best way to handle this, if any?   

  

 

Thanks.

Edited January 9, 2018 by ajoo

[requinix]

Do you suggest using the same database for all sets of people?

Probably. Why are you considering splitting it? What is the problem you think that spreading out the data over multiple databases is going to solve?

 

Won't there be operational issues with that and won't that make querying the database very difficult ? Let me know your views.

Why would there be problems?

 

I have another, maybe unrelated, question question and that is how to handle the superuser for a database?

 

I have a hierarchical structure of users who can access the database. There is however a superuser that supersedes them all. Initially I created the superuser directly into the database while all other users were created using the forms.

Is that how a superuser is normally created ?

There is no normal way to create such a user. Creating it manually should be fine.

 

Also the position of the superuser in the database is obviously 1. I was wondering if it is possible to change that id to something else like say 100 or XXXX for security reasons?

It's a piece of data in the database. Of course you can change it.

 

But the number itself is irrelevant. Don't think that hiding the user ID will protect you from anything because it won't. Since it won't there's no point trying to be clever by changing the ID.

[ajoo]

Hi requinix, 

 

Thanks.

 

The reason I thought of separating the databases was that the databases worked for different sets of people in 2 different locations. Totally unrelated. So I thought it would be best to separate them. They would also represent 2 separate, though similar, businesses maybe. Maybe with a different web-server for each too. 

 

Besides I thought the querying would be all the more complex with another factor -country -(even though completely redundant) to take care of. These are just my ideas and could be completely wrong. My experience in this is probably zero compared to yours. What are the points in favour of having just a single database?

 

Thanks for the rest of the reply that cleared the superuser password related queries.

 

Thanks loads !

[requinix]

The reason I thought of separating the databases was that the databases worked for different sets of people in 2 different locations. Totally unrelated.

Indeed.

 

They would also represent 2 separate, though similar, businesses maybe. Maybe with a different web-server for each too.

That is a reasonable reason to split them: separate businesses and sites.

 

Besides I thought the querying would be all the more complex with another factor -country -(even though completely redundant) to take care of.

It would be and that's the problem: making the system more complex without any significant reason to do so.

 

What are the points in favour of having just a single database?

It's simple. You don't have to think about which database you need to query if all the data is in one place. It's also good to not segregate everything based on data that can change (country), which then means you have to worry about making sure the data is stored in the right place if/when it changes.