Is this Correct database design

HI all,
I have a claims database, which has a header table, details table and
otherinfo table. The header table will contain claim header info, ie
claimnumber date of loss etc., the details would contain claim detail, as
details of loss, damage ammounts, etc, the otherinfo contains information
not common to all classes of claims, so I would have a motor table
conmtaining driver, motor type model etc, GPA, would contain empoyee name,
earnings medical etc.
Now this is just in pricipal, hence no ddl, but anyway, some one suggested
that for the otherinfo table I create a descriptor table that will enable us
to add numerous columns for this "otherinfo" information at will
his quote is:
"descriptor table that can hold the field names, the data type, an input
string regular expression, and a bit field for required or not. Field Start
Date, and Field End Date. Fields can then be added and removed at will"
Whyle this might sound good, my gut says its a bad idea, for starters, it
could be a nightmare trying to create stable reports, etc.
Any other thought here or suggestions
Thanks
RobertYour gut feeling is correct; this is generally a bad idea. SQL
databases should be used for strongly-typed and stable schemas; in
other words, the designer should know what the information is going to
look like before you develop it. Trying to dynamically construct
tables from columns and column values added at will is a performance
nightmare. If a column is needed for reporting purposes (or some other
application purpose) then alter your design.
That being said, there are other database engines that MAY do what you
require, such as object-oriented databases; I've never worked with
them, so I don't know for sure. Yo may also explore other options for
holding miscellaneous information (such as the xml datatype in SQL
2005). However, what your friend is suggesting is NOT a relational
design, and therfore should not be used in an RDBMS solution.
HTH,
Stusql