Timeline for Database Normalization - Can one field point to another?
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 20, 2014 at 20:40 | comment | added | mustaccio | Like I said, physical locations of table rows and column values within them are not guaranteed to remain constant, so persistently storing pointers would have been useless, just like it would have been useless to save values of C pointers between program invocations and hope they reference the same data the next time you run the program. Record IDs play the role of pointers in databases, and it is for this reason that they should be immutable. Other redundancy scenarios should be taken care of by proper normalization. | |
| Jun 20, 2014 at 19:07 | comment | added | linsek |
Unless I misunderstand how FKs work, History.EmployeeID is NOT a pointer to Employees.ID. The relationship is established by containing identical table UNIQUE data. That is not a pointer. That's data matching. If I changed the Employee ID in the Employees table that would break the relationship between any History records of that employee. Also, a PK being 'normally' chosen doesn't moot the use-case. It might not have been a flawless analogy, but the question wasn't if it was. It's whether pointers between fields are possible.
|
|
| Jun 20, 2014 at 18:45 | history | answered | mustaccio | CC BY-SA 3.0 |