Lets say I have a table EmailQueue that is used to build out emails to send to users, using several non related processes. The Emails can contain a ever growing number of different 'content items' but for now lets just say we have News, Events, and Offers. Each of these 'content items' are already populated in their own respective tables and will be selectively added to a users email.
Now I have a design decision to make.
1
I could keep with a normalized pattern and create a mapping table for each of the 'content items' that an email can contain.
|EmailId|NewsId| , |EmailId|OfferId| , ...
The main issue I see with this design is that there is a good bit of overhead every time a new 'content type' is integrated to the email system; Both in database and object mapping.
OR
2
I could create 1 mapping table that has a Type reference.
|EmailId|ContentID|ContentType|
Of course the big issue here is that there is no referential integrity. I feel object mapping would be much easier to handle and adding a new object only requires adding a new ContentType row (and of course the required object mapping code).
Is one of these solutions better than the other? Or is there a solution better than both of these that I am unaware of?
I'm leaning towards using method 2, mainly because this project needs to be rapidly developed, but worried I may regret that decision down the road.
Note: We are using subsonic as our data access ORM, which does a decent(not perfect) job of handling object graphs through keyed relations. I will still likely need to map the active record 'content' objects to domain object though.
Related
I've been trying to get my head around NoSQL, and I do see the benefits to embedding data in documents.
What I can't understand, and hope someone can clear up, is how to store data if it must be relational.
For example.
I have many users. They are all buying a product. So everytime that they buy a product, we add it under the users document in mongo, so its embedded and its all great.
The problem I have is when something in reference to that product changes.
Lets say user A buys a car called "Porsche". Then, we add a reference to that under the users profile. However, in a strange turn of events Porsche gets purchased by Ferrari.
What do you do now, update each and every record and change to name from Porsche to Ferrari?
Typically in SQL, we would create 3 tables. One for users, one for Cars (description, model etc) & one for mapping users to purchases.
Do you do the same thing for Mongo? It seems like if you go down this route, you are trying to make Mongo do things SQL way, which is not what its intended for.
I can understand how certain data is great for embedding (addresses, contact details, comments, etc) but what happens when you need to reference data that can and needs to change at a regular basis?
I hope this question is clear
DBRefs/Manual References were made specifically to solve this issue. Instead of manually adding the data to each document and then needing to update when something changes, you can store a reference to another collection. Here is the mongoDB documentation for details.
References in Mongo
Then all you would need to do is update the reference collection and the change would be reflected in all downstream locations.
When i used the mongoose library for node js it actually creates 3 tables similar to how you might do it in SQL, you can use object id's as foreign keys and enrich them either on the client side or on the backend, still no joining but you could do an 'in' query for the ID's then enrich the objects that way, mongoose can do this automatically by 'populating'
I am not able to figure out that how should I store system related information in Moqui.
For example, if I am using the HiveMind application for a particular organization (ABC Corp), I have to hard code the value while making records for the particular organization. I could not find any suitable entity that will allow me to handle this particular case.
So is there any method by which I can handle this particular case?
For example, when I am creating users and clients in the HiveMind application, there is no record in the database that will specify that the Users are employees of a particular organization.
For clients they are just stored in the Organization entity and no relationship exists that will specify that. I can handle that case by creating a party relationship whenever a new user or client is created.
But I will have to hard code the value of the Party with which I want to create the relationship. Suppose ABC corp is using the HiveMind application, I would have to hard code ABC corp's party Id whenever I create a new user or client. Rather that hard coding this value, it would be more efficient for me to fetch this particular value from the database. Whenever a new Organization wants to use the application, I will just change it in the database and the service code will remain as it is.
This is really an application design question and not an aspect of the framework, but I'll share some thoughts on it.
Business level configuration should generally be done in the database in structures (entities) that are designed for the purpose. Sometimes it general values are needed, but this should be the exception and only rare cases. In Moqui the way to handle user or user group preferences is to use the UserPreference and UserGroupPreference, and for all users use the ALL_USERS group that is standard in Moqui (all users are automatically part of this group). This can be done directly on the entities or using the relevant methods on the UserFacade (ec.user).
That said, from a business and application design perspective for apps based on Mantle (for others reading in, this is the business artifacts project based on Moqui) I wouldn't recommend doing it this way. If you want to support multiple organizations when creating an employee you should have a field on the form to select which organization the employee is part of (and then create the PartyRelationship record as you implied).
In HiveMind there can be multiple vendor organizations with people in different roles associated with them. When creating a project you select the vendor and client organizations for the particular project so we know who to bill from and to, which users are involved with different aspects of the project, etc.
If you do want to support just one vendor organization you may as well hard-code it and not make it visible or selectable anywhere in the application, and make it part of the "seed" data of the app in the more strict sense of the term seed data as data that code depends on directly (i.e. uses "hard-coded", though that term has negative implications that are often unjustified, directly use string values are often quite useful and improve clarity and maintainability).
We are creating a system that allows users to create and modify bills for their clients. The modifications need to be maintained as part of the bill for auditing purposes. It is to some extent a point in time architecture but we aren't tracking by time just by revision. This is a ASP.NET MVC 5, WebAPI2, EntityFramework 6, SQL Server app using Breeze on the client and the server.
I'm trying to figure how to get back the Breeze and our data model to work correctly. When we modify an entity we essentially keep the old row, make a copy of it with the modifications and update some entity state fields w/ date/time/revision number and so on. We can always get the most recent version of the entity based off of an entity ID and an EditState field where "1" is the most current.
I made a small sample app to work on getting Breeze working as part of the solution and to enable some nice SPA architecture and inline editing on the client and it all works... except that since our entity framework code automatically creates a new entity that contains the modifications, the SaveChanges response contains the original entity but not the new "updated" entity. Reloading the data on the client works but it would of course be dumb to do that outside of just hacking around for demo purposes.
So I made a new ContextProvider and inherited from EFContextProvider, overrode the AfterSaveEntities method and then things got a bit more complicated. Not all the entities have this "point in time" / revision functionality but most of them do. If they do I can as I said above get the latest version of that entity using its EntityId and EditState but I'm not seeing a straight forward way to get the new entity (pretty new to EF and very new to Breeze) so I'm hoping to find some pointers here.
Would this solution lie in Breeze or our DataContext? I could just do some reflection, get the type, query the updated entity and shove that into the saveMap. It seems like that might break down at some point (not sure how or when but seems sketchy). Is our architecture bad? Should we have gone the route of creating audit/log tables to store the modified values instead of keeping the datamodel somewhat smaller by keeping all of the revisions of the entities in their original tables but with the revision information and making the queries slightly more complicated? Am I just missing something in EF?
... and to head of the obvious response, I know we should have used a document database but that wasn't an option on this project. We are stuck in relational land.
I haven't tried this but another approach would be to simply change the EntityState of the incoming entity in the BeforeSaveEntities method from Modified to Added. You will probably need to also update some version field in this 'new' entity so that it doesn't have a primary key conflict with the original.
But... having built apps like this in the past, I really recommend another approach. Store your 'historical' entities of each type in a separate table. It can be exactly the same shape as the 'current' table. When you save you first copy the 'current' entity into the 'historical' table ( again with some version numbering or date schema for the primary key) and then just update your 'current' entity normally.
This might not give you the answer you expected, but here is an idea:
When saving an object, intercept save on server, you get an instance of object you need to modify, read object from database that has the same ID, put copy of that old object to legacy table in your database and continue with saving into main table. That way only latest revision stays in main table while legacy table would contain all previous versions.
So, all you would need to do is have two tables containing same objects:
public DbSet<MyClass> OriginalMyClasses{get;set;}
public DbSet<MyClass> LegacyMyClasses{get;set;}
override SaveChanges function and intercept when entry E state is Modified, read E type, get the original and legacy tables, read object O from Original with same ID as E, save O to Legacy table, and finally return base.SaveChanges(); (let it save as it is supposed to by default).
My company is about to start a new project using Telerik's OpenAccess ORM. This is a new product to us, and the first time we'll be using an ORM for a project instead of a Dataset based approach. We are currently having some disagreement regarding the best way to structure our data layer. Specifically, should we have a single .rlinq file and domain model for the project, or should we have per screen/module .rlinq files that contain only the tables, and the columns from the tables, required for that particular screen/module. To illustrate the latter:
Say we have a Person table, with fields for first name, last name, ssn, birthdate, gender and marital status. In the personal information screen, we need all of these fields, so we include the whole table in the domain model in that .rlinq file. On another screen (with a separate .rlinq file), we only need the person's last name and ssn, so the Person object in that .rlinq file contains only last name and ssn.
The argument for this method has been primarily that we should only select the data that we need for a particular screen, and no more. In our current Dataset based applications, this makes sense. There has also been concern expressed that having unnecessary tables and relationships will cause unneeded data to be loaded even if it is not asked for and lead to network load. The argument against this has been that we're fragmenting the domain model and introducing unnecessary complexity, and that part of the job of the ORM is to manage data fetching with caching and lazy loading. We can't come to an agreement on this, and can't find any conclusive information one way or another, so we're turning to the StackOverflow community for help!
If it matters, we're building a Windows Forms based intranet app, and the data layer will be sitting behind WCF services, and the database will have around 100 tables.
Thank you in advance for your help!
In general it is best to have a solid domain model built up in a single RLINQ file. You can then handle screen concerns by projecting queries into ScreenModels/DTOs as needed.
For Example
Say you have a person object with multiple properties, however, on a particular screen you only want to return first name & last name.
var myUserDto = context.People
.First()
.Select( p => new UserDto { FirstName= p.FirstName,
LastName=p.LastName });
OpenAccess is smart enough to only query for the first/last name in this case. Now when the screen ends up requiring another property available in the person object, you only need to update the dto and LINQ query.
Also, if you plan to use the Data Service Wizard OpenAccess provides, it creates a service per OpenAccessContext. So if you have an RLINQ per entity you will have a service per entity, which would be painful to maintain on the client to say the least. If you hand roll the service layer, you would obviously have a little more control here, but you will still need to constantly remember which OpenAccessContext handles each domain object.
FYI, For a large model it may be helpful to look into the aggregate metadata source OpenAccess provides to help break up large models into manageable pieces.
Hope this helps! :)
I am working on a design where I can have flexible attributes for users and I am confused how to continue the design of the schema.
I made a table where I kept system needed information:
Table name: users
id
username
password
Now, I wish to create a profile table and have one to one relation where all the other attributes in profile table such as email, first name, last name, etc. My question is: is there a way to add a third table in which profiles will be flexible? In other words, if my clients need to create a new attribute he/she won't need any customization to the code.
You're looking for a normalized table. That is a table that has user_id, key, value columns which produce a 1:N relationship between User & this new table. Look into http://en.wikipedia.org/wiki/Database_normalization for a little more information. Performance isn't amazing with normalized tables and it can take some interesting planning for optimization of your code but it's a very standard practice.
Keep the fixed parts of the profile in a standard table to make it easy to query, add constraints, etc.
For the configurable parts it sounds like you are looking for an entity-attribute-value model. The extra configurability comes at a high cost though: everything will have to be stored as strings and you will have to do any data validation in the application, not in the database.
How will these attributes be used? Are they simply a bag of data or would the user expect that the system would do something with these values? Are there ever going to be any reports against them?
If the system must do something with these attributes then you should make them columns since code will have to be written anyway that does something special with the values. However, if the customers just want them to store data then an EAV might be the ticket.
If you are going to implement an EAV, I would suggest adding a DataType column to your attributes table. This enables you to do some rudimentary validation on the entered data and dynamically change the control used for entry.
If you are going to use an EAV, then the one rule you must follow is to never write any code where you specify a particular attribute. If these custom attributes are nothing more than a wad of data, then an EAV for this one portion of your system will work. You could even consider creating an XML column to store these attributes. SQL Server actually has an XML data type but all databases have some form of large text data type that will also work. On reports, the data would only ever be spit out. You would never place specific values in specific places on reports nor would you ever do any kind of numerical operation against the data.
The price of an EAV is vigilence and discipline. You have to have discipline amongst yourself and the other developers and especially report writers to never filter on a specific attribute no matter how much pressure you get from management. The moment a client wants to filter or do operations on a specific attribute, it must become a first class attribute as a column. If you feel that this kind of discipline cannot be maintained, then I would simply create columns for each attribute which would mean an adjustment to code but it will create less of mess down the road.