I would like to have a one-to-many relationship with extra information attached: Each organisation has a customer-id for a specific vendor (because purchase orders are processed in the name of the organisation).
What is the best way to achieve that?
If one organization can be related to only one vendor (have uitype 10 field), best way to store vendor specific Id - make additional field for organization. If relation is many-to-many - you have to add special table (like OrgToVendorRel) to store relation data. And all necessary functions to process it.
Oleg
Oleg.a#pinstudio.ru
Related
The demand is this:
a user belongs to multiple departments, and the roles in each department are different, and each role has different permissions.
The general idea is You need to build another layer of relationships on the relationship table. I wonder if there are other better designs
Before making "super improvements" follow the "natural" strategy. If something belongs to some other thing what is the pattern you "naturally" need to use?. While exist ways to "split database tables" into some more 'simple' tables (https://www.bmc.com/blogs/canonical-data-model/) there is not a complete answer as for some db engines you might need to repeat fields to cache some info. This is typical when a server allows you only a limited number of db calls per transaction.
i have this project where i have an issue, there are 3 relevant enteties.
User:
has_many: Leads
Bot:
has_many: Leads
Lead:
has_one: User/Bot
Now, a user and a bot share a lot of the same things, but they use different firewalls, they have many different fields etc, but i want a user and a bot to be interchangeable in regards of who a lead belongs to, it can either belong to a bot or a user, never both at the same time.
And in many of my other enteties where i run stats etc, i refere to a single field, i dont check if there is a user or a bot.
Is it possible to make these 2 enteties share the same Primary key and then just somehow refer to a single entity in the Lead field ?
Or what would be the best design approach in Symfony?
If you have all fields the same in 2 entities I would recommend you to drop Bot entity at all. All you need is just one field type with available values bot and user. To optimize SQL queries I would recommend you to declare this field as ENUM type.
Also if you really need different entities you can use Single table inheritance with discriminator field type described above.
I feel pretty lost on collections, and entities as it stands.
My purpose:
A user will have one or more abilities. There are a set number of abilities, and numerous users. (A user entity, usertoabilities, abilities)
I want to display a form of the set abilities (lets say running, swimming, climbing), with properties such as (skill level, length of time).
The user would check each ability they have, and select their skill level and time.
My current understanding, is that my form will contain:
a collection of abilities (collection of entities), a collection of skill levels, and a collection times.
The form will print out each row of abilities with the corresponding properties. Where the user selects these abilities and saves them.
Is my understanding correct?
My current approach seems to have me going in circles.
you can create only two Entities (User and ability) and you need to create a ManyToMany Relation where you need to set a field (property) that is the relations field with some annotations where you wil set the "JoinTable" that in this case is "usertoabilities" for the two entities and more fields that will be the "abilities" you can find more information in http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html
I'm working on a studio project to try to learn different approaches using Symfony2, Doctrine 2.4.7 as ORM and MySql 5.5 as DB. I've deliberately minimized my question for a better understandability and readability, if you need more details you only have to ask and apologize me if my english is not so good.
To avoid a large discussion due to the title of my question let me synthesize the problem showing a simple and common case (but complex for me because I'm new with doctrine).
The Model:
The User entity (mapped) that stores the user's data
The Category entity (mapped) that stores some categories associated to the User with a ManyToMany BD.
Each User can select one or more Categories.
The Problem:
User categories are near 100.
Many Categories could have a specific associated form.
Each form is composed by common and/or only specific fields (from 1 to 10 fields per category).
The Goal:
Understand what's the most balanced approach for this use case (in terms of flexibility and performances), for create the entities and associations needed to store the data filled by the user (some of these data I wish they were to be searchable).
Some Related References:
Doctrine2 docs
Serialized LOB
Extensible Data Modelling
and many other threads not much relevant...
A Possible Solution:
Create manually a form type for each category with inside the block of related fields (I use this forms as services in DIC and use blocks for the fields I need to reuse on more then one category).
Create a CategoryForm entity with the properties needed to retrieve the name of the form related to the category (useful to the form factory when I build the form) with an association ManyToMany UD with Category and to store the serialized LOB (the data coming from the form and related to the User).
There is a better approach to avoid the serialization of the object in a LOB? (maybe I'm wrong but serialized data are not searchable/indexable in mysql)
Any other solution or reference to a readable resource is welcome!
Well, I will try to answer the question with a simple guess: the category is something shared beetween several users (since you got the many to many).
So, if you want the User's form to be able to set (add/delete or update) Categories assiated to the user, then you should just have acollection of entity widgets related to the Category.
Why do I say that ?
Since your categories are linked to several users, the way you want to treat the relation beetween Categories and Users will cause any update on existing Category from a User's form to be propagated to other Users.
This means that Categories should be created/updated by a single form (modulo your needs). You can then link the Category to the User from User's form.
As far as the number of form of Categories is concerned, there are several parameters to handle:
Are all the Categories validated the same way (to know if you simply need to hide widgets to make the validation work) ?
Do you have a large amount of different types of Categories ?
If yes, are always composed the same way for a given type ?
Give further details if I'm wrong in my initial guess ;)
It's simple. I have three tables, for example: Persons(ID, Name, etc.) Lessons(ID, ClassroomID, Description, Etc.) Person_Lesson_Link(PersonID, LessonID)
The third table links the two others in an N:M relationship. A person can follow multiple lessons, and a lesson is given to multiple persons. I've created an entity model around these tables, which only shows the Perssons and Lessons tables and which links the two. I've also created a Dynamic Data website which will allow me to work with these tables, adding, editing and removing records as needed. But I still need to know a few things, in the following priority:
I need to filter the Persons based on a lesson. So a filter is needed which shows the lessons.
I need to add a link between a Person and a Lesson. Or edit a link, or drop a link.
So, any examples on how to do this, without having to write lots and lots of code?
(Main problem: I have about 15 of these linked tables, so I need something generic.)
There is standard Dynamic Data field template for editing Many-To-Many relationships in .NET4.0 based on CheckListBox. Download VS2010 and grab templates from there.
Also you can create Filter Template based on this field template for filtering Many-To-Many relationships.