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
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'm building a SaaS system that allows users to define their own data models and enter data according to those models. It's a bit like airtable.
One user might model a bookshop, and would have a Book model, with title and ISBN fields. Another user might model medical records, and would have "date of last visit" as a field.
In the case of the bookshop, I want users to be able to search on title and ISBN. In the case of the medical records, I want users to be able to search on the date of the last visit.
I am using Firestore as my backend.
Firestore requires an index to enable a search. So that approach will not scale as # of customers increases.
My thought therefore was to have a Firestore instance for each customer, and those specific instances would have the necessary indexes.
I'm sure there are downsides to doing this though.
What would folks recommend to best solve this need?
What you are trying to achieve is some kind of weird, since you will not provide at least a few standard common properties for each user of your Bookshop.
When you want to perform a search in a Cloud Firestore database, you need the exact name of the property on which you want to search for. Having dynamic properties might not help you solve the search feature. However, you can create a document with a property of type array that can hold the name of all properties the users have chosen and perform a search on every property, but this solution will be much too expensive.
In my opinion, a possible solution might be to create at least a few common properties, so you can have the properties on which you can search. When someone creates, for example, a book shop you can display at the beginning all available properties a user can choose. Once you create a shop, you can have different users with different shop properties. This means that if a user does not choose a property, when you perform a search on that property, the results won't contain his/her products. This will work, only if you have predefined properties.
I have these entities :
Now, I need to create form to store data.
My problem is, I don't know how to figure out to create those forms.
What I want is a form where I can create a User, and here, I can select a Pack.
When I selected it, a list of Services of the selected pack appears, which I can checked if it is consumed by the User.
More complicated, I need to allow User to have several pack, and same pack is allowed.
It's look like a collection of User_Pack_Service form, but how to keep the Pack of each collection?
Other questions, since Pack_Service is a relation table of ManyToMany relation ship, it complicated the way of add Services in Pack. Is there a way to avoid is creation as entity? (I know I need it to link Pack and Service to User but that result in to many entities for nothing...)
Thanks for your help.
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'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 ;)