Validate data against a set of rules

[karl Jonson 0]

Hi,
I have similar student data:

FirstName
LastName
DOB
DegreeType
Course1
Course1StartDate
Course2EndDate

Also, I have rules similar to these:

  FirstName does not match pattern
  LastName does not match pattern
  Student age cannot be greater than 110 or less than 15
  A language degree must have a least one language course
  A language course cannot be given for a non-laguage degree
  Course start date can't be after end date

These are just examples.  I have about 100 data fields & 50 rules.

Which is the best way to validate student data against these rules ?
If student data is valid add to xml if not then add to a list or erroneous records.

TIA

Edited December 3, 2022 by karl Jonson

[programmerdelphi2k 239]

for sure, you needs create a "class" to specific case! then, you can use it in any other similar case!

 

a little skeleton...

unit uMyPeoples;

interface

type
  TMyPeoples = class
  private
    FFirstName: string;
    // ... another fields...
    //
    function GetFirstName: string;
    procedure SetFirstName(const Value: string);
  protected

  public
    constructor Create;
    destructor Destroy; override;
    //
    function ValidMyCurseDate(const ADate, AMin, AMax: TDate): boolean;
    //
    property FirstName: string read GetFirstName write SetFirstName;
    //
    // ... another propreties to another fields
  end;

implementation

{ TMyPeoples }

constructor TMyPeoples.Create;
begin

end;

destructor TMyPeoples.Destroy;
begin

  inherited;
end;

function TMyPeoples.GetFirstName: string;
begin
  result := FFirstName;
end;

procedure TMyPeoples.SetFirstName(const Value: string);
begin
  if (Value = '....') then
    FFirstName := Value;
end;

function TMyPeoples.ValidMyCurseDate(const ADate, AMin, AMax: TDate): boolean;
begin
  result := (ADate >= AMin) and (ADate <= AMax);
end;

end.

the rest... you can use your SQL query to valid all records readed!

Edited December 4, 2022 by programmerdelphi2k

[Fr0sT.Brutal 904]

I'd look for simple expression parser and executor so that the rules could be defined in plain text (and admin could modify them without rebuilding).

Validating at DB side (if you have DB of course) is also an option

Edited December 5, 2022 by Fr0sT.Brutal

[David Schwartz 442]

I'd start by defining a "Rule" that lets you give some conditions and how to check against them. Some things are simple that only need to look at the data item, while others are going to require related (dependent) data stored elsewhere to be tested for validation. So you may want to stagger the testing, filtering the easy stuff first, then queuing up things that require remote access in a way that can do larger batched queries that can pull down data for local evaluation rather than firing off a bazillion simple queries at the back-end. But if there's no easy way to narrow-down the search set, then you might want to send all of the dependent queries to a stored proc on the back end and let it process them and return a table with the results. I've seen all of these approaches in pratice, and it just depends on the nature of the dataset. I also saw one that was optimized for an initial dataset that eventually outgrew it's initial performance assumptions that was getting slower and slower because of back-end data growth, and nobody wanted to touch it for fear of breaking something. So scaling-up over time should be taken into consideration as well.

 

And maybe there's a way to do it all in the back-end DB, but most of the rules that can be applied to the DB tables and fields are to ensure integrity of data in the DB, not application-facing field validation. I'm not sure how you'd do that other than maybe defining a custom table with triggers and whatnot for field validation, then selecting data to copy into it and see what gets blocked. This is a relatively common thing in DB apps, but I'm not sure if there's much built-in to any DBs that lets you implement it. I've seen some apps where this kind of validation resulted in the largest and most convoluted methods in the entire app, and they were hell to maintain. I've never seen a very elegant solution, TBH.