Suggestion: Allow choosing optional category with DB fields

[Kevin W]

In Pages Databases the ability to use a "Database Relationship" as a field type is excellent but it would be really nice if it could be taken one step further and allow for an optional category from the linked DB to selected.

By allowing a DB to use categories to group records together (combined with allowing form fields per category) it allows for some really nice organization for potentially large databases but when that database is then used as a foreign relationship field in a second DB then that organization is a lost a bit.  To expand upon that in an example scenario, let's say that you create a database configured as a wiki with the focus being dining in NYC (again this is just an example scenario).  In that wiki you then use categories to group records together into different categories such as restaurants, chefs, suppliers, and locations.  You then create a second database that will be used for recipes.  In that second DB for recipes you want to include optional fields for "Created by Chef" and/or "Restaurant First Served At".  The possible answers for those fields just happen to already exist in your first wiki database in the categories "chefs" and "restaurants".  Great, now you can cross link the recipes to the pertinent entries in your wiki!   Unfortunately though when the database relationship field is created you can't specify to restrict the choices from within the "chefs" category or the "restaurants" category, instead all records from the wiki database become valid responses.  😞

[opentype]

2 hours ago, Kevin W said:

In that wiki you then use categories to group records together into different categories such as restaurants, chefs, suppliers, and locations.  

I don’t think that is a good approach. If the entries are this different, there is no point in forcing them in one database. Each of those should be a database of its own and then your problem with the database relationship field would vanish as well. 

[Kevin W]

5 hours ago, opentype said:

I don’t think that is a good approach. If the entries are this different, there is no point in forcing them in one database. Each of those should be a database of its own and then your problem with the database relationship field would vanish as well. 

As mentioned, those types of groupings is a natural fit for a wiki type database using categories.   Having to create several wiki databases, instead of using categories, just to accommodate being able to link to them, is a far more ugly approach then having an optional category selector when defining the DB link.

[opentype]

2 minutes ago, Kevin W said:

 Having to create several wiki databases, instead of using categories, just to accommodate being able to link to them, is a far more ugly approach then having an optional category selector when defining the DB link.

Please do not put words in my mouth. I haven’t made that argument at all. I did NOT say you should create multiple databases JUST to solve the linking. I said it is a bad approach in general to collect data with a completely different structure in one database. I mean, that should hardly need explaining. The IPS database doesn’t store members and forum topics in the same table and then separate them by a “member” and a “topic” category. There will of course be two database tables with fields specifically tailored to just that content stored in them. In the same way, I would usually not collect “chefs” and “restaurants” in the same database. They are just too different. 

And I don’t see how that is related to it being a Wiki database. That functionality is just about who can edit the content. It is unrelated to the structural demands of the database. As an example: On one of my sites I have a database since IPS 3.4 about fonts with links to a second database of font designers and a third database for font makers. None of my users has a problem with editing each content type in their respective databases. 

[Kevin W]

This is silly; I'm suggesting a really minor enhancement to features that already exist. Really, it's just a natural extension of the existing offerings. I gave a suggestion and gave an example scenario; if you don't see the benefit of such an enhancement then great, your data needs & usage are different from mine, but I, and I suspect others, would welcome the enhancement even if you don't.  

 

 

 

 

 

(So is this how suggestions are usually responded to in the IP community?  Yikes!😳)

[opentype]

30 minutes ago, Kevin W said:

I gave a suggestion and gave an example scenario;

And I explained to you that the problem you ran into is the result of a questionable setup you could easily change, so you would not only solve the problem at hand but also avoid running into other problems because of that setup. I am investing time to help you see that—entirely for your benefit. You could say “thanks, I haven’t considered that …” or something along those lines—or even completely ignore it, but dismissing it all as “silly” without even trying to address my points is pretty disappointing and somewhat ungrateful. I just helped you a couple of days ago with the category field settings. My comments here are in no way different. It’s just potentially helpful advice you can consider or not. But it’s not “silly” just because it isn’t full support of your request. 

30 minutes ago, Kevin W said:

if you don't see the benefit of such an enhancement then great, your data needs & usage are different from mine, but I, and I suspect others, would welcome the enhancement even if you don't.  

And again you are putting words in my mouth. I haven’t judged the feature at all, nor have I suggested in any way that IPS should not include it. The validity of my advise not combine such kinds of data types in one database is completely irrelevant from whether I would need or use that feature. 

30 minutes ago, Kevin W said:

(So is this how suggestions are usually responded to in the IP community?  

Pretty much. IPS will usually not publicly comment on feature requests, but the other clients are free to discuss them. And why should they not? It’s deliberately set up as discussion forum. Everyone can be heard. What did you expect? I’m sure you wouldn’t mind supporting replies. But everyone else should shut up? This is not how forums or the internet work. 

[Kevin W]

1 hour ago, opentype said:

And I explained to you that the problem you ran into is the result of a questionable setup you could easily change,

No, it's "questionable" to you. 

 

Am I missing something here?  Are you an unidentified IP staff member or something and that is why you are being so argumentative about a suggestion that you're not even interested in? 🤔

[opentype]

You seem to be completely flabbergasted by the idea that people could have disagreements in online forums and are willing or even interested to talk these things through for the benefit of anyone involved. You know, learning things by considering new arguments and information. And no, that doesn’t need a hidden agenda nor do I need to be an interested party in a certain feature to comment on it. That’s a really strange reasoning. People can still care about the correctness of claims and the validity or soundness of arguments presented in public forums. Can I not care about a questionable statement when it involves a different country I am not living in? Can I not care about about a statement about women’s right just because I am a man? And so on … I hope you see that this logic of “if you don’t want to use it, stay out of it” makes little sense. 

But it’s okay. I won’t bother you anymore with advice or any kind of Pages help in the future. No problem. IPS has a feature to make sure of that. 

[Kevin W]

3 minutes ago, opentype said:

You seem to be completely flabbergasted

While you seem flabbergasted by the notion that your opinion is not the only one and your "solution" to the scenario described makes no sense from a DB data perspective.