Arguments with regard to SpareField1 or specific schema

Because each new feature or property addition requires database changes there is the idea that instead you hold data in fields such as SpareText1, SpareInt1 etc. and this post discusses the relative merits of this and its alternatives. Another place this may be used is to create a common Lookup Field table.

It is my opinion that this should normally be avoided and instead specific schema is used.

Advantages of specific schema

  1. Data type integrity
  2. Required and non-required control by product (Null or Non-Null)
  3. Strongly typed code
  4. Reporting is easier
  5. Discoverability is easier – stay in context
  6. For lookup tables, you will gain referential integrity, and in any case it is possible and not too difficult to create abstract data update forms which may update any of these with data-driven addition of which tables to edit.

Disadvantages of specific schema

  1. You have to change the schema for each change
  2. If you have multiple client databases you may need to change several. If you have many this may be difficult

Mitigations to disadvantages of specific schema

  1. Learn and use simpler design techniques to speed up development. E.g. Entity Framework, code generation
  2. Write forms which may edit any tables. For instance for Lookup tables

Disadvantages of SpareField1

  1. You have to keep a record of what each Spare Field represents. Control and communication of that is difficult, control of a specific, e.g. Length field is not necessary because it says what it is
  2. That may get confusing, or there is a danger that Spare Field may be used in different ways by different people. So in the end it is more complex

Data type integrity

If you have a decimal with precision 4 and scale 2, i.e. 2 dp, max 99.99, then this controls the data. A SpareDecimal1 may have any data type definition, probably too large so as to cope with the general case, and as such bad data may appear, so for instance if you know length is always less than 100 units, then a data entry of 101 is bad data.

Also data type integrity would include Null control

Advertisements

Why use Entity Framework – Justifications

Learning EF takes a lot of time, changing code to use EF is risky, so what are the justifications for considering this.

  1. Entity Framework is listed in NuGet as Microsoft’s recommended data access technology.
  2. You need a lot less code to get and fill objects and reduces the amount of code that you need to write
  3. Closer to OO
  4. It appears to be here to stay
  5. It keeps getting better
  6. Data sets are not being developed
  7. Works well with WPF
  8. You will learn and get better at it in time