Re: Attribute-values in separate table

<anjasmedts_at_hotmail.com> wrote in message news:1188630222.774830.120050_at_k79g2000hse.googlegroups.com...
> > There are two schools of thought as to whether the addition of a new
> > attribute should or should not require additional data definition.
> >
> > Adding a row to a table is data manipulation. altering a table to add a
new
> > column is data definition. Creating a new table is likewise data
> > definition.
> >
> > I'm of the school of thought that data in a database is managed better
when
> > the right to create and alter data definitions is severely restricted,
> > while the right to manipulate data is extended to the applications that
> > interact with the database.
> >
> > The other school of thought is that the superior flexibility of defining
new
> > attributes without altering any database definitions overrules the data
> > management advantages in prohibiting the same. I can't defend this
school
> > of thought (apparently yours) because, in my view, it leads inexorably
to
> > undocumented and therefore unusable data.
> >
> > Hope this helps.
>
> Good point, David.
> Although here I've found a lot of small attributes only containing Y/N-
> values, for which nobody knows what they're standing for. When
> creating new records, they are always filled with the default. It's a
> beautiful example that adding rows does not lead to more documented
> use.
>
> I do not belong to any school, I'm only open-minded.
> I think I look to data the wrong way. IfI see records with many
> attributes, mostly all 'N', except for the column HasWheels, I get
> confused.
> When I only see one record telling (123, HasWheels,Y), it points me
> directly to the fact that furniture 123 has something special: it has
> wheels!
>
> Is adding a column not forcing the application to stop as it will lock
> the entire table, or am I wrong?
>
It depends on which DBMS you are using. The best case I have seen (some ten years ago) was where the DBMS altered the table in the context of a transaction. Running applications would be forced to block (not stop) while the table was altered, and when the transaction committed, would be allowed to resume.

I can't speak for any of the major DBMS products in the field today. They may require you to stop or even recompile the application in order to get the desired result. And adding a column raises a possible area of ambiguity.

If the application contains the construct "select * from" it's possible that the columns delivered may be different from the programmer's intent at the time of writing the query. The programmer may have intended to retrieve all the columns that existed at that time, not all the columns that are added sometime in the future. Hence the application may become broken after recompile.

This is a slippery slope.

Programmers generally prefer to go the way you went, and deal with undocumented data. Programmers have never liked data mangagement under somebody else's control. They didn't like it in the days of indexed files. They didn't like it in the days of CODASYL databases. They didn't like it in the early days of SQL databases. They still don't like it.

I used to be a programmer in a former lifetime. But I've been managing data or databases for so long now that I might as well consider myself a non-programmer. Undocumented data is practically unmanageable as far as I'm concerned.

This is a very deep divide in the world of IT. I have only scratched the surface in my repsonses. Received on Sat Sep 01 2007 - 14:14:11 CEST