Naming conventions for special database objects

#41

Philipp Post wrote:

Quote:

the more references I have, the better.

If you need a collection, you might check these - but if you ask 100
people, you will get 101 oppinions:

Yes, and some are crazy indeed. But I think it's useful to read the
rationales for insane opinions, thank you!

#42

Philipp Post wrote:

Quote:

the more references I have, the better.

If you need a collection, you might check these - but if you ask 100
people, you will get 101 oppinions:

Yes, and some are crazy indeed. But I think it's useful to read the
rationales for insane opinions, thank you!

#43

Philipp Post wrote:

Quote:

the more references I have, the better.

If you need a collection, you might check these - but if you ask 100
people, you will get 101 oppinions:

Yes, and some are crazy indeed. But I think it's useful to read the
rationales for insane opinions, thank you!

#44

Quote:

That's not the kind of flags I was talking about; say we need to track expenses and some expense types have an additional field [sic: column] to be required in the form [sic: form? like on the input, non-DB side of the house?]. I might add a column in the expense_types table to indicate whether a datum is required.

If you want it to be required, why not use a DEFAULT and a NOT NULL
constraint?

Quote:

The same way, if we write a social network where kids register their quigzmo collection, the "races" table might have a has_tail column -- to avoid asking tail lengths for races that have no tail.

What the heck is a "quigzmo"? Hey, remember I am old! I still say
"hip hugger bell bottoms" and not "low erise flares" and use an abacus
for my check book.

Quote:

And with a clever trick we might change has_tail in minimum_tail_length, where accepted values are 1 and NULL... I'm not sure I like that

If I understand what a "quigzmo" (gotta google that!), then that would
a good choice. Try this line of reasoning:
1) If a "quigzmo" can be modified to add a tail, then a length of zero
would make sense.
2) If a "quigzmo" cannot be modified to add a tail, then a length of
NULL makes sense.

Quote:

A way to avoid the has_tail flag might be to explicitly state the subset of tailed races... with

CREATE TABLE tailed_races
(race_code VARCHAR(10) PRIMARY KEY REFERENCES Races);

but I think it might not be convenient to grow tables like that. <<

The classic scenario calls for a root class with all the common
attributes and then specialized sub-classes under it. As an example,
let's take the class of Vehicles and find an industry standard
identifier (VIN), and add two mutually exclusive sub-classes, Sport
utility vehicles and sedans ('SUV', 'SED').

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
UNIQUE (vin, vehicle_type),
..);

Notice the overlapping candidate keys. I then use a compound candidate
key (vin, vehicle_type) and a constraint in each sub-class table to
assure that the vehicle_type is locked and agrees with the Vehicles
table. Add some DRI actions and you are done:

