Reputation: 471
I'm playing around with DynamoDB for the first time ever, and it's my first time using an ORM. I'm trying to follow good practices around keeping Model seperate from controller. The project i'm using is a ASP.NET Web API for Lambda
I've written up my basic model and it looks like below
I have a User class
[DynamoDBTable("Users")]
public class User
{
[DynamoDBHashKey]
public string username { get; set; }
public string firstname { get; set; }
public string surname { get; set; }
and i have a Accounts class
[DynamoDBTable("Account")]
public class Account
{
[DynamoDBHashKey]
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
[DynamoDBLocalSecondaryIndexRangeKey]
public User User { get; set; }
My Account is associated with a user. Now i understand that as far as the database goes i want to store just the ID (username) of the user. But as far as in my Model. should i be storing the User object or just the Username? if i should store the User object, how do i save just the Key from the User object instead of the whole object.
On top of that if i am storing as a whole object. i wouldn't expect the client to post in the whole object, they would just post in the username. would the below code in the controller make sense? (note: DBContext is my database wrapper)
public void Post(Account NewAccount, String username)
{
User user = DBContext.GetItem<User>(username);
NewAccount.User = user
DBContext.StoreAsync(NewAccount);
}
Note: this code is not currently working due to the User object in Accounts.
Upvotes: 1
Views: 727
Reputation: 2452
To preface my answer I want to defer to this highly ranked answer to remind you that: "All the answers for how to store many-to-many associations in the "NoSQL way" reduce to the same thing: storing data redundantly."
DynamoDB is a nosql database service so this statement applies. With this in mind, remember that there are going to be many ways to approach the solution to your questions. When you design your model: "In NoSQL, you don't design your database based on the relationships between data entities. You design your database based on the queries you will run against it." Your model will not be an "ORM" necessarily because you are not representing relationships between data. Rather, the type of query you need to run should be the driving decision factor on how your represent the data.
Should I be storing the User object or just the Username?
This depends on the information you need from the user object in the query you are running. If your query needs all user information then you should store the full user object. If the query only needs to know if the user exists, then a username will be fine.
If I should store the User object, how do i save just the Key from the User object instead of the whole object?
This question is a little conflicting because you want to store the User object, but then only want to save the key. It seems you have an example of saving only the username below, and I further discuss this idea in the next part of the question.
I wouldn't expect the client to post in the whole object, they would just post in the username. would the below code in the controller make sense?
Yes - If the account query only needs a username to represent the user object. If your account query needs other attributes to represent the user object, you will need to decide how you will include these attributes. If you save multiple user attributes to the account model, you will have to keep in mind "In a denormalized database or in NoSQL, it becomes your responsibility to write application code to prevent anomalies (redundant data that is out of sync)."
Again I would highly recommend reading How do you track record relations in NoSQL? for more information on relationship records in a NoSQL environment. The principles are the same regardless of which NoSQL database you are using (dynamodb,couchdb,cassandra, etc..) and which coding language you are using to interact with the database.
Upvotes: 1