Server sql vs client side sql

Question

I have been looking for answers to this question in the last two hours. I did not find any relevant message / book / response. Can someone explain the difference between server side scripts and client side scripts for me. I know that triggers are part of server-side scripts, but actually, what is the difference between them. Could you provide me a couple of examples.

Thanks!

Answer 1

I don’t think you can say that there is such a thing as “client SQL”. There may be SQL commands / statements created by the client application, but they are executed directly in Database Enginer to save and register.

In other words, the client application can do this:

select * from SomeTable 

If this is successful, then SELECT will be executed on the database server, and not on the client application, even if it was created.

Now you can try to determine where the SQL code is generated. The client application can generate the bulk of the data manipulation language (DML) code (i.e., INSERT/UPDATE/DELETE ) and perform OLAP ( SELECT ). The server will generate SQL and events for things like triggers. The database engine with the trigger will see that an action has been taken on the database, object, or server itself, and then this event will “trigger” the database engine to execute another part of the SQL code. This will be SQL Server Generation.

I think I understand your question, but please let me know if there is anything else or I did not answer correctly.

Answer 2

This may mean a few different things, but the explanation that is probably most important to you (based on your mention of triggers) is that the server-side script is SQL that is precompiled and stored in the database in the form triggers, functions, stored procedures, views, etc., while the client-side SQL client (also known as dynamic SQL) is the SQL that is contained in the application.

Some of the reasons for implementing a server-side SQL server include performance (the database can pre-compile and optimize SQL), security and maintenance (it is much easier to change the stored procedure than recompile and republish your application).

The main reason we found to implement dynamic SQL is to handle situations in which it is not easy to process server-side SQL queries, usually containing variable-length statements.