What is disadvantages of query database smart service

What is your use case?
Query databases and record types are not directly comparable; they serve distinct purposes.

EAch one of them are totally different, and serves for different purposes.. even when both of them works againt database....

Unknown said:

even when both of them works againt database..

Just to add to David's  point . Record data with Sync enabled stored in Appian Memory (It's like a Cache data). 

spykid said:

What is the disadvantages of query database smart servie

I can say direct Database interactions . Where as when you Query Records you are not hitting DB directly

When you work with Record Types, you work with an strcutured data model, but when you work with query database you are working with queries.

For example, if you have two records in Appian, but you need two execute an SP, a view, or just a query with an special agregation, you use queryDatabaseSmartService....even when you are working with the same tables...

Could you please explain in more detail?
What are the different purposes of each?

Check the next answer. 

I will not say those are disadvantages as others have mentioned earlier. Each serve its purpose.

The main difference would be that when querying from records, you are trying to get the data from the memory i.e., cache which gives you a quicker response. Also you would not perform a direct query on the database.

Heres something from the documentation which will make it clear

"Data sync caches your source data in Appian.

Think of it like a cache on your web browser: when you cache web content locally on your browser, your site content loads faster and improves the speed of your browsing. The same applies when you sync your source data—Appian only has to execute queries against your synced data instead of the external source, so your record data will load faster. In addition to faster queries"

https://docs.appian.com/suite/help/22.2/records-data-sync.html#how-does-data-sync-work

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?