What is the difference between Has One and Belongs To in GORM?
Where is each used?
Thanks.
I read the documentation, but I did not understand the difference and their uses.
Both of them are used to create one-to-one connection with another model, the differences between them I think it's self-explanatory as its documentation said.
Belongs To
type User struct {
gorm.Model
Name string
CompanyID int
Company Company
}
type Company struct {
ID int
Name string
}
Like the example above, the user can only work in one company, there is no chance user can do other work in multiple companies since the user only belongs to one company.
Has One
type User struct {
gorm.Model
CreditCard CreditCard
}
type CreditCard struct {
gorm.Model
Number string
UserID uint
}
Otherwise, the has one relationship guarantee that each model can only have one another model. In the example above the user can only have one credit card and the credit card can only belong to exactly one user as its owner.
And when to use one over another depends on the entity and the main business of your application. Thanks, hope that help.
Related
I have two models, using Go 1.19:
type User struct {
Name string
ID int
}
type Order struct {
ID int
Name string
User *User
// or
UserID int
}
Of course, the database orders table has a foreign key to the users table via user_id.
Probably in different situations I have to use one of these models. When exactly?
Mb only user_id in DTO models, the user in responses from the server?
I will be glad for any information :)
It depends on your purpose. As usual, you have to use id when a table to include has meta info about your entity (often it's tables with a lot of rows and so heavy), therefore it will be better to use id, otherwise if it's table which describe some fields in initial table, you can use full entity.
How to create a Facebook database on small scale.
about the project:
User can signup and create a account (info is store in UserTB table)
User can edit there profile & address informaion (info is store in ProfileTB & addressTB tables)
User can add their family member information. But Family member is Not a user of this application.
Family Member can become a member of application but doesnt has to be
Issue: How can user add their family member information (sister/brother/dad)? User's family will also have first_name, address etc.. so maybe doesnt make sense to re-creating FamilyProfile or FamilyAddress Tables. Main issue is user can add their many Family Member but family member doesnt has to be a user of this application.
UserTB = track user login information
ProfileTB = Track user profile information
AddressTB = track user address information
FamilyTB = user have multi family member linked to user table (Relationship is string, ex brother, sister, dad etc..).
I solove this issue by adding Linked_ID in each tables. but it has its own issues, for example. i could have 50 tables... and when family member becomes a user... than I will have to update user_ID in 50 different tables...
Table and test data
click here to see ERD Image
The AddressTB is unnecessary and must be merged with the ProfileTB. I know why you seperated Street into a different table (Normalization) but streets are just way too many and they can sometimes have multiple names (In some countries atleast), people can also have typos when entering their Street name and it's not worth it!
On the other hand you need the FamilyTB (I would rename this table to RelationTB for more clearance).The actual information for users are stored in ProfileTB and only their relations are stored in FamilyTB. (Read more here)
Also, Family_ID cannot be a primary key on its own! Because primary keys must be Unique; However, a user can have multiple brothers and that violates this rule. Change it the following so it's always unique:
Table = FamilyTB
Field = Family_ID (PK)
Field = User_ID (PK)
Field = Relationship
I'm sorry if this is the wrong place for this question. I volunteer for a charity group that has to store sensitive data, as we are a new type of format, there are no systems that fit within our needs or our budget. Someone else started building the database, I wasn't sure he was resolving the relationships correctly, so I presented him with an alternate ER model and now we haven't heard back from him, so I am left to build it by myself.
As we have to store sensitive data, I'm reluctant to put my database design on here in it's entirety, so if there is a way I can privately discuss this with someone, that would be my preference, as I would love to get someone else to check it in full to make sure it's ALL good... but for now, can someone confirm if I have resolved the relationships correctly, or if the original design was better?
The database description is: There are different types of members -
Client, Staff, Professional (Offsite), Supplier, Family, General. There are different types of Staff members: Managers, Volunteer, Professional (Onsite), Admin, Committee, Lecturer. A member can be one or many types eg: Client/Volunteer/Family, Supplier/Volunteer, Manager/Lecturer/Volunteer/Committee/Family.
The original guy resolved this by creating a separate table for each user, each table storing a name and address eg:
Client - ClientName, ClientAddress
Professional - ProfessionalName, ProfessionalAddress
Employee - EmployeeName, EmployeeAddress
Family - FamilyName, FamilyAddress
My only problem with this is that I would ideally like one person to have one MemberID with their name and address, but with the original design each person would have a different ID for each type of person that they were, all storing name, address, phone number, email etc.
I thought that creating a Member table and having a Member Type table with a joining Member Type List table would be a better design. This is how I have resolved the issue:
Member Tables
Have I done this correctly or should I continue with the original design?
Thanks
Update:
Staff Model
It makes sense to store all member related data within one table.
Also for programming, I cannot imagine any use case that would support having different tables for each member type.
That being said, I advise you to look up the concept of "user roles", since this seems very similar.
You have different users (members) and they can have different roles (member type). Based on your roles you might want to show different data / allow different actions / send specific mails (or whatever else you can imagine).
So generally your approach looks good. The only thing I think about is that right now you don't have stored who is a "Staff" member for example. If you just have one list with different names you don't store the structure.
Depending on your use cases you can e.g. make another column in MemberType table "isStaff". Or, if you need to be more flexible and there are likely more different member types in the future, you can make another table (e.g.) MemberTypeParent and set a foreign key on your MemberType table to that table to make the connection.
It all depends on what you want to do with the data in the future.
I have three tables: user, friend and family.
User is entity.
Friend is relationship.
Family is relationship.
However, if I would like to set privacy level which can control who can view my full information. i.e. Only friend can see my hobbies, and only family can see my current location.
I don't know how I can implement this on ER design.
Option 1:
User{
attribute 1: ID;
[other attributes]
}
Friend{
Attribute 1: FriendID;
}
Family{
Attribute 1: family ID;
}
How can I meet the requirements? Still confused about it. Anyone has a rational solution ?
ER diagrams are really a seperate issue from security. ER diagrams just state what exists and how it is realated.
The best place for this kind of secuiry is in the model. When you someone asks for your current location, check if they are your family, etc...
This is especially true since current location is likely to be calculated from GPS, not stored as an entity in the database. If it is, you could potentially include a forign key from current location to familyID that would tie these together.
If this doesn't make sense, please provide more details on hobbies and current location.
Just a homework question I am trying to figure out, I would appreciate some assistance.
Apparently, there are three problems with the design of this database design:
Account = {AccNumber, Type, Balance}
Customer = {CustID, FirstName, LastName, Address, AccNumber}
The one that is pretty obvious is that 'CustID' is useless if 'AccNumber' exists.
I am not quite sure about the second and third problem.
Is there a problem with a separate attribute for 'FirstName' and "LastName', cant we just use 'Name'?
And another option, if 'AccNumber' is the primary key (assuming CustID will be removed), it probably should be place in the beginning :
Such as:
Customer = {AccNumber, Name, Address}
Any input would be appreciated!
Thanks
The customer-account relationship, at first glance, appears to be a many-many relationship, which necessitates the use of an intermediary relationship table. For instance, I have three accounts of my own at my bank. In addition, my wife has two of her own. Finally, we have a shared account. The schema above could not well handle such relationships.
You could, indeed, just use "Name" - but you may need to know what the first or last names are at some point in the future and such a concatination can be quite problematic to split.
Good luck with your homework...
The problem is that you haven't presented us with what the database should represent in words; as it is now, there's nothing "wrong" with the design, since we don't know what the design is supposed to model.
I certainly wouldn't say that CustID is useless, as it serves as the primary key of the table. What you need to determine is the relationship between customers and accounts. It should be one of the following:
A single customer can be tied to multiple accounts, but a single account can be tied to a single customer
A single customer can be tied to only one account, but an account can be tied to multiple customers.
A single customer can be tied to multiple accounts, and a single account can be tied to multiple customers
Right now, with AccNumber in the Customer table, your design models #2.
How is is designed right now, each customer could only have one bank account.
The many-to-many relationship will be a problem. Instead, you might create a third table that holds the relationships. For example:
Account = {AccNumber, Type, Balance}
Connection = {ConnID, AccNumber, CustID}
Customer = {CustID, FirstName, LastName, Address}
This way, both Account and Customer are parented by Connection (for lack of a better name). You could query all connections with a certain AccNumber and find all the customers using that account, and vice versa.