The original Radius administrator (who has since left) upsized our
current db from Access (using the triggers option). Since then, I've
noticed some things that have me believe that we could (should?) rebuild
our database using a better schema. Here are some questions:
1. Should the schema be based on DRI instead of triggers?
2. Should there be referential constraints (or triggers) on:
- RadAttributes to RadConfigs (RadAttributeID)
- AccountTypes to RadATConfigs (AccountType)
- RadAttributes to RadATConfigs (RadAttributeID)
- others?
3. Can the MasterAccounts and SubAccounts table layout be based,
alone, on the fields defined in the 'radiusnt.doc'?
That is, I want to split my registration database and apps from
the RadiusNT database, and use RadiusNT on a
radius only database/server.
4. Where are the definitions for the RadRoamServers and RadRoamDomains
tables talked about in 'radiusnt.doc'?
We have two tables 'RadRoams' and 'RadRoamServers' that have the
following column definitions.
Are these correct?
RadRoams - "RadRoamID" "int"
"DomainName" varchar (32)
"Domain" varchar (32)
"CostPerMinute" "int"
RadRoamServers - "RadRoamID" "int"
"Priority" "int"
"IPAddress" varchar (16)
"ServerName" varchar (32)
"Timeout" "int"
"Retries" "int"
5. Most important, what are the correct indexes for subaccounts and
masteraccounts so that RadiusNT can process
the authentication query without doing table scans? The query,
taken from 'radius -x15', looks like the following:
Select DateAdd(Day, (ma.extension + ma.overdue),
maExpireDate), DateAdd(Day, sa.extension,
saExpireDate), sa.AccountID, sa.AccountType, sa.Password,
sa.Login, sa.Shell From
MasterAccounts ma, SubAccounts sa Where (sa.Login='user' or
sa.Shell='user') AND
ma.CustomerID=sa.CustomerID and sa.Active<>0 and
ma.Active<>0