I wrote a program that supplies access to the input and performs various transformations, and faced with the fact that if something changes in the input database structure, then the code will have to be strictly refactored ... The fact is that I work through interop in some places I make requests for updates, which are encoded in the code, in another place where the power of high-level languages ​​is required. I open the recordset and update the records. You can load everything into memory and work through datatable, but I was afraid of large databases and refused this idea ... Tell me, it is best to get away from what is in the code, which is easy to edit if the structure changes, maintaining high processing speed.

  • "various transformations" is what? - Firepro
  • Well, let's say there is base A, as a result of the work, base B is obtained with a completely different structure and set of fields. Different logic can be applied to the fields when working through a recordset, for example, parsing. - iluxa1810
  • Implement this logic through the rule rules in your code and then you will not have to always change your code to solve this problem. Some rules can be made permanent, some changeable, you can make a set of transformation rules. - Firepro
  • 2
    > the problem is that the queries to the database are encoded directly in the code - so set the values ​​of all fields / tables in the code by constants in one place. Then use them when building queries. Refactoring is reduced to changing the values ​​of the constants in one place. - pegoopik
  • one
    @ iluxa1810 but have you heard about the DTO & DAO templates? - Senior Pomidor

3 answers 3

Create a table in the database with the base config. And, proceeding from this, form SQL queries. For example, create an info table with a table description.

CREATE TABLE info ( ID int identity (1, 1) primary key ,NameTable varchar(50) ,NameColumn varchar(50) )

When launching the application, we read this table and form queries for other tables. For example, load the table in a DataTable with the name infoTable:

 string command = "SELECT [ID] "; foreach (DataRow row in infoTable.Rows) { command = command + ",[" + row[2].ToString() + "]"; } command = command + " FROM [" + row[1].ToString() + "]";

As a result, the command produces a type request:

 SELECT [ID], [NameColumn1], [NameColumn2] FROM [NameTable]

And so on ... The table in a DB changes, we change the description, requests are formed differently.

    Another option is to change the program so that it only 001_update_table1.sql external scripts (in the form of files 001_update_table1.sql ), which you will edit if necessary. In this case:

    • You will not need to rebuild and rewrite the program implementation all the time.
    • You can implement support for different versions of the database.
    • Editing in one place (only in scripts), it is not necessary to look for variables in DataSet'ah go zahardkozhenyh variables.

      And maybe at the entrance to submit not only the database, but also the change package. The structure that will describe such a list of changes can already be developed depending on the tasks.

      Thus, when changing DB, you will not need to edit the code, but only the file with the necessary changes.