How are you handling the database?

Question

Delphi

Good day.
The other day I did a test task for one office and about writing database processing they had a question: "Why don't you use components to work with the database (BDEdit, DBLable, etc.)". I always wrote and continue to write in such a way that when editing records, I fill out the form with the data of the edited record in the usual Edit and then process it.
Essence of the question: What is the difference and does the speed of processing "crutches" or queries, filling, etc. play a role?

Answer 1

Quite a lot of standard functionality is built into the components. By using components, you not only save time, but also reduce the amount of code in a unit, which is a big plus for someone who will read your code later.
The basic functionality for displaying and editing data from the database can be thrown into components without a single line of code at all, and it will work quickly and almost certainly without errors - why not use this feature?
>> That is, objectively, the difference is only in the speed of writing and in the amount of source code?
0x0CB : Not only. The principle of operation of standard components is known to most developers, so understanding the operation of the program for someone who did not write it will be much easier than disassembling your bikes.
Components have been written and refined over a long period of time - they took into account a lot of programmers' experience, fixed a lot of bugs, provided for a lot of troubles, optimized work with resources, etc.
In general, these are the usual advantages of using libraries against bicycles. For Delphi, if you use the standard DBEdit, DBGrid, etc., even the downside of having to install the components on another machine to edit the code is gone, since they are built into the IDE.

Answer 2

When programming with crutches, you spend time writing the functionality that is already in DB* controls.

Answer 3

"Why reinvent the wheel if it already exists"
Components contain additional functionality and logic that a developer may not track. For example, if you try to insert incorrect data into the database (incompatible by type), so if there is a ready-made solution, then use it.

Answer 4

Why do we never use any DBEdit, DBMemo, etc. Because with them there is a bunch of hemorrhoids. To be honest, I don’t remember which ones, it was a very long time ago, but it was even strictly forbidden at one office in the coding agreement. Sorry that is not very informative, but a fact.