It would be very helpful if we could create query layers on file geodatabase data.
Even though FGDBs don't have a SQL spatial type like ST_GEOMETRY, it would still help to use non-spatial SQL in full blown SQL queries on file geodatabases.
Although a Query Layer and Database View could give the same result within a map, the implementation is different. I think the difference is enough to warrant keeping this idea.
My thoughts are: Query layers are useful for temporary or one-off cases where you don’t want to create an object in the database.
This would be a game changer. Query layers are an amazing tool in our arsenal, but being limited to only enterprise GDBs severely cuts down on our possible uses, given that a lot of data lives in file geodatabases.
Especially for users without enterprise GDBs, not being able to use query layers is really limiting.
Like JoshuaBixby and Bud say, although the end result is the same, the implementation matters. Layers are great because they ultimately don't really take up any space. Creating a view (which is also very cool) adds yet another item to clutter the GDB, and is a more permanent solution for what could be a throwaway question.
Another great thing about query layers (and views) is that they can get around several Arcade limitations, such as exporting the value returned by the expression as a field, or symbolizing based on a related table. Being able to use a computed columns with a file geodatabase (or mobile) would open up a world of possibilities.
