(DEV)
Programma’s waarbij je een database gebruikt, worden dikwijls ontwikkeld op een andere databank dan diegene die uiteindelijk zal gebruikt worden.
Stel dat de ontwikkeling gebeurt op server (DEV), met databank employee. Die server kan evengoed een virtuele machine, je eigen desktop of laptop zijn.

Structuur (DEV) –> (PRODUCTION)
Op een bepaald moment wordt het programma in gebruik genomen, en maak je dus een definitieve databank aan op de server (PRODUCTION), die werkelijk gebruikt wordt. Waarschijnlijk houd je je DEV voor verdere ontwikkeling, met een kleine test-database met relevante gegevens voor wat je aan het ontwikkelen bent, terwijl die van de (PRODUCTION) server met rasse schreden in volume toeneemt.

Data (PRODUCTION) –> (TEST)
Die verdere ontwikkeling testen met echte productie data wil je misschien laten doen door iemand anders, terwijl jij voortontwikkelt. Dan is het handig om een (TEST) systeem te hebben. De data kan je uit de productieserver halen, zodat je op grote aantallen data kan testen, wat realistischer is.

(DEV) ? (TEST) ? (PRODUCTION)
Als je nu vanop je ontwikkelomgeving programma’s wil gebruiken met data van TEST (vers geupdate van PRODUCTION), moet je de gegevens van je verbinding met de databank in het programma aanpassen. Waarschijnlijk in een settings- of configuratiebestand, wat het iets gemakkelijker maakt. Je kan dat settingsbestand dan in versies DEV en TEST maken, en met een shell script het te gebruiken configuratiebestand kopiëren over het standaard configuratiebestand. Of kan het vanuit je software?

Dataset
Concept: je kan in je programma voorzien om verschillende datasets te gebruiken. Gevolg is dat je in een menu kan omschakelen naar “dev”, “test”, of “production”, en dat de juiste connectiegegevens geladen worden.

Ik gebruik een aparte module voor de data (1)
MData

Ik nummer mijn datasets, zodat ik ze gemakkelijk kan aflopen maar ook in de Settings kan opslaan: 0, 1, 2…
Ik houd in een variabele in de data module bij welke dataset momenteel in gebruik is:
PRIVATE iCurrentDataSet AS Integer

Ik geef de dataset een standaard naam in de module die de data gebruikt:
PRIVATE CONST sDataSetName = "dbdata"

Voor de eigen data heb ik dus db configuraties:
dbdata0, dbdata1, dbdata2 (0-dev, 1-test, 2-production).

In de Settings file komt bv:
[dbdata0]
servertype="mysql"
datasetname="dbdatadev"
database="maindb"
host="localhost"
login="myapp"
password="ldfjq5sehrqz"
...
[dbdata1]
servertype="mysql"
datasetname="dbdatatest"
database="maindb"
host="test.copyleft.loc"
login="myapp"
password="ldfjq5sehrqz"
...

Om de instelling van de juiste dataset “sDataset” op te halen, te bewaren moet je hem natuurlijk kunnen benoemen:

Settings["dbdata1/host"]

Of via universelere code
sDataset & "/host"
waarbij
sDataset = getDataSetString(iCurrentDataSet)

Die is samengesteld van de naam plus het nummer, een procedure uit de betreffende module levert die:

PUBLIC SUB getDataSetString(i as Integer) AS String
   RETURN sDataSetName & Str$(iCurrentDataSet)
END

Hiermee kan je de voorkeuzelijst vullen.

Als je meer data modules gebruikt:

Een aparte module voor de data, import, export, enz, met telkens hetzelfde systeem.
MData
MImport
MExport

krijgt in elke module de dataset een *andere* naam:

dbdata = voor de eigen data van het programma
dbimport = voor data die geïmporteerd wordt uit een andere databank
..

Voor de import data heb ik dan datasets:
dbimport0, dbimport1, dbimport2

In de settingsfile zijn die dan terug te vinden:

[dbimport0]
servertype="mysql"
datasetname="dbimportdev"
database="maindb"
host="localhost"
login="readimport"
password="ldfjq5sehrqz"
...
[dbimport1]
servertype="mysql"
datasetname="dbimporttest"
database="maindb"
host="test.copyleft.loc"
login="readimport"
password="ldfjq5sehrqz"
...

Een aanzet tot ietwat universele code:

