What is disadvantages of query database smart service

The Query Database smart service is pretty horrible - cumbersome, unflexible, and also fairly dangerous in the wrong hands.  I practically never use it if it can be avoided at all.  The only time I ever willingly use it is to execute a specialty SQL statement that checks the next available ID in a database and reserves an entry using that row at the exact same time, to avoid a weird race condition.  And under most circumstances this can just be done with a regular Query Entity call and clever process node arrangement.

For everything else, you should be using Query Entity (since you said RecordType data is not usable to you - if it were, it'd probably be best to be using that at this point).  I don't know of any reason to ever use the Query DB smart service when you could be reading and/or writing using Entity data.  I know there are some extreme edge cases, but they're rare at best.

If you mean that 70% of your queries would be using the QD Smart Service - that is too much IMO.

I only use QD in exceptional situations. Should definitely not be the norm.

IMHO using QD for 70% of your queries feels like something was going severely wrong in solution design.

Can you explain why that is?

Peter Lewis 

Peter Lewis said:

Why not? Can you provide more context?

The database design was really really really really bad and recordtype relationships are not possible.

Peter Lewis said:

In our system, the usage rate of the query database smart service is expected to be approximately 70%.

Also can you give more context to this one? I'm not exactly sure what usage of 70% means - 70% of what?

The usage rate of the query database smart service is about 70% means data registration, update and select mostly use query database smart service because the record type relation are not possible and the only way is to write complex queries.

Is it best to modify the database design?

Personally I don't think I've heard of a project doing 70% of queries through the Query Database smart service - essentially you're missing out on all the benefits of a low-code platform if you're doing that.

I'd be interested in hearing more about your data model - for example, are there other systems that are using? In general though I think it's worth considering a refactor of your design to better support data in Appian.

spykid said:

the only way is to write complex queries.

Query Entity, combined with using Views as needed, can provide pretty much any complex queries you need, IMHO.  And these are MUCH easier to create, test, and manage, than the QDB Smart Service.

yes,the data model is also used in other systems.

Mike Schmitt 

Is query entity easier and has better performance than query database smart service?

With respect to doing read-only queries from DB tables and views, every single thing about it is both easier and better, as i've been saying.