Unanswered: How to set up a subscriber based database?
I have a database that I would like to sell on a mobile app store but would like to make it subscriber based, that is after signing up a person a empty database would be created and only he could access. So if I signed up a 1000 users there would be 1000 empty databases created. I was thinking that 1 big database could be used and after signing up a person an empty version of the database could be created .
I really don't have a clue as to where to start. I am used to a single user environment. Any help would be appreciated.
I am really new to this. After a new user is registered a new empty database is created that only he has access to . I don't see any interaction is needed on my part. I must be missing something very general. Are online subscriber databases hard or expensive to set up? I can create a stand alone database on a mobile device. The problem is when using a PC the user's data is on the device not in the cloud.
I have developed some mobile device applications and typically what we do is to create a single table with fields that identify perhaps a group level access. Any individual may be placed into a group and as a result would have access to that piece of information. So you would need the main table containing your data along with a group access identifier, a user id table and a user id to group mapping.
If I have a database I know I can add users and give them different access. What I want to know is how can I set up a system where a buyer of my app/database would access a database hosted somewhere and that access-data would be to him alone. My app would be the front end/GUI the table and fields would be hosted elsewhere. If there was only one user or a group of users looking at the same database the would not be a problem. What about 1000 users each one looking at data unique to himself. Do I need 1000 different databases the each one having a different connection table? Or is there some trick to this, some thing I haven't seen or imagined yet?
I am not too sure what you mean? What you are saying is that each user of the application will have its own database. The database will contain numerous tables. Will each table be identical in each of the databases?
Can the connecting user can be readily identified?
If the answers to both the questions above is yes then why not store the information in a single database but include the user id as part of the table so that you can easily identify the records that should be accessed by them and them only.
One thing to consider for the future would be data management. How big will the database grow per user connection? To facilitate data management consider using partitioning. Partitioning can be viewed like a set of buckets. Each bucket stores information based on certain criteria (for instance user id). Collectively they all belong to the same table but in terms of data management if you want to remove a user you simply drop the bucket containing their information.
Again without fully understanding your app and the nature of the data being stored it is difficult to identify a solution that will match your requirements.
I think you have figured out what I am trying to convey. Boy am I green. Looks like I need to study up on partitioning and data management. Do you know of any tutorials or links that explore this aspect of MYSQL.
I have used this feature extensively in Oracle but not in MySQL. I would start off the MySQL documentation. Even for Oracle there is no fast track to learning other than going through the manuals. There are always options available which may not be mentioned on tutorials which might impact your project.