CREATE TABLE SUV
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL
CHECK(vehicle_type = 'SUV'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE Sedans
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL
CHECK(vehicle_type = 'SED'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

I can continue to build a hierarchy like this. For example, if I had
a Sedans table that broke down into two-door and four-door sedans, I
could a schema like this:

CREATE TABLE Sedans
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL
CHECK(vehicle_type IN ('2DR', '4DR', 'SED')),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE TwoDoor
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL
CHECK(vehicle_type = '2DR'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Sedans(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE FourDoor
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL
CHECK(vehicle_type = '4DR'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Sedans (vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

The idea is to build a chain of identifiers and types in a UNIQUE()
constraint that go up the tree when you use a REFERENCES constraint.
Obviously, you can do variants of this trick to get different class
structures.

If an entity doesn't have to be exclusively one subtype, you play with
the root of the class hierarchy:

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
PRIMARY KEY (vin, vehicle_type),
..);

Now start hiding all this stuff in VIEWs immediately and add an
INSTEAD OF trigger to those VIEWs.

#45

Quote:

That's not the kind of flags I was talking about; say we need to track expenses and some expense types have an additional field [sic: column] to be required in the form [sic: form? like on the input, non-DB side of the house?]. I might add a column in the expense_types table to indicate whether a datum is required.

If you want it to be required, why not use a DEFAULT and a NOT NULL
constraint?

Quote:

The same way, if we write a social network where kids register their quigzmo collection, the "races" table might have a has_tail column -- to avoid asking tail lengths for races that have no tail.

What the heck is a "quigzmo"? Hey, remember I am old! I still say
"hip hugger bell bottoms" and not "low erise flares" and use an abacus
for my check book.

Quote:

And with a clever trick we might change has_tail in minimum_tail_length, where accepted values are 1 and NULL... I'm not sure I like that

If I understand what a "quigzmo" (gotta google that!), then that would
a good choice. Try this line of reasoning:
1) If a "quigzmo" can be modified to add a tail, then a length of zero
would make sense.
2) If a "quigzmo" cannot be modified to add a tail, then a length of
NULL makes sense.

Quote:

A way to avoid the has_tail flag might be to explicitly state the subset of tailed races... with

CREATE TABLE tailed_races
(race_code VARCHAR(10) PRIMARY KEY REFERENCES Races);

but I think it might not be convenient to grow tables like that. <<

The classic scenario calls for a root class with all the common
attributes and then specialized sub-classes under it. As an example,
let's take the class of Vehicles and find an industry standard
identifier (VIN), and add two mutually exclusive sub-classes, Sport
utility vehicles and sedans ('SUV', 'SED').

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
UNIQUE (vin, vehicle_type),
..);

Notice the overlapping candidate keys. I then use a compound candidate
key (vin, vehicle_type) and a constraint in each sub-class table to
assure that the vehicle_type is locked and agrees with the Vehicles
table. Add some DRI actions and you are done:

CREATE TABLE SUV
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL
CHECK(vehicle_type = 'SUV'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE Sedans
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL
CHECK(vehicle_type = 'SED'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

I can continue to build a hierarchy like this. For example, if I had
a Sedans table that broke down into two-door and four-door sedans, I
could a schema like this:

CREATE TABLE Sedans
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL
CHECK(vehicle_type IN ('2DR', '4DR', 'SED')),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE TwoDoor
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL
CHECK(vehicle_type = '2DR'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Sedans(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE FourDoor
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL
CHECK(vehicle_type = '4DR'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Sedans (vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

The idea is to build a chain of identifiers and types in a UNIQUE()
constraint that go up the tree when you use a REFERENCES constraint.
Obviously, you can do variants of this trick to get different class
structures.

If an entity doesn't have to be exclusively one subtype, you play with
the root of the class hierarchy:

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
PRIMARY KEY (vin, vehicle_type),
..);

Now start hiding all this stuff in VIEWs immediately and add an
INSTEAD OF trigger to those VIEWs.

#46

Quote:

That's not the kind of flags I was talking about; say we need to track expenses and some expense types have an additional field [sic: column] to be required in the form [sic: form? like on the input, non-DB side of the house?]. I might add a column in the expense_types table to indicate whether a datum is required.

If you want it to be required, why not use a DEFAULT and a NOT NULL
constraint?

Quote:

The same way, if we write a social network where kids register their quigzmo collection, the "races" table might have a has_tail column -- to avoid asking tail lengths for races that have no tail.

What the heck is a "quigzmo"? Hey, remember I am old! I still say
"hip hugger bell bottoms" and not "low erise flares" and use an abacus
for my check book.

Quote:

And with a clever trick we might change has_tail in minimum_tail_length, where accepted values are 1 and NULL... I'm not sure I like that

If I understand what a "quigzmo" (gotta google that!), then that would
a good choice. Try this line of reasoning:
1) If a "quigzmo" can be modified to add a tail, then a length of zero
would make sense.
2) If a "quigzmo" cannot be modified to add a tail, then a length of
NULL makes sense.

Quote:

A way to avoid the has_tail flag might be to explicitly state the subset of tailed races... with

CREATE TABLE tailed_races
(race_code VARCHAR(10) PRIMARY KEY REFERENCES Races);

but I think it might not be convenient to grow tables like that. <<

The classic scenario calls for a root class with all the common
attributes and then specialized sub-classes under it. As an example,
let's take the class of Vehicles and find an industry standard
identifier (VIN), and add two mutually exclusive sub-classes, Sport
utility vehicles and sedans ('SUV', 'SED').

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
UNIQUE (vin, vehicle_type),
..);

Notice the overlapping candidate keys. I then use a compound candidate
key (vin, vehicle_type) and a constraint in each sub-class table to
assure that the vehicle_type is locked and agrees with the Vehicles
table. Add some DRI actions and you are done:

CREATE TABLE SUV
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SUV' NOT NULL
CHECK(vehicle_type = 'SUV'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE Sedans
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL
CHECK(vehicle_type = 'SED'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

I can continue to build a hierarchy like this. For example, if I had
a Sedans table that broke down into two-door and four-door sedans, I
could a schema like this:

CREATE TABLE Sedans
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT 'SED' NOT NULL
CHECK(vehicle_type IN ('2DR', '4DR', 'SED')),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Vehicles(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE TwoDoor
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT '2DR' NOT NULL
CHECK(vehicle_type = '2DR'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Sedans(vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

CREATE TABLE FourDoor
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) DEFAULT '4DR' NOT NULL
CHECK(vehicle_type = '4DR'),
UNIQUE (vin, vehicle_type),
FOREIGN KEY (vin, vehicle_type)
REFERENCES Sedans (vin, vehicle_type)
ON UPDATE CASCADE
ON DELETE CASCADE,
..);

The idea is to build a chain of identifiers and types in a UNIQUE()
constraint that go up the tree when you use a REFERENCES constraint.
Obviously, you can do variants of this trick to get different class
structures.

If an entity doesn't have to be exclusively one subtype, you play with
the root of the class hierarchy:

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
PRIMARY KEY (vin, vehicle_type),
..);

Now start hiding all this stuff in VIEWs immediately and add an
INSTEAD OF trigger to those VIEWs.

#47

--CELKO-- wrote:

Quote:

That's not the kind of flags I was talking about; say we need to track expenses and some expense types have an additional field [sic: column] to be required in the form [sic: form? like on the input, non-DB side of the house?].

Yes, I mentioned fields in the context of building a dynamic input form.

Quote:

I might add a column in the expense_types table to indicate whether a datum is required.

If you want it to be required, why not use a DEFAULT and a NOT NULL constraint?

Because the additional data is required only for some kind of expenses.
I might have an "expense_types" table, and a "expenses" table. Then I
use expenses_types to build the form.
In editing an expense, whenever the type changes, some widgets might
come up or disappear.

Quote:

The same way, if we write a social network where kids register their quigzmo collection, the "races" table might have a has_tail column -- to avoid asking tail lengths for races that have no tail.

What the heck is a "quigzmo"?

I made it up, sorry. I figured a kind of plastic monster where every
specimen is unique in colors and personalization (so that kids buy
several almost identical ones) but come in different "races" and each
race can have some features, or not.
When registering a kid's collection, I want to ask for the color of the
tail if and only if the race comes with a tail at all.

(the primary key is conveniently given by the factory, each one has a
guaranteed unique name printed on the bottom)

Quote:

The classic scenario calls for a root class with all the common
attributes and then specialized sub-classes under it. As an example,
let's take the class of Vehicles and find an industry standard
identifier (VIN), and add two mutually exclusive sub-classes, Sport
utility vehicles and sedans ('SUV', 'SED').

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
UNIQUE (vin, vehicle_type),
..);

Notice the overlapping candidate keys.

Yes. I understand and already use this pattern in some places, to the
point I would avoid tools that don't support compound foreign keys.

Quote:

The idea is to build a chain of identifiers and types in a UNIQUE()
constraint that go up the tree when you use a REFERENCES constraint.
Obviously, you can do variants of this trick to get different class
structures.

But it doesn't seem to me that the form generation code would be more
readable than the version with some boolean column, at least not without
a strong library for generating dynamic SQL.

Quote:

If an entity doesn't have to be exclusively one subtype, you play with
the root of the class hierarchy:

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
PRIMARY KEY (vin, vehicle_type),
..);

Now start hiding all this stuff in VIEWs immediately and add an
INSTEAD OF trigger to those VIEWs.

Especially when it comes to business rules that can change very often
for unfathomable (to me) reasons, on small applications as opposed to
the ones that drive airports, I feel the burden of a tiny weeny boolean
column can preferable to a more complex schema.

Still, the very fact that I asked this question about design is because
every time I do some of the things you might despise, I ask myself if
it's appropriate, and try to keep a balance between pragmatism,
conceptual correctness and deadlines

Thank you for the clear answers.

#48

--CELKO-- wrote:

Quote:

That's not the kind of flags I was talking about; say we need to track expenses and some expense types have an additional field [sic: column] to be required in the form [sic: form? like on the input, non-DB side of the house?].

Yes, I mentioned fields in the context of building a dynamic input form.

Quote:

I might add a column in the expense_types table to indicate whether a datum is required.

If you want it to be required, why not use a DEFAULT and a NOT NULL constraint?

Because the additional data is required only for some kind of expenses.
I might have an "expense_types" table, and a "expenses" table. Then I
use expenses_types to build the form.
In editing an expense, whenever the type changes, some widgets might
come up or disappear.

Quote:

The same way, if we write a social network where kids register their quigzmo collection, the "races" table might have a has_tail column -- to avoid asking tail lengths for races that have no tail.

What the heck is a "quigzmo"?

I made it up, sorry. I figured a kind of plastic monster where every
specimen is unique in colors and personalization (so that kids buy
several almost identical ones) but come in different "races" and each
race can have some features, or not.
When registering a kid's collection, I want to ask for the color of the
tail if and only if the race comes with a tail at all.

(the primary key is conveniently given by the factory, each one has a
guaranteed unique name printed on the bottom)

Quote:

The classic scenario calls for a root class with all the common
attributes and then specialized sub-classes under it. As an example,
let's take the class of Vehicles and find an industry standard
identifier (VIN), and add two mutually exclusive sub-classes, Sport
utility vehicles and sedans ('SUV', 'SED').

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
UNIQUE (vin, vehicle_type),
..);

Notice the overlapping candidate keys.

Yes. I understand and already use this pattern in some places, to the
point I would avoid tools that don't support compound foreign keys.

Quote:

The idea is to build a chain of identifiers and types in a UNIQUE()
constraint that go up the tree when you use a REFERENCES constraint.
Obviously, you can do variants of this trick to get different class
structures.

But it doesn't seem to me that the form generation code would be more
readable than the version with some boolean column, at least not without
a strong library for generating dynamic SQL.

Quote:

If an entity doesn't have to be exclusively one subtype, you play with
the root of the class hierarchy:

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
PRIMARY KEY (vin, vehicle_type),
..);

Now start hiding all this stuff in VIEWs immediately and add an
INSTEAD OF trigger to those VIEWs.

Especially when it comes to business rules that can change very often
for unfathomable (to me) reasons, on small applications as opposed to
the ones that drive airports, I feel the burden of a tiny weeny boolean
column can preferable to a more complex schema.

Still, the very fact that I asked this question about design is because
every time I do some of the things you might despise, I ask myself if
it's appropriate, and try to keep a balance between pragmatism,
conceptual correctness and deadlines

Thank you for the clear answers.

#49

--CELKO-- wrote:

Quote:

That's not the kind of flags I was talking about; say we need to track expenses and some expense types have an additional field [sic: column] to be required in the form [sic: form? like on the input, non-DB side of the house?].

Yes, I mentioned fields in the context of building a dynamic input form.

Quote:

I might add a column in the expense_types table to indicate whether a datum is required.

If you want it to be required, why not use a DEFAULT and a NOT NULL constraint?

Because the additional data is required only for some kind of expenses.
I might have an "expense_types" table, and a "expenses" table. Then I
use expenses_types to build the form.
In editing an expense, whenever the type changes, some widgets might
come up or disappear.

Quote:

The same way, if we write a social network where kids register their quigzmo collection, the "races" table might have a has_tail column -- to avoid asking tail lengths for races that have no tail.

What the heck is a "quigzmo"?

I made it up, sorry. I figured a kind of plastic monster where every
specimen is unique in colors and personalization (so that kids buy
several almost identical ones) but come in different "races" and each
race can have some features, or not.
When registering a kid's collection, I want to ask for the color of the
tail if and only if the race comes with a tail at all.

(the primary key is conveniently given by the factory, each one has a
guaranteed unique name printed on the bottom)

Quote:

The classic scenario calls for a root class with all the common
attributes and then specialized sub-classes under it. As an example,
let's take the class of Vehicles and find an industry standard
identifier (VIN), and add two mutually exclusive sub-classes, Sport
utility vehicles and sedans ('SUV', 'SED').

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL PRIMARY KEY,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
UNIQUE (vin, vehicle_type),
..);

Notice the overlapping candidate keys.

Yes. I understand and already use this pattern in some places, to the
point I would avoid tools that don't support compound foreign keys.

Quote:

The idea is to build a chain of identifiers and types in a UNIQUE()
constraint that go up the tree when you use a REFERENCES constraint.
Obviously, you can do variants of this trick to get different class
structures.

But it doesn't seem to me that the form generation code would be more
readable than the version with some boolean column, at least not without
a strong library for generating dynamic SQL.

Quote:

If an entity doesn't have to be exclusively one subtype, you play with
the root of the class hierarchy:

CREATE TABLE Vehicles
(vin CHAR(17) NOT NULL,
vehicle_type CHAR(3) NOT NULL
CHECK(vehicle_type IN ('SUV', 'SED')),
PRIMARY KEY (vin, vehicle_type),
..);

Now start hiding all this stuff in VIEWs immediately and add an
INSTEAD OF trigger to those VIEWs.

Especially when it comes to business rules that can change very often
for unfathomable (to me) reasons, on small applications as opposed to
the ones that drive airports, I feel the burden of a tiny weeny boolean
column can preferable to a more complex schema.

Still, the very fact that I asked this question about design is because
every time I do some of the things you might despise, I ask myself if
it's appropriate, and try to keep a balance between pragmatism,
conceptual correctness and deadlines

Thank you for the clear answers.