I am making a site in django [mysql] that will have to be scalable, so my question is what is better for multiple users with same kind of data
have a db per user , or have one big monolithic db?
Please advice of the design pattern preferred for this?
thanks!
Normally, You use a single database for multiple users with the same table schema, unless your requirement makes you create multiple DBs. Especially, if you have the same kind of data for each user, you must handle access rights and other things in your application side, not in your database side.
Django hava a nice User authentication/authorization system that lets you define permissions and lets you control user access rights (creating a new record, updating an existing one and deleting one) for each type of data that is represented by a table in your system. Also you can define custom permissions to control access rigts as you wish.
Separate databases are almost never the correct answer but there are cases in which it's appropriate. Unless you have very special needs, and in absence of any real description of what your project is, a single database is likely to be the correct decision.
Related
I was looking into how to add a create user account/login to my website, so I could have members join and come back, etc and ended up finding out in order to do that, I'd need to create a new database in my SQL, to store the users credentials, I dont have the option to create any new databases by my webhost. Only the one database is what I can use. Could I just add this to my existing database? Do I really need more than 1 database on SQL for my website? If so, could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website? Im sorry for the few questions, Im really new to all this and so confused and overwhelmed.
You can create multiple tables in same database.just make a table with fields such as user id,password etc. and use it for saving,fetching user details using sql queries.
Could I just add this to my existing database?
Yes, you can tables to the existing database.
Do I really need more than 1 database on SQL for my website?
There are a lot of websites that use just one database. Some websites use connections to multiple databases. What information is stored in which database is frequently the result of factors other than the website. The ability to connect to multiple databases means that a website could use authentication/authorization info from one database, store user profiles and submissions in another, and read information from other sources (for example, historical stock prices, stored in another database.
All of that information could be stored in a single database. Having them as separate databases means that the databases can be managed separately (frequencye of backups, replication to DR site) and makes it easier to share the database across multiple applications. (For example, we would probably want employee payroll and health care information stored in a separate database, with separate access controls.
Could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website?
It may be technically possible to do that, but that's not the way you want to go. That would add another dependency... the website at the web hosting provider would be dependent on having access to another database, which is not being backed up and managed along with your website.
Is there a way to create a new database in an ROR app automatically.
What I'm trying to do is create a new database for each new user that signs up for my site. so if the new user sign-up is successful a new database with some empty tables will be created.
Ever new user will get a new database and ever new database will be the same tables inside of it, but the information that each user will store will be different.
the reason I believe I need this due to if the user no longer want to use my system I can provide them the information that they stored on my DB and then drop the DB and tables with great ease
what I'm looking for is something like the mysql_create_db() in php
Dont you think that you are making a simple system complex? The way you are thinking is not scalable. For example, if you have thousands of user you have to create same amount of database tables!! Where most of the tables might be of no use. That is definitely ridiculous...
If you just want to achieve the followings
Each user will have his own data.
User may want to export data.
If users close his account you will delete all his data
then you better think the whole as a single application with a single database. Design your database accordingly and better look for the best DRY practices of rails to implement that.
This is not a good way to store users in a relational database, especially when using an application framework like ruby on rails which depends on your following convention over configuration.
Have one user Model and use the Devise and then Cancan gems to manage roles and permissions. There's no need to reinvent the wheel here and that's just what this would be doing.
If there are other considerations such as size or performance, please spell them out in more detail. The reasons you give (ease of management) would not be a good reason to go down that path.
It's an interesting idea and has uses in other areas, but really not so good for your standard user tables.
I am making a semi-simple web application for my mother using php, mysql, and javascript.
She is a teacher, and this wil allow her to manage various components of her lesson plans.
For each component there is a table, and for each component that can contain another component there is another table that holds the relationship. (That table type has two columns each has a foreign key to the related tables)
I am nearly done, but she now wants to allow her friends to use this, I don't care too much about sql injection, but I would like to implement User Control so that only users that create a component can view and edit that component.
I also want them to be able to make public components, so that users can copy components to their own dataset.
My question To implement the user control should I have each user have there own database instant, or should each table have an owner column and column for public/private status, or is there another alternative that I have not thought of.
An issue that I see is that it would require additional mysql query when creating the relations between components because I would need to check that both components user tag matches the current user.
Any feedback/suggestions are helpful
Update The only people using/accessing this will be other teachers, that will be developing their own lesson plans
I would certainly implement this within the same database. Having a different database for each user is not a good solution in this case. Think, for example, how you would build a search function if each user's data is in a separate database will clashing UIDs. It would be a nightmare. Separate databases work where each database serves a separate application and there are precisely zero relations between the data in different databases.
So that brings you on to how to implement it. This will depend on your model. Will each lesson plan only ever have, for example, one and only one owner? If so, then adding that info to the components table might work. Or else you might need a separate table to define ownership and hence access to the different components. Either way, I would make sure the access logic is decoupled and encapsulated in your application to make sure you can change it in the future. Imagine for example you start with a simple, single-owner model but the site grows and grows and soon groups of people all need ownership/edit access to components.
I am developing a web application in which a user can Create a table in data base. I am thinking on taking the attribute names and table description from user and put them into SQL query and execute it. But the drawback is that if this application is installed somewhere else all the db connection parameters have to be changed secondly it will be hard coded. Or is this the approach in software industry?
Another approach I can think of is taking all the information about creating a new table from user and inserting them into one table and have some kind of trigger on this table which creates a new table everytime when insertion is performed into the first table.What would be the SQL Script for such thing if my approach is correct?
I am using SPRING - MVC, Hibernate, MySQL, REST web service
Please correct me if I am thinking in wrong direction. TO be honest I am not clear on how I am going to do this.
Thanks
This is risky, since a database schema with a vague and ever-expanding schema will become difficult to manage. Your problem isn't how to manage the credentials, which you would have to handle securely whether users were creating tables or not. Your problem is why it seems necessary for users to create tables.
Are you building an interface to manage arbitrary databases? Maybe phpmyadmin would give your users everything they need.
Or are you doing something not quite so general purpose and open ended? Perhaps with a sufficiently rich table design, you can give the users what they want without requiring that they build their own tables. What information do users have to put in a table that it looks like they need to build their own?
If you are more specific with your objectives, we could be more helpful.
I'm trying to split a database into two pieces -- a backend that updates automatically, and a front-end that allows searching and adding/editing comments. The data in the source database is pulled together from multiple tables into a pair of queries, and I want to use these queries as the source of the current database.
Access 2007 supports splitting a database into multiple pieces, but not in the way I'm looking for. It keeps the tables in the source database and puts all the forms, queries, reports, and macros into the new database. The tables and queries are already in the back-end, and this new database should just provide a good GUI to the end-user.
Access 2007 also supports linked tables, but these can only use a table as a source, not a query object.
I was thinking that the best way to do this would be to do a SQL query along the lines of
SELECT * FROM SourceQuery IN "C:\Path\To\ExternalDB.accdb";
Is what I'm working towards even possible, and would this be the best way to do it?
Since its still relatively early in the project, rearchitecting the database isn't out of the question, but is something I'd prefer to avoid.
You described the usual Access BE-FE division correctly: only tables in the back-end. I'm aware not all DB programs do it that way, but this is Access and my approach would be to honor the usual division. (And you hardly have a choice in that you can't "link to a query" in Access.)
Reviewing your comment ('There is a specific reason ...'), I think this would possibly mean
adding a few more tables to the back-end, essentially buckets (import-data in ready form; export 1; export 2) that allow all users to get to consistent processed data;
making a small admin FE that sits next to the BE and stores your modules, queries for export, and export routines; and
having some redundant queries on the user FE. This is vexing in my own work. I just try to design sturdy stable "building block" queries in those roles, and keep their number to a minimum.
Hope I'm understanding you correctly, but the most sensible solution would be to link the tables in the backend DB and copy the queries to the UI database. Those queries would still be able to access the uderlying tables (via the linked tables) without issues and would be accessible through normal means to your forms and VBA code.
Is there a particular reason you don't want the queries in the UI database?