What is disadvantages of query database smart service

The main thing to remember is that the the Query Database smart service uses SQL, while querying and writing data through records uses the structure of the data model you've already defined in your application, which should make it easier and faster.

Since Appian is a low-code platform, using records is our low-code method of interacting with your database and other systems. At this point I'd only recommend using the Query Database smart service if something isn't obviously supported through records (which is getting pretty rare at this point).

Can you give some more context to the question? Are you trying to make a decision on which one to use?

The main thing to remember is that the the Query Database smart service uses SQL, while querying and writing data through records uses the structure of the data model you've already defined in your application, which should make it easier and faster.

Since Appian is a low-code platform, using records is our low-code method of interacting with your database and other systems. At this point I'd only recommend using the Query Database smart service if something isn't obviously supported through records (which is getting pretty rare at this point).

Can you give some more context to the question? Are you trying to make a decision on which one to use?

 Peter Lewis 

Thanks you for your response.

In our system's database structure there are many places where recordtype relationships are not possible.
In our system, the usage rate of the query database smart service is expected to be approximately 70%.
I'm worried about it's okay or not.I'm looking for a better way.

spykid said:

In our system's database structure there are many places where recordtype relationships are not possible.

Why not? Can you provide more context?

spykid 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?

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.