I have three entities that need to be linked. In my scenario, I have three tables users, stores and accounts.
Both users and stores can have zero or one account and each account should be either for a store or a user (see image below).
I need a one-to-one relationship between user-account and store-account. Since one-to-one relationship force the model to use one key, the user and store Ids might have conflict.
Is there any solution for this in Entity Framework or do I have a flaw in my design?
It would be much easier to use intermediate tables user_account and store_account, that would store only keys. This way you can enforce any logic you want.
Related
Links are generally the intersection of combinations/associations of hash surrogate keys generated from respective business keys in the connected hubs.
Is it ever viable to use a link to generate a primary key that unions the surrogate keys of the multiple hubs (using latest DV 2.0.2 specification)?
The possible application I'm thinking of is an entity link table (A) which unions multiple types of entities from separate hubs (legal ownership structure), each with their own separate satellites. Each of these entities can have {0:n} parent or child relationships with another entity of any type (ragged hierarchy). Each of the separate entity hubs also join a hierarchical link table (B) that is the entity-relationship definition (on either parent or child FK).
Is there anything I'm missing here, or is there is a simpler way of modelling this?
I am working on a project manually mapping entities from a SQL db. My primary source of information about columns, keys, relationships, and others is the rlinq generate by Telerik from the db.
I wonder if it's possible to detect a many-to-many relationship based on only in this file.
Is there a standard way in CUBA to modelize attributes for many-to-many association ? Documentation omits the topic so I guess it is not. In this case, is this in the roadmap ?
For many-to-many association (e.g between Products and Providers), CUBA Studio generates automatically a link table (holding Provider ID and Product ID).
In order to handle specific attributes to this association (e.g Boolean preferredProvider) it would need to add the preferredProvider column in the link table and create a class holding the two IDs and the attribute.
It would also probably impact the platfom mechanism of fetching many-to-many associations.
I'm reasonably sure that CUBA Studio does not manage it as of 2.2.3 - no option in Studio GUI, nothing in doc. It is still of course possible to code the case manually but one would need to manually write JPQL. Not necessarily a big deal but losing a strong feature of the platform here just for one field.
So I created the preferredProvider field as a one-to-one association from Product to Provider, which is a valid workaround at the cost of an additional association.
I'm trying to create a database to analyze the configurations of my servers.
But i have many services that can run on many servers (for failover/load balancing). Also, the configuration of a same service can change from one server to an other, this is why I can't just have a service table
I tried to link the different tables using a single table that tie them all together. I think i'm in NF3 but i'm not 100% sure.
Is that a "valide" database design? database design
I fear that the request to find stuff in the database are going to be a bit complicated.
thank you
It would help more if you showed the actual db design. But...
If you have two tables associated in a many to many relationship, you will need a table in between them that represents the relationship. Tables normally represent entities in the real world, and foreign key represent the relationships. But in a many to many relationship you need a table to handle that complexity.
That table represents and could be called ServiceRunningOnServer and it's primary key should be the combination of a ServiceId (with a foreign key to Service.Id), and a ServerId (with a foreign key to Server.Id).
Any setting for a service that is across the board (not server specific) is an attribute of the service entity and so belongs in the Service table. But any setting that is specific to the server it is running on, is an attribute of the relationship between that service and that server and so it belongs in the ServiceRunningOnServer table.
Yes, this is a perfectly normalized db design. And actually it is the design with the most optimized complexity. Meaning that other designs might make some things easier, but they will also make other things harder. In the end, and in the total sum of things, other designs will over-complicate things. This design will keep the total complexity of adding, updating, reading and deleting data from your database to a minimum.
BizAgi tables are used to view collections in 1-m relationships.
It is also possible to view m-m relationships from the point of view of one entity (thus, a 1-m relationship).
The add and delete buttons don't work with m-m relationships and no errors appear.
Has anybody used them successfully?
My interpretation with an example:
One contract has N clients, and one client has N different contracts. You want to use collections to represent this connection.
The only was I see of representing this information is to have a table of contracts, to which the edit/detail form shows a table of clients for that contract.
You might also want to consider using a form link as a column of that table.
Let me know if this is a correct interpretation.