My experience with databases is limited so I am not sure of the best way to ask this question, so I am going to break it down as simply as possible. I've built an ASP.net application with a mySQL database using NHibernate that has multiple users that can log in and all work on the same table (let's say of forum posts). So we have our users table and our food table.
Now I am looking for the best way to split these users into groups, very much like different companies. So The users from the same "company" can log on and see all there other company users and edit/create posts view-able by said "company".
I am looking for the most scalable (fastest with 1000's of companies) way to do this. Should I
1: Have a universal table for users and posts with a foreign key? So everything is stored on the same SQL table but their view of this table is restricted by the company ID. I see this being the easiest one to build, but will 1000's of companies accessing the same table with this be slow/problematic?
2: Create a new posts table for every company? So every user from a company accesses their own table of posts. To scale up would this be more efficient/faster if there were thousands of companies?
A quick explanation of the best method would be really appreciated. But also pointing me to documentation/resources would be amazing! Cheers.
I strongly suggest option 1.
You should create company table with companyID as primary key. Use companyID as foreign key in users table and food table.
This is regular approach and works well in most of the cases.
It would be very complicated to maintain 1000's of tables in the application.
Users and food table will be already indexed by company ID so the filtering will be very fast.
Related
I showed my lecturer my database today (based on an Ecommerce site).
He was very quick to point out a few issues, such as data redundancy. For example I have User ID in five tables.
My database is based on my ERD: http://imgur.com/X02JlF3
I am just looking on some advice on cleaning up my ERD so that I can produce a more efficient database.
If I removed User ID from every table except Users, how could I provide a User ID with a transaction report for example? Or would User ID need to be a foreign key in every table?
Thanks, sorry if this is an inappropriate question! Just not sure the right way to clean up this ERD.
After a quick look, I think that the use of UserID as a foreign key is OK. The redunancy I see is more like Prodcut Name, product Description, Price and stock level occuring in the Wish List, for example. These values should only be in the Product table and the ProductID in Wish List used to join to that table as a FK. With that in mind, I'm sure you will see other examples in your ERD.
I am designing a database for student information. I wish to implement the best practices regarding separate tables and use of Primary and Foreign Keys.
Let's say I have the following tables (High Level):
Users
Student Information
Student Transcripts
Student Records
There will be different users with different levels. Also, the information in Student Info/Transcripts/Records will all have a Foreign Key with the ID that's in Users.
SO, it would be dumb to just clump all the tables into one big table, wouldn't it? Is it a good idea to keep all this information separate and just use Primary/Foreign keys to link things together, as well as maybe Joins? I just personally think a big table would be quite messy and through this way, it allows one to keep similar data together with its own kind.
Thanks for all input on the matter!
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
The following screenshot is ERD for one application or one business. If you have used QuickBooks youll know that it has starting form called company so in one application we can create many companies and maintain company accounts
if I add a column companyid to all table then I can add many companies in one application
what is the good practice:
Adding company key and exacting company info with company key
Creating database for each company if thrs 100 companies 100 mysql databases
please advice !
Creating a separate database per company is almost assuredly not what you want to do (unless you have a really good reason to need to do so). Adding a company_id to your tables and ensuring that columns you query against are indexed with company_id along with whatever other column you will typically be querying would be wise.
You'll also need to ensure that your application is designed to correctly inadvertent (or purposeful) access from one company to another company's data.
EDIT - Now that I see your ERD has been added: I would add a "company" table containing a company_id, name, and whatever other data you like, then ensure your other tables have an additional company_id field as well.
Since you want to maintain all companies' businesses and accounts within the same application, then there is no need to create a database for each company, just add a Companies table, then add a foreign key company_id to the other database tables
I've been programming and using a survey software for more than three years. It began as a simple survey system, with a basic 'users' SQL table, as you can find, for instance, in most CMS's. I initially planned to use the program two or three times, with 30 users or so for each survey.
Today, the program has grown and is used for one or two surveys every month. A survey may have hundreds of users, which makes the table awfully long and confusing.
I can't find a best way than a classic user list, though. I though of creating a new table for each survey, but I feel it's asking for problems. What I do now is to archive the complete SQL database when a survey is finished, which is convenient enough for now but will turn into a nightmare when I'll have to quickly find the results of an old survey.
I'm confident I'm not the first one to encounter this problem and would be happy to know how you solved it. Are there some kind of best practices for it?
Thanks!
One solution is to maintain two tables. Users and Users_History.
Once a survey is complete, you can move the data to users_history. That way, DB that affects app performance would stay within a manageable size. For analysis purpose, data would always be available in history table.
If the set of users for each survey is distinct (the same person in two surveys would have two different user accounts), you could add a column to users referencing the surveys table.
ALTER TABLE users ADD COLUMN survey INT NOT NULL;
ALTER TABLE users ADD FOREIGN KEY (survey)
REFERENCES surveys (id)
ON DELETE CASCADE;
If you want to allow users that aren't associated with a survey, allow the survey reference to be NULL and set the foreign key to ON DELETE SET NULL.
When it comes time for you to operate on the users table, use the column to get only the users that are a part of the survey of interest.