I have a table [Team] in my Database. Many other tables require a many to many relationship with this table. This is mostly due to various records in my other table having authorisation settings based on which team the current user is in.
For example a record in my [User] table can be linked to many teams and a team can be linked to many [Ticket] records. If the teams overlap that user now has permission to view the [Ticket].
I am considering two options, firstly have a seperate table for each [UserTeam] and [TicketTeam] e.g ticket team will have the following columns Id,TicketId,TeamId.
My second option is to store the data for both in the same table. To do this I would create a [AuthorisationRecord] table with one Id column and a [AuthorisationRecordTeam] table with Id,AuthorisationId,TeamId. I would also then need an extra column on my [Ticket] and [User] tables AuthorisationRecordId. This has the downside of needing an extra column and every time we create a record we also have to create an [AuthorisationRecord] record.
If it was just these two tables I think it would make sense to have a seperate many to many table for each. However as there are many tables needing this same relationship with the [Team] table and the potential for many more in the future I am leaning toward my second option, as this will simplfy the devlopment process as every time we add a new feature that needs authorisation based on the Team we will not have to add another many to many table but simply add one extra column with a relationship to my [AuthorisationRecord] table.
My question is weather this is a good scaleable idea? It seems like it will greatly simplfy my database as instead of potentialy hundreds of many to many tables with my [Team] table there will be just one. However I can't find resources online about this potential method so I think it might be a bad idea.
Related
I have two tables users (whose primary key is user_id) and items (whose primary key is item_id).
One user_id (resp. item_id) can be associated with zero to many item_id (resp. user_id).
Under normal circumstances, I would model this many-to-many relationship with a joining table linking the two i.e. users_items (user_id, item_id).
In practice however, most user_id are associated with all items rows, and with millions of users and items the matching between every single pair results in billions of rows and rapidly becomes impractical (indexation, RAM usage, storage...).
For instance, 2 million users all having 1 million items would result in 2000 billion rows.
The less-than-ideal temporary solution I came up with is to add a boolean is_owned_by_all_users column in the items table, which seems to me like an inherently bad design (more complex queries, information split between two tables etc).
Is there a better strategy to implement this type of relationship?
While this is a general SQL question, I am also interested in engine-specific implementations that would solve this problem (if more suited to this particular scenario).
The solution I've seen posed to this is that you create a "security profile" table. Each record in the table represents a particular list of users.
then instead of a many to many bridge table, you have a many to one. Each item record (many) refers to one security profile record (which actually represents many)
The security profile record represents basically a particular combination of users.
There is of course overhead in maintaining, generating, and decoding this table but it stops you needing a bridge table.
If there are a lot of different combinations, it's also impractical.
If that is not practical then your original idea sounds fine to me, if that is a particular characteristic of your data, there's nothing wrong with modelling it that way.
Ok I am very new to creating databases with Entity in mind.
I have a Master table which is going to have:
departmentID
functionID
processID
procedureID
Each of those ID's need to point to a specific list of information. Which is name, description and owner of course they link back to each ID in the master table.
My question is, should I make 4 separate tables or create one table since the information is the same in all the tables except one.
The procedureID will actually need to have an extra field for documentID to point to a specific document.
Is it possible and a good idea to make one table and add some inheritance, or is it better to make 4 separate tables?
Splitting data into a number of related tables brings many advantages over one single table. Also by having data held in separate tables, it is simple to add records that are not yet needed but may be in the future. You can also create your corresponding objects for each table in your code. Also it would be more difficult to split the data into separate tables in the future if somehow you need to do that.
I have a table of People, and a table of Service Tickets. Service Tickets refer to 1+ People, and over time People are likely to be associated with multiple Tickets. What is the best way to represent this relationship in a SQL database?
It seems like my two options are to create 'enough' columns to contain all the person id's i should need, or a single huge string column that is processed CSV style after being fetched from the database. Both of these options have a maximum capacity, which seems like a bad design, and the second design means we can't join using the person id's.
A little background - I'm implementing a fairly small database as part of the backend for a class project. I've never really worked with SQL and what I know is self taught.
I feel like this is has to be a duplicate question, but I'm unable to find anything similar.
No, if this si a MANY to MANY relation ship, creat the table accordingly.
Create a table, something like
PeopleServiceLink:
PersonID,
ServieTicketID,
PRIMARY KEY (PersonID, ServieTicketID)
Have a read hear at Understanding SQL: Many to Many Relationships
For many-to-many relationship generally create three tables: Tickets(id, ...), People(id,...) and join table like TicketsPeopleJoin(ticketId, peopleId)
Create a separate tickets_people table which has person_id & ticket_id columns.
EDIT:
Would it be a good idea to just keep it all under 1 big table and have a flag that differentiates the different forms?
I have to build a site with 5 forms, maybe more. so far the fields for the forms are the following:
What would be the best approach to normalize this design?
I was thinking about splitting "Personal Details" into 3 different tables:
and then reference them from the others with an ID...
Would that make sense? It looks like I'll end up with lots of relationships...
Normalized data essentially means that the same data is not stored multiple times in multiple places. For example, instead of storing the customer contact info with an order, the customer ID is stored with the order and the customer's contact information is 'related' to the order. When the customer's phone number is updated, there is only one place the phone number needs to be updated (the customer table) and all the orders will have the correct information without being updated. Each piece of data exists in one, and only one, place. This is normalized data.
So, to answer your question: no, you will not make your database structure more normalized by breaking up a large table as you described.
The reason to break up a single table into multiple tables is usually to create a one to many relationship. For example, one person might have multiple e-mail addresses. Or multiple physical addresses. Another common reason for breaking up tables is to make systems modular, so that tables can be created that join to existing tables without modifying the existing tables.
Breaking one big table into multiple little tables, with a one to one relationship between them, doesn't make the data any more normalized, it just makes your queries more of a pain to write.* And you don't want to structure your database design around interfaces (forms) unless there is a good reason. There usually isn't.
*Although there are sometimes good reasons to break up big tables and create one to one relationships, normalization isn't one of them.
I am working on a project where there are several types of users (students and teachers). Currently to store the user's information, two tables are used. The users table stores the information that all users have in common. The teachers table stores information that only teachers have with a foreign key relating it to the users table.
users table
id
name
email
34 other fields
teachers table
id
user_id
subject
17 other fields
In the rest of the database, there are no references to teachers.id. All other tables who need to relate to a user use users.id. Since a user will only have one corresponding entry in the teachers table, should I just move the fields from the teachers table into the users table and leave them blank for users who aren't teachers?
e.g.
users
id
name
email
subject
51 other fields
Is this too many fields for one table? Will this impede performance?
I think this design is fine, assuming that most of the time you only need the user data, and that you know when you need to show the teacher-specific fields.
In addition, you get only teachers just by doing a JOIN, which might come in handy.
Tomorrow you might have another kind of user who is not a teacher, and you'll be glad of the separation.
Edited to add: yes, this is an inheritance pattern, but since he didn't say what language he was using I didn't want to muddy the waters...
In the rest of the database, there are no references to teachers.id. All other tables who need to relate to a user
use users.id.
I would expect relating to the teacher_id for classes/sections...
Since a user will only have one corresponding entry in the teachers table, should I just move the fields from the teachers table into the users table and leave them blank for users who aren't teachers?
Are you modelling a system for a high school, or post-secondary? Reason I ask is because in post-secondary, a user can be both a teacher and a student... in numerous subjects.
I would think it fine provided neither you or anyone else succumbs to the temptation to reuse 'empty' columns for other purposes.
By this I mean, there will in your new table be columns that are only populated for teachers. Someone may decide that there is another value they need to store for non-teachers, and use one of the teacher's columns to hold it, because after all it'll never be needed for this non-teacher, and that way we don't need to change the table, and pretty soon your code fills up with things testing row types to find what each column holds.
I've seen this done on several systems (for instance, when loaning a library book, if the loan is a long loan the due date holds the date the book is expected back. but if it's a short loan the due date holds the time it's expected back, and woe betide anyone who doesn't somehow know that).
It's not too many fields for one table (although without any details it does seem kind of suspicious). And worrying about performance at this stage is premature.
You're probably dealing with very few rows and a very small amount of data. You concerns should be 1) getting the job done 2) designing it correctly 3) performance, in that order.
It's really not that big of a deal (at this stage/scale).
I would not stuff all fields in one table. Student to teacher ratio is high, so for 100 teachers there may be 10000 students with NULLs in those 17 fields.
Usually, a model would look close to this:
I your case, there are no specific fields for students, so you can omit the Student table, so the model would look like this
Note that for inheritance modeling, the Teacher table has UserID, same as the User table; contrast that to your example which has an Id for the Teacher table and then a separate user_id.
it won't really hurt the performance, but the other programmers might hurt you if you won't redisign it :) (55 fielded tables ??)