I'm trying to build an Inventory web application with .NET Core. In this app, I want to keep track of every create and update operation, so almost every model in my application has CreatedBy and ModifiedBy fields and each of those fields have a one-to-many relationship with the UserId field from the Users model.
So there are a lot of foreign keys in my models and lots of navigational properties in my Users model. It works but looks kind of messy especially in my Users model so it got me thinking maybe there is something wrong with my approach. I thought of some other ways but I am just learning the ropes so I can't really predict the possible downsides of those approaches, thus, I need help.
So what's the best way to deal with this kind of situation in a web application?
Should I keep defining foreign keys?
Should I store UserId as string in those columns?
Should I create another table which holds records for every create / update operation?
Is there a better way out there?
After some research I decided to go on with temporal tables solution from SQL Server directly. You have to add just a couple of codes to your dbcontext's onmodelcreating method to set it up and it looks like it's working very good for my needs.
Related
I'm using Identity 3 and I want to add some columns in AspNetUser table.
I've tried to do it using EF Core Code first and it's working well but I need to do it DB first.
I was wondering, if I will create the columns manually in database, then create the ApplicationUser class with corresponding properties, will it work?
Yup that should work, I've done it before.
However as time goes on I ended up having to add so many that it got messy.
So eventually I refactored those extra columns into their own related tables:
e.g: User_AdditionalDetails
This was a massive pain as I had live users and had to write scripts to migrate everyone's data etc.
This way you would only need to add a single FK for the related table with all this extra info.
It also neatens the code too, and gives the benefit of being able to load different sets of user properties only when they are needed.
If it's for an application scope property of the user like 'Region' which determines behaviour of core functionality of your app, then I'd say add it straight onto the main ApplicationUser class.
My entire group is new to ASP.Net Core and I was the lucky one tasked with Authentication/Authorization. We have always used a DB first approach, and this is no different, we already have our DB all set up. The higher ups want to use our specific tables for all things Identity, but they also want to leverage the tools that ASP.Net Core gives.
This will be a multi-site app where there is one central database. Our current setup is close to what the scaffolding adds, but has some small differences.
I have read a ton of resources, but the vast majority all focus on the code first approach and I currently don't fully understand what I need and what is there for the code first approach. I have seen a couple of answers that recommend using the .ToTable and .Property inside of OnModelCreate. Is this the best option or am I better off creating my own stores and methods? I currently have a user model created and a store to go with it (based on this site). Is it best for me to try to expand that all the way out (don't full understand how to have it pull in roles and claims).
This is what our DB Schema currently looks like.
At this point we are creating our Roles and Claims via a db script. The only thing we will be using UI's for right now is a page that will let a site admin add users, and assign them roles, and any singular claims they need.
Any help or input would be greatly appreciated as I try to wrap my head around all of this. If I have left out any pertinent information please let me know. As I said with what I have now I can create a user and login, I just have no idea where to go from here (how to add roles and claims).
Here's how I think about it and the steps I would take to approach in solving this problem.
So Microsoft's implementation of Identity is an abstraction of the problem.
The Models that they provide and the Tables that are derived from them is their choice for the default implementation of the abstraction.
So essentially what you want to do is to plug in your models in to this abstraction.
To quickly generate these models from your database you might want to use scaffolding this will generate the DbContext and the Models, you will then have to configure the dbcontext to plug in your design.
And if you look at how you can create your own Identity Tables providing your own objects
here this can give you an idea of how to plug in your models/functions in to this abstraction.
You will most likely have to override the OnModelCreating method to configure the relationship of your tables.
I know that each time a user registers in my ASP.NET MVC application the ApplicationUser class is used to create the new record and put it in the database.
I was wondering if it's okay to add properties to that class for example I want the model to have a column in the database for DateOfBirth. Then use that class(model) directly in my application when I have to do some business logic things, database queries and similar stuff. Or is it more correct to create a new table in the database called let's say ApplicationAccounts, that saves the general info about the account. Each ApplicationAccount will be associated with a ApplicationUser(1 to 1 relation) and be somewhat of a buffer in the communication with the real accounts. Does that make sense?
I would go with the second option : create your own table, link them up in a one to one relationship using the UserID as a unique foreign key and then go from there.
One note here, it is perfectly normal for the model you need for the views to be different from the database model, this is because your db model can hold a lot of data that your view doesn't actually need. You might want to consider having separate models and use something like Automapper for a quick translation from one to another.
For instance, i have these entities
Client : table
TransactionA : table
TransactionB : table
..
TransactionZ : table
TransactionA to TransactionZ table is referenced to Client
in database structure, i've been thinking of creating new table TransactionA for every new Client registered and has a schema with the Client.Code so it looks like clientA.tbl_TransactionA.
with this structure, i think my database would generate thousands of table depending on how many clients will register which i think that it is hard in maintenance if there's a modification in core.
I would like to ask for your opinion on the best approach on this matter, advantage and disadvantage.
PS:
I am using Entity Framework (code first), MSSQL
Thanks in advance.
Creating a table per client would not be a good idea on many levels. To pick one of the more obvious ones, using Entity Framework you would have to alter and recompile your code each time you wanted to add a client. You'd probably have to use reflection or to figure out which client DbSet to reference when seeking a transaction.
It isn't clear what has driven you to this design consideration, but it would seem obvious that the more reasonable model would be to have a Transactions table that had a foreign key / navigation property to the Client table. I assume there's some good but unstated reason why this would not suffice, though.
I am creating a ASP.NET MVC website where people can save their bookmarks. There is no limit on the number of bookmarks each user can store so the database tables may grow quite large.
Many to many relationship:
A bookmark can have many tags
A tag can have many bookmarks
My tables use identity to generate ids in a MSSQL database. When I insert a bookmark with NHibernate this results in multiple requests to the database. Up to 10 requests. I know there are alternatives to generate ids like HiLo, but I am not sure if I really need it.
This article suggests using HiLo in case of a greenfield application:
http://nhibernate.info/blog/2009/03/19/nhibernate-poid-generators-revealed.html
Questions:
Should I use HiLo in my situation?
Are there any disadvantages of using HiLo?
In what situations are these multiple requests to the database going to hurt performance?
HiLo makes sense in scenarios where you have to batch insert lots of records constantly.
It is just easier for the client (NHibernate) to create the IDs on the client instead of
having to query the database after each insert to get the new identifiers (which is more or less the case with auto increment Ids).
This should lead (also in your case) to better performance and less potential errors.
The downside is that you need another table to store the HiLo values and that other applications accessing the database all must know about that and need to implement the exact same logic. As long as your application is the only one accessing the database, this is not an issue.
In MSSQL2012 we now also have Sequences. This can be used instead of HiLo, the handling of IDs is more or less the same, you just have to create a sequence for each an every table...