In order to put this in the simplest of terms, we would first need to know that a store procedure is similar to that of functions in your everyday typical programming language. For example, in languages such as C++, we would typically need to provide a specific number of parameters or definitions during function declaration. Then, when called upon them later, we could use those parameters to pass certain user-defined inputs over to the function to perform a more detailed and specific set of actions. This idea of a pre-defined function is nearly identical to a store procedure in terms of its underlying logic. In a stored procedure, you can write a pre-determined set of instructions based on a hypothetical value, a value that a user can input later. This is perhaps one of the biggest advantages of a store procedure because, in doing so, it allows for improved database access security while also enhancing interdepartmental and segmental collaboration; most importantly of all, it improves overall execution efficiency. However, also as you can see from this design, it shifts code execution away from the host machine to the database server. Although this approach resolves the issues facing resource restrained host machines, it does increase the overall resources required for database servers. Nonetheless, the biggest drawback is not just the resource allocation; it is the overall maintenance. Since the user lacks an understanding of the underlying database design, it will most definitely increase the overall debugging difficulty.