Relationships
I have a scenario where a client is wanting to create a database related to plants. Multiple plants that have a lot of properties.
The issue I have is when I create a second plant, It cant share the same properties as the first plant. I have tried many/many and 1/many, this seem impossible.
6 replies
-
One way of dealing with "a lot of properties" would be to have a parent "plants" table with a child "properties" table. The "properties" table could have name/value pairs, with a "name" column and a "value" column. That way you could have an almost unlimited number of properties.
You could then duplicate the above two tables and add "templates" to each table name, so you would have a "plants templates" table with a related child "properties templates" table. Add records to the templates tables for common groupings of plants/properties.
Then make it so when a user clicks on a "plants template" record, the record and its related child records would be copied over to the plants/properties tables. That way you would be saving the user from having to retype commonly used plant/properties. They would only need to add the less common properties.
-
So what I ended up doing, was I guess the same or similar to what you suggetested. I put in subforms to the plant table, with a relationship to the properties tables. This allows me to set up a Many to Many scenario, making it possible for plants to have shared properties and property to have multiple plants.
The template idea is something I want to experiment with, as when adding a property, it would be great in the future to be able to select multiple properties.
-
I have a similar use case and agree this would be helpful.
-
One day perhaps, my fear at the moment is Nioxus.
-
That made me laugh
. Are you referring to hour long videos to explain something that should only take 5 minutes or enhancements that you have to pay an extra subscription fee for, or, or... -
haha not so much the videos themselves, it's the plugins they are developing as in the Calendar Plus and Reports Plus plugins. Ninox has not built or improved on there own. So in order to use a better reporting engine, I need to pay Nioxus MORE than what Ninox is worth in a year, per user. Which is wrong. A plugin should be a perpetual license for the team/owner, not each member.
I have paused developing in Ninox until they pick their game up and actually compete with the current market.
Content aside
- 4 yrs agoLast active
- 6Replies
- 1246Views