C
C#14mo ago
sharp

❔ Storing data which is different per user type

Hi there! I'm working on a project where I have two types of users. Buyer and Suppler. When the buyer is making a purchase of some items, I'm having some statuses of the purchase which he can track. Since the status is and integer in the database, both of those users should see different value on UI based on that integer
+---+----------+----------+
| # | Buyer | Supplier |
+---+----------+----------+
| 1 | Status A | Status X |
| 2 | Status B | Status Y |
| 3 | Status C | Status Y |
| 4 | Status D | Status Z |
+---+----------+----------+
+---+----------+----------+
| # | Buyer | Supplier |
+---+----------+----------+
| 1 | Status A | Status X |
| 2 | Status B | Status Y |
| 3 | Status C | Status Y |
| 4 | Status D | Status Z |
+---+----------+----------+
My current table has only ID and Name, but should I add type and maybe a separate Resources table where I'm gonna localised the status or? The main reason I'm asking is because I need to be able to show the statuses on the list and order by them (Alphabetically). Currently they are being ordered by ID, which is not the correct way.
11 Replies
JakenVeina
JakenVeina14mo ago
you should have a core users table a table of buyer statuses a table of supplier statuses a table of buyers and a table of suppliers
sharp
sharp14mo ago
I usually distinguish them by UserType, 1 = Buyer, 2 = Supplier
JakenVeina
JakenVeina14mo ago
public class BuyerStatus
{
public required int Id { get; init; }
public required string Name { get; init; }
}

public class SupplierStatus
{
public required int Id { get; init; }
public required string Name { get; set; }
}

public class User
{
public required long Id { get; init; }
public required string Name { get; set; }
}

public class Buyer
: User
{
public required int StatusId { get; set; }
public BuyerStatus Status { get; set; }
= null!;
}

public class Supplier
: User
{
public required int StatusId { get; set; }
public SupplierStatus Status { get; set; }
= null!;
}
public class BuyerStatus
{
public required int Id { get; init; }
public required string Name { get; init; }
}

public class SupplierStatus
{
public required int Id { get; init; }
public required string Name { get; set; }
}

public class User
{
public required long Id { get; init; }
public required string Name { get; set; }
}

public class Buyer
: User
{
public required int StatusId { get; set; }
public BuyerStatus Status { get; set; }
= null!;
}

public class Supplier
: User
{
public required int StatusId { get; set; }
public SupplierStatus Status { get; set; }
= null!;
}
sharp
sharp14mo ago
What is this approach named, do you know any articles/blogs that I could check out? Or any github repo which implements it in similar matter?
JakenVeina
JakenVeina14mo ago
uhhhh you could call it "normalized" in general or you could call it "table-per-type" in the context of EF but what else is there to know? that's the table structure you want
sharp
sharp14mo ago
What do you think about storing it in "Resources" table, where all the other resources could live in? Yes the downfall is querying it by resource name...
JakenVeina
JakenVeina14mo ago
what is "Resources" table? what does that look like
sharp
sharp14mo ago
Something like this
+---+-----------------------+----------+----------+
| # | Name | Language | Value |
+---+-----------------------+----------+----------+
| 1 | user.supplier.statusx | en-GB | Status A |
| 2 | user.buyer.statusx | en-GB | Status X |
| 3 | | | |
+---+-----------------------+----------+----------+
+---+-----------------------+----------+----------+
| # | Name | Language | Value |
+---+-----------------------+----------+----------+
| 1 | user.supplier.statusx | en-GB | Status A |
| 2 | user.buyer.statusx | en-GB | Status X |
| 3 | | | |
+---+-----------------------+----------+----------+
Where the name would follow some sort table-related naming pattern
JakenVeina
JakenVeina14mo ago
I would say that is not well-normalized and that if you want a document store, you should use a document store
sharp
sharp14mo ago
Great, thanks for the input
Accord
Accord14mo ago
Was this issue resolved? If so, run /close - otherwise I will mark this as stale and this post will be archived until there is new activity.