| Subject | Re: [ib-support] Automatic domain creating |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2001-02-22T16:17:10Z |
At 03:55 PM 2/22/2001 +0200, Gerhardus Geldenhuis wrote:
Its data model is based on field definitions (RDB$FIELDS) that are
independent of table definitions (RDB$RELATIONS) and matched through
junction records (RDB$RELATION_FIELDS). A field is an entity - it has
semantic content. For example, a customer number is different from a
quantity on hand, although both are integers).
The RDB$FIELDS records establish data type, length, scale, etc. The
RDB$RELATION_FIELDS records can give a name to a field in a table and
override some of the less essential characteristics. For example,
the "badge number" field might be included twice in the employee
table, once to identify the employee and once to identify the supervisor.
This design fit with the literature which included the concept of "domain"
- though that word was used in two different senses, leading to confusion
(on my part at least).
Then SQL took over the world. The first version had no concept of
domain or global field. Fields were just parts of tables. We had
two choices to map our model onto SQL. One was to create a dummy
domain for every column in every table. Another was to create some
generic domains and map columns into them. The problem with the
second choice is that InterBase has always permitted considerable
changes to fields - length, type of number, etc. The common mapping
could - would - lead to unpredictable behavior - changing one column
affecting another.
Certainly, if you wish, you can define domains for the common
fields types and reduce the number of domain definitions, but
even a very complex schema has relatively few fields - in the
thousands, perhaps, but not in the millions. The database is
designed to handle millions of rows. The size of RDB$FIELDS
just isn't an issue.
Regards,
Ann
www.ibphoenix.com
We have answers.
>I have noticed that IB creates a domain for fieldtypes that is notInterBase was designed before "SQL" became synonymous with "relational".
>domains.(Explicitly defined by user as domain)
>Why is this ?
>Would it be better to create a integer domain or such like, instead of
>having RDB$XXX you will only have +-50 domains.
Its data model is based on field definitions (RDB$FIELDS) that are
independent of table definitions (RDB$RELATIONS) and matched through
junction records (RDB$RELATION_FIELDS). A field is an entity - it has
semantic content. For example, a customer number is different from a
quantity on hand, although both are integers).
The RDB$FIELDS records establish data type, length, scale, etc. The
RDB$RELATION_FIELDS records can give a name to a field in a table and
override some of the less essential characteristics. For example,
the "badge number" field might be included twice in the employee
table, once to identify the employee and once to identify the supervisor.
This design fit with the literature which included the concept of "domain"
- though that word was used in two different senses, leading to confusion
(on my part at least).
Then SQL took over the world. The first version had no concept of
domain or global field. Fields were just parts of tables. We had
two choices to map our model onto SQL. One was to create a dummy
domain for every column in every table. Another was to create some
generic domains and map columns into them. The problem with the
second choice is that InterBase has always permitted considerable
changes to fields - length, type of number, etc. The common mapping
could - would - lead to unpredictable behavior - changing one column
affecting another.
Certainly, if you wish, you can define domains for the common
fields types and reduce the number of domain definitions, but
even a very complex schema has relatively few fields - in the
thousands, perhaps, but not in the millions. The database is
designed to handle millions of rows. The size of RDB$FIELDS
just isn't an issue.
Regards,
Ann
www.ibphoenix.com
We have answers.