In this article it seems the author is arguing for meaningful primary keys:
"Most RDBMSs offer a type of counter or autonumbering data type that automatically assigns a consecutive numeric value to each record. Although these counter fields will guarantee that you have a candidate key, the key will be meaningless for searching."
I would infer from the above that she recommends using PKs that do have meaning for searching.
That is, in my book, and also in the article about choosing a PK she refers to, a big NO, NO. Taking her advice, and designing the DB the way she does in her example, would therefore be a good example of an anti-pattern for DB design. I find it a little odd that an article talking about normalization would have such a bogus recommendataion.
Discussion on:
View:
Show:
The article is replete with misinformation. Let's take it point-by-point:
1. Multivalued fields must be removed to another table.
This is a silly statement. In the strictest sense, a column is only capable of holding one value from the domain over which it is defined.
Using the term "values" more loosely, there is no restriction on how many a field may contain. Given "X" is a value, let the debate begin about how many values are in "XX" and "X,X". In any case, none violate 1NF. The strongest proof is that 1NF is a characteristic of the table, irrespective of the data it contains.
2. Each field must be atomic, or as small as possible.
I guess that would be a bit, right? What more can I say?
3. Each field must have a key. [So, the values in at least one field or column in a table must be unique.]
The actual requirement is that the table may not permit duplicate rows. While a primary key is the usual way to achieve that, there is no limitation on the number of columns it may contain.
4. Repeating values must be removed to another table.
Absurd. A value may repeat in different rows of the same column or different columns of the same row. Reading the author's explanation, I have no idea what this means.
1. Multivalued fields must be removed to another table.
This is a silly statement. In the strictest sense, a column is only capable of holding one value from the domain over which it is defined.
Using the term "values" more loosely, there is no restriction on how many a field may contain. Given "X" is a value, let the debate begin about how many values are in "XX" and "X,X". In any case, none violate 1NF. The strongest proof is that 1NF is a characteristic of the table, irrespective of the data it contains.
2. Each field must be atomic, or as small as possible.
I guess that would be a bit, right? What more can I say?
3. Each field must have a key. [So, the values in at least one field or column in a table must be unique.]
The actual requirement is that the table may not permit duplicate rows. While a primary key is the usual way to achieve that, there is no limitation on the number of columns it may contain.
4. Repeating values must be removed to another table.
Absurd. A value may repeat in different rows of the same column or different columns of the same row. Reading the author's explanation, I have no idea what this means.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
