From Wikipedia, the free encyclopedia
[edit] How about the Drawbacks?
Maps very poorly to the relational model, Does not normalize well, Incurs overhead because it often requires data be implicitly or explicitly converted to/from character format, Many implementations waste space by providing several columns of different data types to allow for the different data types a value might be, You have to manually re-create a lot of the functionality built-in to a relational database, such as check constraints and foreign key constraints.
The fact that vendors impose "limitations" and design databases poorly is not an advantage. By the way, the example given in the article is very EASILY converted to a properly normalized relational model. Perhaps someone should come up with a better example that is NOT easily converted to a normalized relational model? As an example:
| Patient Table: |
| [Primary Key is (Patient_ID)] |
| Patient_ID |
| Patient_Name |
| Patient_Test Table: |
| [Primary Key is (Patient_ID, Test_ID)] |
| Patient_ID |
| Test_ID |
| Date |
| Test_Type |
| Quantity |
| Unit_of_Measure |
Test_Type would be related to another table containing the various tests that could be performed, and Unit_of_Measure could relate to another table with UOM identifiers and possibly a conversion factor for a common UOM.
| Patient |
|
| Patient_ID |
Patient_Name |
| 1 |
Patient XYZ |
| Patient_Test |
| Patient_ID |
Test_ID |
Date |
Test_Type |
Quantity |
Unit_of_Measure |
| 1 |
1 |
1/5/1998 |
Hemoglobin |
12.5 |
gm/dl |
| 1 |
2 |
1/5/1998 |
Potassium |
4.9 |
Meq/L |
