Here is a question from a newbie. I need to store music data(URL, artist ...) for each user. Should I put all data in one single table with distinct keys for each user. Or maybe it is good idea to have separate tables for each user.
I am making an online player.
Thanks in advance
You will create huge database if you are going to create seprate table for each user, make a table structure that will contain entries of all user in single table....
Create a single table with different user privileges for ex create an
group column table and provide different grouids to different users
e.g. groupid =1 for admin ,2 for normal user etc.
A separate table for each user is not appropriate.
You need one table for the music data (URL, artist, ...).
If the only item you store about users is the name, you can put that into the music data table as well without violating database design principles too much.
As soon as you store additional information about users (e.g. password, e-mail address) you need a second table for the user data and connect the music data to the user data via a foreign key in the music data table (or, in case of a n:m relation, a third table).
If you are looking for further information about database design, keywords are functional dependency and normalization.
Enhanced relationship diagrams may help you in designing your database. It might be worth mapping out your proposed database using these diagrams before you implement them.
This is a good tool to make sure you have a correct database design for you and as previously said below deal with functional dependency and normalization.
This is a good website to help you if you haven't done this before: http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html
Related
Let us say I need to design a database which will host data for multiple companies. Now for security and admin purposes I need to make sure that the data for different companies is properly isolated but I also do not want to start 10 mysql processes for hosting the data for 10 companies on 10 different servers. What are the best ways to do this with the mysql database.
There are several approaches to multi-tenant databases. For discussion, they're usually broken into three categories.
One database per tenant.
Shared database, one schema per
tenant.
Shared database, shared schema. A tenant identifier (tenant key) associates every row with the right tenant.
MSDN has a good article on the pros and cons of each design, and examples of implementations.
Microsoft has apparently taken down the pages I referred to, but they are on on archive.org. Links have been changed to point there.
For reference, this is the original link for the second article
In MySQL I prefer to use a single database for all tenants. I restrict access to the data by using a separate database user for each tenant that only has access to views that only show rows that belong to that tenant.
This can be done by:
Add a tenant_id column to every table
Use a trigger to populate the tenant_id with the current database username on insert
Create a view for each table where tenant_id = current_database_username
Only use the views in your application
Connect to the database using the tenant specific username
I've fully documented this in a blog post:
https://opensource.io/it/mysql-multi-tenant/
The simple way is: for each shared table, add a column says SEGMENT_ID. Assigned proper SEGMENT_ID to each customer. Then create views for each customer base on the SEGMENT_ID, These views will keep data separated from each customers. With this method, information can be shared, make it simple for both operation & development (stored procedure can also be shared) simple.
Assuming you'd run one MySQL database on a single MySQL instance - there are several ways how to distinguish between what's belonging to whom.
Most obvious choice (for me at least) would be creating a composite primary key such as:
CREATE TABLE some_table (
id int unsigned not null auto_increment,
companyId int unsigned not null,
..
..
..,
primary key(id, company_id)
) engine = innodb;
and then distinguishing between companies by changing the companyId part of the primary key.
That way you can have all the data of all the companies in the same table / database and at application level you can control what company is tied to which companyId and determine which data to display for certain company.
If this wasn't what you were looking for - my apologies for misunderstanding your question.
Have you considered creating a different schema for each company?
You should try to define more precisely what you want to achieve, though.
If you want to make sure that an HW failure doesn't compromise data for more than one company, for example, you have to create different instances and run them on different nodes.
If you want to make sure that someone from company A cannot see data that belong to company B you can do that at the application level as per Matthew PK answer, for example
If you want to be sure that someone who manages to compromise the security and run arbitrary SQL against the DB you need something more robust than that, though.
If you want to be able to backup data independently so that you can safely backup Company C on mondays and Company A on sundays and be able to restore just company C then, again, a purely application-based solution won't help.
Given a specific DB User, you could give a user membership to group(s) indicating the companies whose data they are permitted to access.
I presume you're going to have a Companies table, so just create a one-to-many relationship between Companies and MySQLUsers or something similar.
Then, as a condition of all your queries, just match the CompanyID based on the UserID
in my file Generate_multiTanentMysql.php i do all steps with PHP script
https://github.com/ziedtuihri/SaaS_Application
A Solution Design Pattern :
Creating a database user for each tenant
Renaming every table to a different and unique name (e.g. using a prefix ‘someprefix_’)
Adding a text column called ‘id_tenant’ to every table to store the name of the tenant the row belongs to
Creating a trigger for each table to automatically store the current database username to the id_tenant column before inserting a new row
Creating a view for each table with the original table name with all the columns except id_tenant. The view will only return rows where (id_tenant = current_database_username)
Only grant permission to the views (not tables) to each tenant’s database user
Then, the only part of the application that needs to change is the database connection logic. When someone connects to the SaaS, the application would need to:
Connect to the database as that tenant-specific username
In relational databases, if we want to create a database for a football tournament for example, we consider the tournament as the mini-world (the unit for which we want to create a database and collect data). Therefore, we may create tables such as matches, teams, and so on. And, we don't create a table called tournament since we have only THE TOURNAMENT for which we are doing all this.
In practice, that's what I used to do. But, what if I want to save in my database some attributes about the tournament, such as its name, the date and the country in which it takes place... What can I do? Is it a good practice to create a table tournament that has only one record? And if yes, what about foreign keys? Is it good in this case to add the ID of the tournament as a foreign key in the tables matches, teams...? If not, what can be the best practice?
Why I want to store the tournament information in the database? Because I want to create a webpage that reads only dynamic data. I don't want to add those information (tournament name, date...) as static data on the web page.
I am also thinking about the benefit from the possibility of future evolution of the product. Later on, I may have more than one tournament and having the tournament table part of the database will allow a smooth integration of more tournaments without modification of the metadata.
Yes, it is typical to use a row to store relevant single values. (Frequently this is done for parameter settings). But you don't need an id in this row for the tournament or foreign keys to it in other tables until you have multiple tournaments.
Yes, this helps extend to multiple tournaments. It also helps in extending to a "temporal"/historical version of the database where we timestamp each row by when it held so that we can query about the state that was current at a given time. (This typically involves further normalization to have separate tables for columns that change together but possibly at different times from other column sets.)
In moving to multiple tournaments, as with any schema change, it is helpful to redefine the names of old tables as views of new tables. Unfortunately updates through views are typically poorly supported by SQL DBMSs so in that respect it can be useful to have a multiple-tournament-capable design right from the beginning.
I've been looking through different questions on here and I can't find something that exactly matches my situation.
I am designing a database for multiple types of users. I have one main User table which includes ID, Username, Password, PasswordSalt, AccountType (enum), and LastLoginDate. I need to have multiple types of accounts: Student, Parent, SchoolAdmin, SystemAdmin, Coordinator, and Teacher. I was originally thinking of having a separate table for each of these types of accounts, but I realized that SchoolAdmin, Coordinator, SystemAdmin, and Teacher all share the exact same data. These account types all have different permissions though. The Student and Parent accounts have extra information that they have to store.
I then thought about adding the information that the 4 identical tables share to the User table and then deleting those tables, but I came across another problem. I need to reference different types of accounts in other tables. For example, I had a foreign key for TeacherID in the Club table to show who the club sponsor is. If I add the information to the User table and get rid of those other tables, then how do I reference a specific account type in another table?
I have never designed a database like this so any help is appreciated.
There are three main ways of implementing inheritance on database models. Please check the links below, and study which is the best one to solve your problem. Nothing better to start analyzing this types of situations to become a good architect.
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Each of the different approaches have their pros and cons so choose wisely.
I am redesigning a database and I need some help.
I have two "User" tables, USER and APPLETCUST, with one being an internal user and the other being a customer.
Since I want them both to login to the same area, I think I need to create a new table that holds login information and whether or not the person is a USER or an APPLETCUST and then have a relationship to the respective USER or APPLETCUST to get that information.
What do you think? Is there a better way?
I'd recommend merging the table, but you already suggested it yourself :-) Creating a third table that references the two tables is also possible but might get messy unless you write the constraints properly.
I'm creating a social networking site with features similar to Facebook.
I want to start with schema design for my database.
What i thought was to create each table for each user who registers to our site.. am i doing right?
If a million users register to my site, a million tables will be created. how to go on about optimizing this? Please do suggest me techniques to overcome this and some references or books to learn about such concepts will be vry useful..
Thanks in Advance.
This is not the way you want to do it.
What you want to do is have a table (perhaps called 'users') that contains one row for each user that registers. Creating a new table for each user is completely pointless and would cause terrible performance.
Maybe something like this:
TABLE users
- username AS VARCHAR(255)
- password AS VARCHAR(255) (use a hashed password, of course)
- ...
Then when a user registers, simply insert the information they provide into the users table as a new row.
That would be massive overkill. You should probably read up on database design (start with normalisation, but don't overdo it). Then write down what you want to save for each user, and think about how to save it without saving data double.
But I'm pretty sure a table-per-user is not an option for this.
You must be confusing the meaning of the words database, table, field (or column), record (or row).
A database contains all your data for a specific project. There is always one database per project (or almost always)
A table contains all data of a specific entity and by saying entity, I mean an object type that is imaginable as real or seperatelly existing by itself. A person is an entity, a book is an entity, a phone is an entity, a movie is an entity, etc. Each of these would be seperate tables in a database.
A field (or column) is a data type that represents a specific characteristic (feature) of a table's entity. For example a table of users can have the fields: NAME, SURNAME, AGE, etc. These are all features that a user has.
A record (or row) is an actual item of one table. It is a single 'piece' of the table's entity. For example in a table of users, one record is one single user, namely {NAME:"John", SURNAME:"Smith", AGE:"32"}.
In your example, I can tell you for sure that you only need one database. You want to store information for many users, so you need one table called USER. You will need to store features to your users, like: name, surname, age, address, etc., then you will need to create the respective fields in this table: NAME, SURNAME, AGE, ADDRESS, etc. Then you will need to insert your data in the database as records. It will be one record per user you want to store.