PUBLIC CONST sDataSet AS String = "dbimport" ' <---- Change this
' to change for each module - base for name in settings file

PRIVATE iCurrentDataSet AS Integer = 0 ' no of dataset, 0 is default, alternatives 1, 2, .. defined in settings

PRIVATE sCurDataSetName AS String ' 

PUBLIC $hconData AS NEW Connection



PUBLIC SUB getLastError() AS String
  
  RETURN sLastError
  
END

PUBLIC SUB resetError()
  
  sLastError = ""
  
END


PUBLIC SUB curDataSetString() AS String
  
  RETURN getDataSetString(iCurrentDataSet)
  
END

PRIVATE SUB getDataSetString(i AS Integer) AS String
  
  RETURN sDataSet & Str$(iCurrentDataSet)
  
END

PUBLIC SUB getDataSetName() AS String
  
  RETURN sCurDataSetName
  
END


PUBLIC SUB loadDataSet(iDataSet AS Integer) AS Boolean
  
  DIM sData AS String
  
  iCurrentDataSet = iDataSet
  sData = getDataSetString(iCurrentDataSet)
  
  DEBUG Settings.Path &/ Application.Name & ".conf"
  IF (Exist(Settings.Path &/ Application.Name & ".conf"))
    sCurDataSetName = Settings[sData & "/datasetname"]
    WITH $hconData
      .Host = Settings[sData & "/host"]
      .Name = Settings[sData & "/database"]
      .Login = Settings[sData & "/login"]
      .Password = Settings[sData & "/password"]
      .Type = Settings[sData & "/servertype"]
    END WITH 
    RETURN TRUE
  ELSE 
    iCurrentDataSet = -1
    sLastError = "Could not find data connection settings " & Error.Text
    RETURN FALSE
  ENDIF   
  
END


PUBLIC SUB goConnect() AS Boolean
  
  TRY $hconData.Close
  TRY $hconData.Open
  IF ERROR 
    sLastError = Error.Text
    RETURN FALSE
  ELSE 
    RETURN TRUE
  ENDIF 
  
END

Naar aanleiding van een vroeger artikel over hergebruik van code, kwam ik op de kwestie van de standaardisering van de veldnamen in een databank. Algemeen zie ik twee systemen gebruikt worden:

1. Met prefix:

Meestal een korte prefix die de naam van de tabel aangeeft, zodat je altijd kan zien waar de veldnaam op slaat:

Inderdaad de employee tabel, “emp” of beter “employee”.

2. Zonder prefix

Zonder tabelnaam (afkorting) in veldnamen:

In dit geval moet je de (afkorting voor) de veldnaam niet meegeven. Als de database vermeld wordt is het toch duidelijk:

emp.id
employee.name
employee.fieldname1
employee.creat
employee.creby
employee.updat
employee.updby

eventueel met korte alias

emp.id
emp.name
emp.fieldname1
emp.creat
emp.creby
emp.updat
emp.updby

Veel code blijft korter, maar een luie blik op de resultaten van een query kan iets meer aandacht gaan vragen (om de oorspronkelijke tabelnaam te zoeken), en misschien worden je aliassen langer e.veld wordt emp.veld voor table employee.

Vgl:

e.emp_id, e.emp_name
emp.id, emp.name

De prefix blijkt vooral een overblijfsel te zijn van vroeger, toen alle veldnamen uniek moesten zijn (ook buiten de tabel).

De algemene raadgeving is: geen prefix gebruiken:

• korter
• eenduidiger
• goede tabelnamen en aliassen te gebruiken
• betere standaardisatie

Pro prefix:

• oude systemen waar het moet
• geen probleem met gereserveerde woorden (commanodo’s in de query taal)*
• gemakkelijk bij export want tabelnaam staat in veld.
• soms beter leesbaar omdat velden altijd dezelfde vorm hebben.

* stel dat je een veld hebt waarin je aangeeft dat er een update gebeurd is of moet gebeuren:
employee.update
Helaas, UPDATE is een gereserveerd woord in de SQL taal (SELECT update FROM …), en zo zijn er nog woorden die door de syntax highlighting kunnen aangewezen worden als “gereserveerd”. Door prefixen te gebruiken moet je daar nooit op letten. Maar je kan ook ‘quotes’ gebruiken rond het gereserveerd woord als veldnaam.

Zie ook discussie op StockOverflow: (1) en (2)