Create Record type from SQL View

1.  As far I understand , if we create with disable sync feature , it may not be of that useful and performance efficient as indirectly it queries the data from table/view, as nothing is cached.

2. As view is in memory that's the reason they might have disabled the sync feature for this.

3. I would suggest better to create view using record types with sync enabled, instead of querying the view using record. Again up to your use case, just check which is better suits you.

4. Try checking the performance of all the three, querying the record type built on view with disable sync, querying the view using query entity, build view using record types with enable sync.

Just curious to hear the feedback of #4 for your use case.

1.  As far I understand , if we create with disable sync feature , it may not be of that useful and performance efficient as indirectly it queries the data from table/view, as nothing is cached.

2. As view is in memory that's the reason they might have disabled the sync feature for this.

3. I would suggest better to create view using record types with sync enabled, instead of querying the view using record. Again up to your use case, just check which is better suits you.

4. Try checking the performance of all the three, querying the record type built on view with disable sync, querying the view using query entity, build view using record types with enable sync.

Just curious to hear the feedback of #4 for your use case.

I suggest to go with 'build view using record types with enable sync'. This will give you best performance among all the options as database view cannot have index and a query has to run on all the rows of database view. Avoid using database view.

Harsh Kumar Agarwal said:

database view cannot have index

Not sure whether I would go with that, but in general, avoiding database views is a good thing.

 Stefan Helzle  As database views are virtual entity so you cannot add indexes to those. While we make a call from Appian to view using some filter then it reads all the rows of view regardless if that column is indexed in the original table or not.
https://dev.mysql.com/doc/refman/8.3/en/view-restrictions.html

Sure, but depends on what exactly you mean with "index". A table index to support the aggregation in the view, or a unique key constraint in the resulting dataset. That's what I meant and which is just a minor detail in the "views are evil" discussion.